It must not call the LoadLibrary or LoadLibraryEx function (or a function that calls these functions), because this may create dependency loops in the DLL load order. This can result in a DLL being used before the system has executed its initialization code.
Эксперименты показали, что ничего такого не происходит.
Покажите код который приведет к проблемам из за использования LoadLibrary в DllMain.
Здравствуйте, Abyx, Вы писали:
A>В MSDN написано: (ссылка) A>
It must not call the LoadLibrary or LoadLibraryEx function (or a function that calls these functions), because this may create dependency loops in the DLL load order. This can result in a DLL being used before the system has executed its initialization code.
A>Эксперименты показали, что ничего такого не происходит.
Здравствуйте, Abyx, Вы писали:
A>В MSDN написано: (ссылка) A>
It must not call the LoadLibrary or LoadLibraryEx function (or a function that calls these functions), because this may create dependency loops in the DLL load order. This can result in a DLL being used before the system has executed its initialization code.
A>Эксперименты показали, что ничего такого не происходит.
A>Покажите код который приведет к проблемам из за использования LoadLibrary в DllMain.
Здравствуйте, LuciferSaratov, Вы писали: LS>Я думаю, вот это имелось ввиду.
Сначала проверьте, а потом постите сюда =\
Этот код выполняется без каких либо проблем. LoadLibrary("lib1.dll") ничего не делает, т.к. lib1.dll уже загружена.
Меня интересуют рабочие примеры проблем с LoadLibrary в DllMain %)
A>Покажите код который приведет к проблемам из за использования LoadLibrary в DllMain.
У меня был практические проблемы использования RegOpenKey из dllmain моей длл — валилось, т.к. DllMain моей длл исполнялся раньше чем advapi32'шный. Апликуха линковалась на обе эти длл, и еще на другие, которые тоже линковались на advapi32, то есть раскрутить бесконфликтный граф исполнения dllmain'ов загрузчику не удалось. Кстати воспроизводилась проблема не на всех системах. Вероятно на некоторых загрузчик вначале исполнял dllmain advapi32
Как много веселых ребят, и все делают велосипед...
Здравствуйте, Abyx, Вы писали:
A>Здравствуйте, Jolly Roger, Вы писали: JR>>А что "такое" должно происходить? A>сам не знаю, но написано же, "must not call"
Хм, но ведь там-же ясно написано "may create", " can result". То есть проблемы возможны, но не обязательны. А "must not call" потому, что отсутствие проблем сейчас не гарантирует их отсутствие и в будущем.
Здравствуйте, Abyx, Вы писали:
A>В MSDN написано: (ссылка) A>
It must not call the LoadLibrary or LoadLibraryEx function (or a function that calls these functions), because this may create dependency loops in the DLL load order. This can result in a DLL being used before the system has executed its initialization code.
A>Эксперименты показали, что ничего такого не происходит.
A>Покажите код который приведет к проблемам из за использования LoadLibrary в DllMain.
Загружаем DLL1. Исполняется ее DLLMain. В ней загружаем DLL2. Исполняется ее DLLMain как часть LoadLibrary. Вызываем теперь из DLL2 некую функцию DLL1. Она будет выполнена при том. что еще не завершилась DLLMain в DLL1.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Загружаем DLL1. Исполняется ее DLLMain. В ней загружаем DLL2. Исполняется ее DLLMain как часть LoadLibrary. Вызываем теперь из DLL2 некую функцию DLL1. Она будет выполнена при том. что еще не завершилась DLLMain в DLL1.
Здравствуйте, Abyx, Вы писали:
A>В MSDN написано: (ссылка) A>
It must not call the LoadLibrary or LoadLibraryEx function (or a function that calls these functions), because this may create dependency loops in the DLL load order. This can result in a DLL being used before the system has executed its initialization code.
A>Эксперименты показали, что ничего такого не происходит.
A>Покажите код который приведет к проблемам из за использования LoadLibrary в DllMain.
LoadLibrary("wininet.dll") — проблема возникает не из-за загрузки dll, а из-за того что там вызывается CreateThread, который в свою очередь посылает в dllmain сообщение THREAD_ATTACH, вообщем получается бесконечный цикл.
Здравствуйте, kai3, Вы писали:
K>LoadLibrary("wininet.dll") — проблема возникает не из-за загрузки dll, а из-за того что там вызывается CreateThread, который в свою очередь посылает в dllmain сообщение THREAD_ATTACH, вообщем получается бесконечный цикл.
У меня все работает.
Такой проблемы просто не может быть, т.к. поток запускается после завершения всех вложенных DllMain — там критическая секция, никаких циклов не возникает.
K>LoadLibrary("wininet.dll") — проблема возникает не из-за загрузки dll, а из-за того что там вызывается CreateThread, который в свою очередь посылает в dllmain сообщение THREAD_ATTACH, вообщем получается бесконечный цикл.
Все в этом отношении с wininet хорошо — потоки из dllmain стартовать можно, если очень осторожно (с)
В wininet я другой баг видел — если ее динамически загружать, потом юзать, и потом динамически _выгружать_ через FreeLibrary, то какаято версия wininet частенько зависала ибо в PROCESS_DETACH ждала какого то своего потока. В случае статической линковки на wininet такой проблемы не было, ибо перед нотификацией статических загруженных длл загрузчик (вернее, выгрузчик вначале убивает все потоки приложения, кроме основного.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, kai3, Вы писали:
K>LoadLibrary("wininet.dll") — проблема возникает не из-за загрузки dll, а из-за того что там вызывается CreateThread, который в свою очередь посылает в dllmain сообщение THREAD_ATTACH, вообщем получается бесконечный цикл.
Потому и рекомендуют вызывать DisableThreadLibraryCalls
K>>LoadLibrary("wininet.dll") — проблема возникает не из-за загрузки dll, а из-за того что там вызывается CreateThread, который в свою очередь посылает в dllmain сообщение THREAD_ATTACH, вообщем получается бесконечный цикл. CD>Потому и рекомендуют вызывать DisableThreadLibraryCalls
DisableThreadLibraryCalls не поможет от дедлока на ожидании начала исполнения или завершения потока. Рекомендуют его совсем по другой причине.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, ononim, Вы писали:
K>>LoadLibrary("wininet.dll") — проблема возникает не из-за загрузки dll, а из-за того что там вызывается CreateThread, который в свою очередь посылает в dllmain сообщение THREAD_ATTACH, вообщем получается бесконечный цикл. O>Все в этом отношении с wininet хорошо — потоки из dllmain стартовать можно, если очень осторожно (с) O>В wininet я другой баг видел — если ее динамически загружать, потом юзать, и потом динамически _выгружать_ через FreeLibrary, то какаято версия wininet частенько зависала ибо в PROCESS_DETACH ждала какого то своего потока. В случае статической линковки на wininet такой проблемы не было, ибо перед нотификацией статических загруженных длл загрузчик (вернее, выгрузчик вначале убивает все потоки приложения, кроме основного.
Да, у меня как раз так и было... библиотека динамически подгружалась, и выполнение после LoadLibrary("wininet.dll") не продолжалось, думал что это связано с созданием потока внутри инициализации wininet.dll. Протрассировал dllmain в wininet.dll, выполнение остановилось на вызове CreateThread.
Здравствуйте, Abyx, Вы писали:
A>Эксперименты показали, что ничего такого не происходит.
A>Покажите код который приведет к проблемам из за использования LoadLibrary в DllMain.
"Нормальные герои всегда идут в обход!"
вначале убивает все потоки приложения, кроме основного.
