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

[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.

--
Thanks,
Bruce

[William DePalo [MVP VC++]]

"Bruce" <bw*****@nospam.nospam> wrote in message
news:O6**************@TK2MSFTNGP12.phx.gbl...

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.
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.

What kind of issues?

Regards,
Will

[Bruce]

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.

--
Thanks,
Bruce
"William DePalo [MVP VC++]" <wi***********@mvps.org> wrote in message
news:eG**************@TK2MSFTNGP14.phx.gbl...

"Bruce" <bw*****@nospam.nospam> wrote in message
news:O6**************@TK2MSFTNGP12.phx.gbl...

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.

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.

What kind of issues?

Regards,
Will

[William DePalo [MVP VC++]]

"Bruce" <bw*****@nospam.nospam> wrote in message
news:eo**************@tk2msftngp13.phx.gbl...

Thanks for the reply.
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.

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

[Doug Forster]

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

"Bruce" <bw*****@nospam.nospam> wrote in message
news:eo**************@tk2msftngp13.phx.gbl...

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.

--
Thanks,
Bruce
"William DePalo [MVP VC++]" <wi***********@mvps.org> wrote in message
news:eG**************@TK2MSFTNGP14.phx.gbl...

"Bruce" <bw*****@nospam.nospam> wrote in message
news:O6**************@TK2MSFTNGP12.phx.gbl...

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.

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.

What kind of issues?

Regards,
Will