Thread: [GD-Windows] Loading new DLLs on old Windows

Brought to you by: vexxed72

gamedevlists-windows

[GD-Windows] Loading new DLLs on old Windows

From: Andras B. <bn...@ma...> - 2004-02-10 17:34:51

MSDN says:

"Windows Me/98/95: If you are using LoadLibrary to load a module that
contains a resource whose numeric identifier is greater than 0x7FFF,
LoadLibrary fails. If you are attempting to load a 16-bit DLL directly
from 32-bit code, LoadLibrary fails. If you are attempting to load a
DLL whose subsystem version is greater than 4.0, LoadLibrary fails. If
your DllMain function tries to call the Unicode version of a function,
LoadLibrary fails."

Now, I believe that my DLLs' subsystem version is greater than 4.0
(how can I check?). How can I make it work on Win95/98/ME?? Is there
a linker option? Or some other workaround?


Thanks,

Andras

RE: [GD-Windows] Loading new DLLs on old Windows

From: Simon O'C. <si...@sc...> - 2004-02-11 00:22:03

Hi Andras,


The subsystem for a DLL is controlled by the /SUBSYSTEM: linker option in
your project settings.


For a DLL project, this will be set to /SUBSYSTEM:WINDOWS.


The /SUBSYSTEM: linker option has an **OPTIONAL** subsystem version
parameter (e.g. /SUBSYSTEM:WINDOWS,5.01). This optional parameter allows you
to specify the _minimum_ OS version that the DLL requires to be run. 

You'll find a list of OS version numbers in the documentation for
OSVERSIONEX. Some examples are:
Windows 95:    4.0
Windows 98:    4.10
Windows ME:    4.90
Windows 2000:  5.0
Windows XP:    5.1 (5.01)

Note that the OS version number comes as two parts, major (4, 5 etc) and
minor (0, 10, 90, 1 etc). The point isn't a decimal point so 5.1 is the same
as 5.01 (the "minor" number is 1).


If you (or your development tools) do *not* specify the optional version
parameter at the end of the /SUBSYSTEM:WINDOWS option, a default subsystem
of 4.00 will be used, regardless of your development tool or OS. [NB: only
for x86  code targets, for Itanium code targets this is 5.01]

So a DLL created with Visual Studio .NET 2003 on a WindowsXP machine for
example will still have a subsystem of 4.00.


The only time you'll encounter a DLL under Win32 OSes that has a subsystem
that is different than 4.00 is if that DLL absolutely requires that version
of Windows.


You can view the subsystem of a DLL using Dependency Walker (it comes with
the platform SDK, depends.exe). DUMPBIN should tell you this too.


