Andreas Mohr wrote:
> And what you describe is exactly what happens:
> The LibMain of WPIRSND.DLL is called there (upon NE_InitializeDLLs):
> /* Initialize implicitly loaded DLLs */
> ERR("init DLLs - START\n");
> NE_InitializeDLLs( pTask->hModule );
> ERR("init DLLs - END\n");
> NE_DllProcessAttach( pTask->hModule );
> ERR("attach DLLs - END\n");
> and then upon NE_DllProcessAttach the DllEntryPoint of MMSYSTEM would have
> been called, but this is too late, as LibMain of WPIRSND already performed
> MMSYSTEM calls. Grrr.
yup...
> According to this program it seems that all dlls a program/other dll depends
> on have to get their DllEntryPoint called before the DllEntryPoint of the
> parent program/dll.
> But is this correct ??
not really. NE DLLs can have two types of "init" funcs
- LibMain: is called to set up the DLLs itself
- DllEntryPoint: has been added in Win95 IIRC to mimic the PE loading mechanism
major issue is: LibMain is only called once, when the DLL is first loaded into
memory. DllEntryPoint is called (at least) for every process attaching to this
DLL
here's what happens is:
EXE gets its implicit DLLs initialized:
- MMSYSTEM has no LibMain => nothing is done
- WPIRSND has a LibMain => it's called
+ this DLL assumes MMSYSTEM has been properly initialized and
calls MMSYSTEM funcs
Wine's MMSYSTEM implementation relies on DllEntryPoint to do its per process
initialization, but, in this case, has not been done in time.
I think that we can rely on Wine's DLL loading mechanism, but rather blame the
16/32 DLL pairing in Wine
this issue can also be found in any DLL pair (NE+PE) using instance data
(winsock for example)
fixes that could be looked upon:
- lazy instance data initialization
- implicit loading of the other DLL in the pair (but import is not supported
for 16 bit DLLs)
- smart use of 'owner' field in BUILTIN16 descriptor (so far it's not used, but
I assume that Alexandre will shortly use it for his elfdll implementation)
- do the PE pair loading in LibMain instead of DllEntryPoint (would require
init directive to be added to 16 bit modules)
not sure which one is best :-(
A+
--
---------------
Eric Pouech (http://perso.wanadoo.fr/eric.pouech/)
"The future will be better tomorrow", Vice President Dan Quayle
