Всем привет!!!
Предлогаю начать дискуссию о проэктировании приложания для различных OS от Microsoft.
Так к примеру всем известно что в win98/95 реализация и использование DLL имеет отличие от работы с DLL в NT/2000.
Сразу вопрос в аудиторию:
Всегда ли Dll в win98 должен содержась DllMain? В MSDN указано, что если при вызове (в W2K)LoadLibraryEx с флагом DONT_RESOLVE_DLL_REFERENCES функция DllMain не вызывается(
...the system does not call DllMain for process and thread initialization and termination.), таким образом можно подумать что, в win98/95 поток DllMain существует до выгрузки dll из адресного простр. родительского процесса. Всели тут так?


Спасибо!

Здравствуйте MadRobinzon, Вы писали:

MR>Так к примеру всем известно что в win98/95 реализация и использование DLL имеет отличие от работы с DLL в NT/2000.

А можно вот об этом подробнее?

MR>Сразу вопрос в аудиторию:
MR>Всегда ли Dll в win98 должен содержась DllMain?

Похоже, что всегда (при условии, что мы пользуемся сишным компайлером и не переименовываем entry point). Причем это справедливо для любой Win32-операционки.

MR> В MSDN указано, что если при вызове (в W2K)LoadLibraryEx с флагом DONT_RESOLVE_DLL_REFERENCES функция DllMain не вызывается(
MR>...the system does not call DllMain for process and thread initialization and termination.),

Ну, раз MS сказала, значит не вызывается.
Но сразу рискну заметить, что случай использования этого флага — ба-а-а-льшая редкость, чаще как раз resolve dll references жизненно необходимы

MR> таким образом можно подумать что, в win98/95 поток DllMain существует до выгрузки dll из адресного простр. родительского процесса. Всели тут так?

Что такое "поток DllMain"?
Поток, в котором _выполняется_ DllMain? Так при загрузке dll DllMain() может быть вызвана в одном потоке, а при выгрузке — в другом, это же функция, ей пофигу, в каком потоке ее позовут.

Здравствуйте Игорь Вартанов, Вы писали:

ИВ> Но сразу рискну заметить, что случай использования этого флага — ба-а-а-льшая редкость, чаще как раз resolve dll references жизненно необходимы

Я бы даже сказал, что это необходимо делать либо в каких-нибудь технологических целях, либо в мазахистских с последующей настройкой всех ссылок и подгрузкой оставшихся модулей

Здравствуйте Игорь Вартанов, Вы писали:

ИВ>Здравствуйте MadRobinzon, Вы писали:

MR>>Так к примеру всем известно что в win98/95 реализация и использование DLL имеет отличие от работы с DLL в NT/2000.

ИВ> А можно вот об этом подробнее?
о Игорь — привет ! Рад видеть тебя в нашем =) форуме =) и IT тут ... все трое собрались...
к чему бы это =)

Здравствуйте Igor Soukhov, Вы писали:

IS>Здравствуйте Игорь Вартанов, Вы писали:

ИВ>>Здравствуйте MadRobinzon, Вы писали:

MR>>>Так к примеру всем известно что в win98/95 реализация и использование DLL имеет отличие от работы с DLL в NT/2000.

ИВ>> А можно вот об этом подробнее?
IS>о Игорь — привет ! Рад видеть тебя в нашем =) форуме =) и IT тут ... все трое собрались...
IS>к чему бы это =)

IS>
Ну как так можно ? надо было подождать пока между вами кто-то вклинится что бы загадать желание
А вот было 2 шанса и все упустил

Здравствуйте Игорь Вартанов, Вы писали:

MR>>Сразу вопрос в аудиторию:
MR>>Всегда ли Dll в win98 должен содержась DllMain?

ИВ> Похоже, что всегда (при условии, что мы пользуемся сишным компайлером и не переименовываем entry point). Причем это справедливо для любой Win32-операционки.

Кроме, конечно, resource-only dlls, что достигается опцией линкера /noentry.

Здравствуйте Alex Fedotov, Вы писали:

ИВ>> Похоже, что всегда (при условии, что мы пользуемся сишным компайлером и не переименовываем entry point). Причем это справедливо для любой Win32-операционки.

AF>Кроме, конечно, resource-only dlls, что достигается опцией линкера /noentry.


Alex, ты как всегда предельно точен.

Здравствуйте Igor Soukhov, Вы писали:

IS>и IT тут ... все трое собрались...
IS>к чему бы это =)

Ну к чему еще? Поговорим про WinAPI

Здравствуйте Игорь Вартанов, Вы писали:

ИВ>Здравствуйте Igor Soukhov, Вы писали:

IS>>и IT тут ... все трое собрались...
IS>>к чему бы это =)

ИВ> Ну к чему еще? Поговорим про WinAPI
ну лана — вы говорите — я пошел FUTURAMу смотреть... =)

Извените великодушно, что вмешиваюсь

Если я правильно понял, то функция DllMain должна существовать всегда?

Но ведь и без нее все работает...

Здравствуйте Digger, Вы писали:

D>Извените великодушно, что вмешиваюсь

Вот вечно так. Только начнешь кому-нибудь лапшу на уши вешать, сразу вмешиваются.

D>Если я правильно понял, то функция DllMain должна существовать всегда?

D>Но ведь и без нее все работает...

Давай разделим две ситуации:

1. Ты просто не пишешь DllMain в своей программе. В таком случае линкер найдет версию DllMain по умолчанию в стандартной библиотеке и слинкует программу с ней. В этом легко убедиться, рассматривая map-файл.

Важно в этом случае то, что точка входа DLL (_DllMainCRTStartup) все равно присутствует, она инициализирует библиотеку C, вызывает статические конструкторы и т.д.

2. Ты запретил точку входа DLL опцией линкера /noentry. Так тоже работает, по крайней мере под NT. DLL прекрасно загружается и можно вызывать экспортируемые функции. Однако в этом случае, библиотека C не инициализируется, статические конструкторы не вызываются; все как в _ATL_MIN_CRT.

"Все работает" относилось к какой ситуации?

Здравствуйте Alex Fedotov, Вы писали:

AF>"Все работает" относилось к какой ситуации?

Вобщем-то ни к какой %-)
Длл написана вообще на фортране, меня здесь интерисует процесс загрузки как таковой, например в win me он идет по другому, конкретно различия еще не понял, но LoadLibrary просто вешает процесс, в НТ загружается нормалино, но потом грохается, но енто уже другая история.

Здравствуйте Alex Fedotov, Вы писали:

AF>2. Ты запретил точку входа DLL опцией линкера /noentry. Так тоже работает, по крайней мере под NT. DLL прекрасно загружается и можно вызывать экспортируемые функции. Однако в этом случае, библиотека C не инициализируется, статические конструкторы не вызываются; все как в _ATL_MIN_CRT.

Стоит добавить, что в этом случае у системы не будет никакого способа сообщить о присоединении/отсоединении к процессу/потоку этой dll, entry-то равно нулю.

Здравствуйте многие, Вы писали ...

А что происходит при загрузке dll с флагом DONT_RESOLVE_DLL_REFERENCES,
он только грузит ее в память, или что-то еще все таки делает ?
Насколько я понимаю он не подгружает IMPORT_TABLE, и не правит "fixup delta".
А что еще делают винды при загрузке ?