Попалась мне длл - cygwin1.dll (от одноименного компилятора). Надо было ее поиспользовать. Но загрузив ее динамически через LoadLibrary она отказывалась работать. Статически прилинковав ее - работала без проблем. Причину выяснил быстро. При статической загрузке, в DllMain, парамерт lpReserved передается контекст, при динамической загрузке - передается NULL. Вот библиотека это палит, и отказывается работать если инициализация прошла с lpReserved = NULL, т.е. если длл была динамически загружена. Интересует, есть ли методы эмуляции статической загрузки dll?
oleg_nefedov Я бы ставил аппартный брейкпоинт на DllMain и подменял. Но на самом деле совсем не факт, что простая подмена lpReserved (не важно, каким способом) заставит cygwin1.dll работать правильно. Наиболее вероятно, что она не просто "палит" аргумент, а читает и модифицирует контекст, чтобы корректировать, куда будет передано дальнейшее управление.
Я просто занопил проверку в длл, и она стала работать как надо. В этом случае, просто проверяется что значение lpReserved != NULL. Просто хотелось бы знать, есть ли легальные способы загрузить dll так же как это делат система? Если мапить длл самому, все будет работать в этом случае, но, например, этой длл не будет в списке модулей PEB..
oleg_nefedov Ну я же сказал, что бы я сделал. Конечно, нет точных гарантий, что модуль попадёт именно туда, куда предполагалось. Но пробная загрузка с флагом DONT_RESOLVE_DLL_REFERENCES в принципе должна дать высоковероятную оценку. Это предположительно самый простой вариант.
Ну система же не ставит хардварных бряков. Система использует какие то другие пути для запуска статических длл. Какие вот это пути? Наверное и в моем случае можно использовать что нибудь такое?
oleg_nefedov Вы хотите делать всё вручную, что делает система? Можно, конечно, и "что-нибудь такое" крайне неудобное. В том числе и в PEB тогда сами добавляйте новый модуль.
Да, хотелось бы сделать так как это делает система. Еще, например, подскажите, как система передает управление на точку входа длл при статическом вызове? Наверное создает поток, да? Но почему же этот поток выполняется сразу? Если мы при инициализации длл создадим поток, то реально он начнет выполняться только когда все длл будут загружены и файл инициализирован..?
также как и при динамическом - LdrLoadDll. никакого потока никто не создает! когда звезды сойдутся так что шелудер виндоса переключит контекст на новосозданый тред, никто не будет ждать завершения загрузки модулей. LdrLoadDll /*EnterCriticalSection( &LdrpLoaderLock )*/ ->LdrpLoadDll /*LdrpMapDll(), LdrpWalkImportDescriptor()*/->LdrpRunInitializeRoutines->LdrpCallInitRoutine->DllMain примерно так оно все происходит.
ASMatic Не пишите сию ересь. Статическая загрузка начинается с апк, точнее исполняется в стартап апк процедуре. Соответственно контекст там сохранён вне зависимости от причин вызова. В динамике же в стеке что угодно быть может. l_inc Привет студентик. Звёзды будут ждать на LdrpLoaderLock. Для вас будет удивительным что завершив поток на дллмейн, другой поток продолжит исполнять загрузчик, дедлока не будет. Сию манипуляцию можно элементарно в несколько инструкций вручную провести. В общем задача не решаема.
kejcerfcrv Речь о повторном захвате одним и тем же потоком? Или Вы пытаетесь впарить, что два разных потока одновременно критическую секцию захватят?
l_inc Если один захватил и был завершён есчо до освобождения кс, то для второго потока она окажется освобождённой и он не будет ждать. Это только для LdrpLoaderLock смысл имеет.
kejcerfcrv видимо нормально подзалились - стек ?! - что там со стеком у вас не то? - у меня все норм. И при статической и при динамической%