To change the subsystem of an existing DLL that you don't have the
sourcecode to (i.e. when you aren't able to alter the /SUBSYSTEM option),
you can change it using EDITBIN.


So in short, all that part of the documentation is saying is "if the DLL
specifies that it needs a newer version of Windows than the one currently
installed (if 9x) then the LoadLibrary() call will fail".


HTH

Cheers,

Simon O'Connor
Programmer @ Acclaim
& Microsoft DirectX MVP  

> -----Original Message-----
> From: gam...@li... 
> [mailto:gam...@li...] On 
> Behalf Of Andras Balogh
> Sent: 10 February 2004 16:31
> To: gam...@li...
> Subject: [GD-Windows] Loading new DLLs on old Windows
> 
> MSDN says:
> 
> "Windows Me/98/95: If you are using LoadLibrary to load a 
> module that contains a resource whose numeric identifier is 
> greater than 0x7FFF, LoadLibrary fails. If you are attempting 
> to load a 16-bit DLL directly from 32-bit code, LoadLibrary 
> fails. If you are attempting to load a DLL whose subsystem 
> version is greater than 4.0, LoadLibrary fails. If your 
> DllMain function tries to call the Unicode version of a 
> function, LoadLibrary fails."
> 
> Now, I believe that my DLLs' subsystem version is greater 
> than 4.0 (how can I check?). How can I make it work on 
> Win95/98/ME?? Is there a linker option? Or some other workaround?
> 
> 
> Thanks,
> 
> Andras
> 
> 
> 
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004 Premiere 
> Conference on Open Tools Development and Integration See the 
> breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> http://www.eclipsecon.org/osdn
> _______________________________________________
> Gamedevlists-windows mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=555
> 
> ---
> Incoming mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.572 / Virus Database: 362 - Release Date: 27/01/2004
>  
> 

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.572 / Virus Database: 362 - Release Date: 27/01/2004

Re: [GD-Windows] Loading new DLLs on old Windows

From: Andras B. <bn...@ma...> - 2004-02-11 18:31:08

Ah, thanks! Huge amount of info there! You were right, my DLLs are all
having subversion 4.0. So my problem is probably somewhere else..

Thanks again,


Andras


Wednesday, February 11, 2004, 1:21:44 AM, Simon O'Connor wrote:


> Hi Andras,


> The subsystem for a DLL is controlled by the /SUBSYSTEM: linker option in
> your project settings.


> For a DLL project, this will be set to /SUBSYSTEM:WINDOWS.


> The /SUBSYSTEM: linker option has an **OPTIONAL** subsystem version
> parameter (e.g. /SUBSYSTEM:WINDOWS,5.01). This optional parameter allows you
> to specify the _minimum_ OS version that the DLL requires to be run.

> You'll find a list of OS version numbers in the documentation for
> OSVERSIONEX. Some examples are:
> Windows 95:    4.0
> Windows 98:    4.10
> Windows ME:    4.90
> Windows 2000:  5.0
> Windows XP:    5.1 (5.01)

> Note that the OS version number comes as two parts, major (4, 5 etc) and
> minor (0, 10, 90, 1 etc). The point isn't a decimal point so 5.1 is the same
> as 5.01 (the "minor" number is 1).


> If you (or your development tools) do *not* specify the optional version
> parameter at the end of the /SUBSYSTEM:WINDOWS option, a default subsystem
> of 4.00 will be used, regardless of your development tool or OS. [NB: only
> for x86  code targets, for Itanium code targets this is 5.01]

> So a DLL created with Visual Studio .NET 2003 on a WindowsXP machine for
> example will still have a subsystem of 4.00.


> The only time you'll encounter a DLL under Win32 OSes that has a subsystem
> that is different than 4.00 is if that DLL absolutely requires that version
> of Windows.


> You can view the subsystem of a DLL using Dependency Walker (it comes with
> the platform SDK, depends.exe). DUMPBIN should tell you this too.


> To change the subsystem of an existing DLL that you don't have the
> sourcecode to (i.e. when you aren't able to alter the /SUBSYSTEM option),
> you can change it using EDITBIN.


> So in short, all that part of the documentation is saying is "if the DLL
> specifies that it needs a newer version of Windows than the one currently
> installed (if 9x) then the LoadLibrary() call will fail".


> HTH

> Cheers,

> Simon O'Connor
> Programmer @ Acclaim
> & Microsoft DirectX MVP

>> -----Original Message-----
>> From: gam...@li...
>> [mailto:gam...@li...] On
>> Behalf Of Andras Balogh
>> Sent: 10 February 2004 16:31
>> To: gam...@li...
>> Subject: [GD-Windows] Loading new DLLs on old Windows
>>
>> MSDN says:
>>
>> "Windows Me/98/95: If you are using LoadLibrary to load a
>> module that contains a resource whose numeric identifier is
>> greater than 0x7FFF, LoadLibrary fails. If you are attempting
>> to load a 16-bit DLL directly from 32-bit code, LoadLibrary
>> fails. If you are attempting to load a DLL whose subsystem
>> version is greater than 4.0, LoadLibrary fails. If your
>> DllMain function tries to call the Unicode version of a
>> function, LoadLibrary fails."
>>
>> Now, I believe that my DLLs' subsystem version is greater
>> than 4.0 (how can I check?). How can I make it work on
>> Win95/98/ME?? Is there a linker option? Or some other workaround?
>>
>>
>> Thanks,
>>
>> Andras
>>

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

From: Andras B. <bn...@ma...> - 2004-02-12 18:14:50

My program supports dynamic loading of plugins. Every plugin
represents a class, and resides in a separate DLL. Instead of
exporting the class itself, I only export a factory function and
provide a header file with the declaration of the pure virtual base
class (ie. the interface). At runtime, I load the DLL and call the
exported factory function, which instances an object and returns a
pointer to the base class.

This architecture works like a charm on most machines. However, on
some configurations, my program reports the following: "Error Code
1114: A dynamic link library (DLL) initialization routine failed."

But I have no clue why. Do I have to use DllMain? MSDN says it's only
an optional entrypoint.. My DLLs are dynamically linked to the C/CPP
run-time libraries.


Thanks,

Andras

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

From: Jon W. <hp...@mi...> - 2004-02-12 20:14:38

Typically this means that you're linking with a DLL that doesn't exist, or
you're calling UNICODE functions without unicode support, or you're plain
running out of memory. Do you have one of the machines available for
debugging? WinDbg sometimes helps in debugging these things.

Cheers,

			/ h+


-----Original Message-----
From: gam...@li...
[mailto:gam...@li...]On Behalf Of
Andras Balogh
Sent: Thursday, February 12, 2004 4:21 AM
To: gam...@li...
Subject: [GD-Windows] DLL initialization (was: Loading new DLLs on old
Windows)


My program supports dynamic loading of plugins. Every plugin
represents a class, and resides in a separate DLL. Instead of
exporting the class itself, I only export a factory function and
provide a header file with the declaration of the pure virtual base
class (ie. the interface). At runtime, I load the DLL and call the
exported factory function, which instances an object and returns a
pointer to the base class.

This architecture works like a charm on most machines. However, on
some configurations, my program reports the following: "Error Code
1114: A dynamic link library (DLL) initialization routine failed."

But I have no clue why. Do I have to use DllMain? MSDN says it's only
an optional entrypoint.. My DLLs are dynamically linked to the C/CPP
run-time libraries.


Thanks,

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
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_id=555