Практически все приложения используют ExitProcess. В том числе приложения, скомпилированные в C++ Builder и Delphi.

Это сообщение отредактировал(а) 586 - 1.8.2010, 10:09

Ну сам по себе вызов LoadLibrary никаких дополнительных потоков не создаёт, если конечно в обработчике DLL_PROCESS_ATTACH этой библиотеки не стоит CreateThread/_beginthreadex... Вы подробнее описать проблему не можете?..
Да и вообще давайте рассуждать логически: если функия потока создаваемого потока (извиняюсь за масло масленное) находится в DLL, и при её выгрузке поток корректно не завершается и продолжает работать, то сразу же должен вылетать access violation. Так как образ DLL уже отгружен от адресного пространства вашего процесса. MSHTML.DLL вряд-ли так криво реализована...



Ну уж очень нестандартное решение... )))))))))

Contains processor-specific register data. The system uses CONTEXT structures to perform various internal operations. Refer to the header file WinNT.h for definitions of this structure for each processor architecture.

Не обращали внимания на эту идиотскую по-вашему мнению информацию из MSDN?.. )))))))))

А вот вам:



Где поле поле регистра Eip?.. Или под каждую архитектуру своё завершение писать?.. Пока ещё такого не было, но всё-таки соглашусь с Abyx: вы бредите. Хотя подход безусловно интересный, но не нестандартный, а нерабочий... 

Это сообщение отредактировал(а) HellStranger - 2.8.2010, 14:07

HellStranger, у вас по умолчанию платформа xeon? у меня - по умолчанию x86-32
какбэ в WinNT.h нужная структура CONTEXT выбирается дефайнами (#ifdef).

Это сообщение отредактировал(а) Abyx - 2.8.2010, 14:10

Вы, наверное, слепые или просто далеки от мысли... Я привёл пример структуры CONTEXT под архитектурой, где указанного поля регистра EIP просто напросто нет, тем самым указав аппаратную зависимость решения, предложенного 12usver12. Или вы у нас настолько продвинутый программист, что под каждый процессор пишите отдельно, но используете при этом cpp?.. "ОЧЕНЬ УМНЫЙ" ПОДХОД! Удачи в вашем нелёгком (читать по-другому...  ) труде!

Добавлю только, что вместо того, чтобы ответить на мою просьбу уточнить суть проблемы, вы начинаете искать повод превратить тему в балаган, делаю вывод, что вы баба базарная... И всё-же, посоветую вам для решения проблемы прочесть Рихтера главы 19 и в особенности 20, где, я уверен, ваша проблема описана и решена.

Это сообщение отредактировал(а) HellStranger - 2.8.2010, 14:36

HellStranger, вы такой забавный) пишите еще


естественно использование регистра eip - это платформозависимое решение, это только x86-32. это очевидная вещь же.
проблема поднятая в этой теме полностью раскрыта в этой теме, и уточнять там нечего. в конце концов вы сами можете воспроизвести ситуацию вызвав LoadLibrary("MSHTML.DLL") под отладчиком

К вашему сведению EIP-регистр общего назначения, присутствующий во всей архитектуре IA-32/64 (в том числе и в XEON), и всё-же решение на его основе даже для данной платформы не подходят. 
Вы тоже забавный, настолько, что отвечать на ваши посты я смысла больше не вижу... Сам шучу- сам смеюсь это про вас... 

HellStranger, я открою вам страшную тайну, первая буква в Eip говорит что это только x32, и никак не x64. там он называется Rip

А кто сказал что по FreeLibrary билиотека будет выгружена из адресного пространства по DLL_PROCESS_DETACH, если вернем false то DLL не будет выгружена?

Может бы все проще ? Автор не вызвал нужные функции для закрытия всех ресурсов ?

автор собственно их и реквестирует

А можно узнать, зачем звать LoadLibrary("MSHTML.DLL") когда можно (и нужно) просто создать COM объект (один из поддерживаемых ею)? Возможно она (MSHTML.DLL) не рассчитана на то, что ее будет грузить НЕ COM менеджер?

xvr, вообще-то создание ком-объекта сопровождается загрузкой библиотеки.
COM менеджер - это что? посмотрите реализацию CoCreateInstance %) там есть LoadLibrary

алсо она рассчитана на то что ее будут грузить не-COM менеджер

Да, но не ограничивается только им.

COM менеджер следит за тем, что бы библиотеку не выгрузилась, пока есть живые COM объекты (если конечно програмист сам ее не выгрузит в принудительном порядке   )

Да, упоминания в MSDN есть. 

А в примерах от MS ( http://www.microsoft.com/downloads/details...;displaylang=en / Htmldlg.exe) тоже остаются нитки при завершении?

Abyx, Используйте ExitProcess, и не слушайте ШКОЛАТУ!

SetThreadContext(утечка памяти pending kernel services, а на WaitFor**** это вообще полный бред)
TerminateThread - прямая утечка памяти(минимум Не корректное освобождения стека, + pending kernel services).

Использования FreeLibrary есть очень плохо во вногих местах. 
При использовании FreeLibrary, вы должны быть уверены, что кроме вашего кода его не кто не использует, и в библиотеке не был создан поток.