Is there a Limit to the number of DLLs that can be loaded by 32 bit Applicatons on Windows 98?

  • Thread starter Thread starter Bruce
  • Start date Start date
B

Bruce

I thought that I had read somewhere before about a limit to the number of
DLL's that could be loaded by a 32 bit application when it is run on Windows
98/ME operating systems.

But I can't seem to find the document in MSDN.

Our application uses Crystal Reports 9 and we have issues on 98 SE and ME
that seem to be dependent on the number of DLL's that are currently loaded
by the application.
 
Bruce said:
I thought that I had read somewhere before about a limit to the number of
DLL's that could be loaded by a 32 bit application when it is run on
Windows 98/ME operating systems.

But I can't seem to find the document in MSDN.
Click to expand...

Well, you won't find something that says "you can load at most 'n'
libraries" because there is no such hard and fast rule.
Our application uses Crystal Reports 9 and we have issues on 98 SE and ME
that seem to be dependent on the number of DLL's that are currently loaded
by the application.
Click to expand...

What kind of issues?

Regards,
Will
 
Thanks for the reply.

Our application is a VC++ 7.1 unmanaged application. We have some new pieces
that we call that were written in C# that we call through a C++ MFC mixed
mode DLL. This functionality is delay-loaded so we don't have the dot net
overhead unless the functionality is actually used. Although we get the same
symptoms if delay-loading of this dll is disabled.

We also have a mail module in our application that uses mapi to send mail.

The symptoms that we get vary. But they do seem to be related to the number
of DLL's that are currently loaded in the application. Generally it will be
that crystal reports says it can't find on of it's u2*.dll's, unable to
create the report viewer ActiveX control or login errors connecting to the
database.

Non of these errors ever occur on W2K or WXP, only on W98SE and WME.

The reports work fine until a feature is accessed that loads more dll's into
the process space, such as loading mapi in the unmanaged C++ code or doing
certain things in the C# code such as getting a list of SQL servers using
SQLDMO.

Once the failing condition is reached, it cannot be corrected without
exiting the application, sometimes even rebooting is required.

I have done extensive remote debugging on the computer with a debug build
and the only commonality that I can come up with is the number of dll's that
are currently loaded when the error occurs.

Also, as long as I stay away from the program's functionality that loads the
extra dll's, the reports work fine no matter how many times I run them.
 
Bruce said:
Thanks for the reply.
Click to expand...

You are welcome.
The symptoms that we get vary. But they do seem to be related to the
number of DLL's that are currently loaded in the application. Generally
it will be that crystal reports says it can't find on of it's u2*.dll's,
unable to create the report viewer ActiveX control or login errors
connecting to the database.

Non of these errors ever occur on W2K or WXP, only on W98SE and WME.

The reports work fine until a feature is accessed that loads more dll's
into the process space, such as loading mapi in the unmanaged C++ code or
doing certain things in the C# code such as getting a list of SQL servers
using SQLDMO.
Click to expand...

A DLL is just a library that gets bound late.

Loading one does require resources - like virtual memory, and "things" do
happen when one is loaded (i.e. any DLL can have a DLLMain() that does
non-trivial or even illegal things. Some DLLs allocate thread-local storage
(see TlsAlloc() et al) and there is a limit of 80 TLS slots on 98/Me. So,
what I am saying is not that you are not exhausting some finite resource,
just that there is a priori no upper bound to the number of DLLs that you
can load and be guaranteed to have sufficient resources below, and run out
above.

Regards,
Will
 
Hi Bruce,

I haven't come across your particular problem, but it doesn't surprise me.
We had a similar problem that only happened in Win9x and finally decided it
was due to holding too many active window handles (delphi's default
paradigm). We changed the program to only create windows as needed and the
problem went away. Completely undocumented and I imagine you could well be
hitting some other undocumented resource limit.

Cheers

Doug Forster
 
Back
Top