RE: DLL initialization (was: Loading new DLLs on old Windows)

This was asked before, but I'll just ask it again.  Are you absolutely sure you aren't uising any functions that in any way touch functions that have unicode equivalents?
 
Remember that Windows 2K/XP natively support these functions while on Win9x you need to supply an extra library to get the compatibility.
 
Furthermore, remember that quite a few of the standard functions have defines in the headers which select between the non unicode (A at the end of the function) and unicode (W at the end of the function).
 
For example there is a CreateWindowA and a CreateWindowW function and CreateWindow is defined to be one or the other depending on your settings (whether or not UNICODE is defined or not).
 
Running dumpbin might show you whether your DLL is indeed expecting the wide character versions or not.  For example 
 
Phil

________________________________

From: [email protected] on behalf of Andras Balogh
Sent: Mon 2/16/2004 01:55
To: [email protected]
Subject: Re: [GD-Windows] DLL initialization (was: Loading new DLLs on old Windows)



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



-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
Gamedevlists-windows mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_id=555