Re: [GD-Windows] DLL initialization (was: Loading new DLLs on old Windows)

[Andras B. <bn...@ma...>]

Hi Simon,

> If the entry point (_DllMainCRTStartup, DllMain or a custom entry point)
> returns FALSE, LoadLibrary() will return the error you're getting
> (ERROR_DLL_INIT_FAILED).

Yeah, I know. I've already included a fake DllMain that just returns TRUE,
but the result is the same. I guess this means that it fails in
_DllMainCRTStartup.

> There aren't many reasons why _DllMainCRTStartup (the function called before
> DllMain) would fail, but a few examples would be:

> - memory (HeapAlloc() inside the CRT stuff failing).

Well, the logs say that he's got 150MB+ of free memory.

> - static/global object creation failing (e.g. out of stack, exceptions from
> constructors etc).

There ain't no static objects in my DLL. It shouldn't do anything upon loading.

> - clashes between the version of the C runtime library used by the DLL and
> the client app (pretty rare unless the DLL and client pass CRT objects
> between each other).

They are dynamically linked to the same CRT (which is installed in the same
directory as the executables + DLLs)

> - CRT file handle problems (e.g. if your client app redirected the standard
> CRT handles in a bad way).

Don't even know what you're talkin' about :)

> - [extremely unlikely, but...] MFC DLLs built with MSVC++ version 4 - there
> were two versions of the 4.2 MFC DLLs that had identical names but were
> slightly different - some apps (mostly OLE heavy ones) where the DLL used
> one version and the client used another would have a few problems.

Have not even touched MFC in any way.

> Have you done anything at all special with your DLLs? (re-basing, function
> forwarding, delay loading etc)

Nope.

> I'd still have a DllMain with just a simple "return TRUE;" (and maybe a
> DisableThreadLibraryCalls() for DLL_PROCESS_ATTACH notifications for
> performance reasons where relevant) just to be certain I knew what was being
> returned for entry.

I've already done that without success... :(

> Do all the plugin DLLs you load suffer from the same issue or is it just
> one? -  try statically linking the offending DLL and see if the tester gets
> any more specific error message (such as the missing export message box
> you'll get if your DLL requires an OS function only present in a newer
> version of Windows).

Currently this program only uses one DLL, but I'll create some more (simple
ones), and see if they work or not. Now I'm pretty sure that I'm using
something in my DLL, that Win98 doesn't support, just doesn't know what. :)

Thanks for your help,


Andras