Вопрос в следующем, здесь между .IF/.ENDIF может быть любой
код или есть какие-то ограничения, например, DialogBoxParam
здесь можно вызвать??

.if reason==DLL_PROCESS_ATTACH
   ......................
.endif

А почему нет? Это же просто инициализация - Win вызвыает вашу процедуру после загрузки DLL, значит ресурсы есть, все остальное тоже, я вообще не вижу отличий DllMain от любой другой ф-ии в DLL, разве что это единственная ф-я, которую обязательно вызовут... мой ламерский опыт свидетельствует - можно делать все что хочешь... пока не пнут :)

Что-то DialogBoxParam у меня не катит :-(

Косяк нашёл, вопрос снимается :-)

> мой ламерский опыт свидетельствует - можно делать все что хочешь... пока не пнут

Не можно только вызывать LoadLibrary() =))

Dr.Golova
То есть лоадить себя? Попробовать надо... Тоже пакость :)

hGoblin
То есть лоадить себя?
Любую DLL. Также не катят WSAStartup, InitCommonControlsEx и прочие ф-ции, которые тоже грузят либы.

Упс. А почему? Может, что почитать надо, а я не знал?

Все, кажется, просек. Это потому что у dll-ки нет своего контекста, и грузить некуда?

Хм.. Дурят нашего брата... Подправил Iczelionov туториал, скопировал в директорию к usedll.exe ASMGUID.DLL, запустил - пашет, мессагбох кажет один раз, ASMGUID не удаляется, значит - грузит!

krnl db "ASMGUID.DLL",0
.code
DllEntry proc hInstance:HINSTANCE, reason:DWORD, reserved1:DWORD
	.if reason==DLL_PROCESS_ATTACH
		invoke MessageBox,NULL,addr LoadMsg,addr AppName,MB_OK
		invoke LoadLibrary,addr krnl
            test eax,eax
            jnz @OK
     		invoke MessageBox,NULL,addr LoadMsg,addr AppName,MB_OK
            @OK:
.elseif .......

Далеко не для всех dll будет работать.
Загрузи user32.dll и пропробуй оттуда дернуть MessageBoxA - о результатах доложить - если я правильно помню историю трехлетней давности - прога просто падала.

Все нормально, грузится как обычно, без проишествий. Попробовал в качестве нагрузки к MessageBox InitCommonControls (кстати, разве она грузит длл?, Iczelion говорил, там один ret ;) - не падает, и все тут! Может, это только у нас, динозавров на '98? NT-подобных у меня нет, проверить не могу :(

MSDN :
Warning The entry-point function should perform only simple initialization or termination tasks. 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. Similarly, the entry-point function must not call the FreeLibrary function (or a function that calls FreeLibrary), because this can result in a DLL being used after the system has executed its termination code.

It is safe to call other functions in Kernel32.dll, because this DLL is guaranteed to be loaded in the process address space when the entry-point function is called. It is common for the entry-point function to create synchronization objects such as critical sections and mutexes, and use TLS. Do not call the registry functions, because they are located in Advapi32.dll. If you are dynamically linking with the C run-time library, do not call malloc; instead, call HeapAlloc.

Calling imported functions other than those located in Kernel32.dll may result in problems that are difficult to diagnose. For example, calling User, Shell, and COM functions can cause access violation errors, because some functions in their DLLs call LoadLibrary to load other system components. Conversely, calling those functions during termination can cause access violation errors because the corresponding component may already have been unloaded or uninitialized.

Because DLL notifications are serialized, entry-point functions should not attempt to communicate with other threads or processes. Deadlocks may occur as a result.

Note To provide more complex initialization, create an initialization routine for the DLL. You can require applications to call the initialization routine before calling any other routines in the DLL. Otherwise, you can have the initialization routine create a named mutex, and have each routine in the DLL call the initialization routine if the mutex does not exist. Be sure to use a unique mutex name for each process that loads the DLL.

А если мы имеем в процессе некоторые delay-load либы, то это может произойти весьма легко.

hGoblin
InitCommonControls (кстати, разве она грузит длл?, Iczelion говорил, там один ret ;) - не падает, и все тут!
Такой апи для меня вообще нет. Я имел в виду InitCommonControlsEx. Вообще послушайте опытных людей! Возможность глюков более чем реальна. Потом никакой отладчик не спасёт ;-)

Так слушаю же! Но не верю на слово :) InitCommonControlsEx я у себя не нашел. Говорю же - динозавр, а пираты родного города не позаботились о снабжении меня WindowsNT (2k, тем паче XP из принципа не покупаю) :( Вот и пришлось вызывать без Ex. Хотя долго чесал в затылке, проводя аналогии: CreateWindow/Ex - простая - расширенная, как же они ret расширить умудрились? В общем, скромно молчу в тряпочку, пока не разживусь где-нибудь NT+MSDN
И все-таки пока не уроню прогу, не пойму, почему она падает. В теории нифига не понятно - где функции могут быть вызваны до инициализации, если
а)DLL notifications are serialized
б)что в длл, что в основном коде ф-ии вызываются после LoadLibrary
Все же правильно должно быть - загрузил - проинициализировалась, если и в exe и в dll грузится одна и та же либа, то она лишь проинициализируется два раза (с разными параметрами), и все... нет, не понимаю :(