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

[Phil T. <ph...@mi...>]

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?
=20
Remember that Windows 2K/XP natively support these functions while on =
Win9x you need to supply an extra library to get the compatibility.
=20
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).
=20
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).
=20
Running dumpbin might show you whether your DLL is indeed expecting the =
wide character versions or not.  For example=20
=20
Phil

________________________________

From: gam...@li... on behalf of =
Andras Balogh
Sent: Mon 2/16/2004 01:55
To: gam...@li...
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=3D1356&alloc_id=3D3438&op=3Dclick
_______________________________________________
Gamedevlists-windows mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_id=3D555