Re: VB and dll's

"NYTRA" <nytra@xxxxxxxx> wrote in message
news:m3ttg.56315$W97.653@xxxxxxxxxxxxxxxxxxxxxxx
expvb wrote:
"NYTRA" <nytra@xxxxxxxx> wrote in message
news:lCrtg.85319$3B.39110@xxxxxxxxxxxxxxxxxxxxxxx

Hello,
I have a question regarding how VB calls dll files and loads/unloads them
from memory. If this isn't the correct forum, please point me to the
correct one. I'm not really a programmer, please forgive me if I don't
know what I'm doing. :)

That being said, we have an app that was written in VB that loads a
number of dll's. After a period of inactivity in the program (maybe about
10 minutes) some of these dll's unload. Not all, but most of them. This
is causing significant delays within the app when the dll's need to be
reloaded.

This is what the software vendor says regarding the way the dll's they
created behave:

Objects are closed (or destroyed) under the sole control of Windows.
Windows holds objects in memory in case they need to be used again. If
an object is not needed for period of time or the system runs low on
resources the object is closed to free up space for active processes.

My question is, is there a way to make particular dll's stay open until
the program is closed? I would like to have them all load and stay
loaded, not just close on their own.

BTW, the system running low on resources is not an issue.

Thanks,
Walt



Are you sure they are unloaded or just swapped to disk? Windows does not
unload DLL's until the application that explicitly used them calls
FreeLibrary(). VB6 to my knowledge, does not do that until the
application terminates. You can't call FreeLibrary() yourself, let VB6 do
it.

One solution I suggest is to call a function in the DLL or check a
property in a Timer that has no side effect on the application. However,
DLL's are composed of sections to allow for fast DLL loading and save
memory in case you don't need all the functionality that the DLL
provides. For example, if a DLL provides graphics manipulation for 2D and
3D, the developer can put 3D functionality in a separate section just in
case you don't need to use it, so you will be saving memory. Some of
these sections are marked to load immediately when the DLL is first
loaded and some are on demand. The on demand sections are loaded
automatically when you call a function that reside on these sections.

In the example above, if you use 2D and 3D functionality, but only
accessing 2D in a Timer, the system might swap the 3D section into disk.

There maybe utilities out there that let you view DLL's and the sections
within and which section a function resides on, but unless someone
suggest a tool to you, it maybe a long research. Here is one tool, but I
am not sure it does that:

http://www.heaventools.com/








Thank you for the quick reply. I checked out the program you suggested,
looks good but I didn't see anything in there regarding FreeLibrary.

Perhaps I'm just not fully aware how these files work regarding being
unloaded or swapped to disk. Initially I was looking to see if particular
dll's are "open' as displayed in the Windows 2000 Computer
management\Shared folders\open files utility.

I have also used another utility called dllshow that displays processes
and open dll and ocx files that are associated with them. This program
yields the same results as the built-in Windows utility.

Is being open the same as being loaded. These files aren't being shown as
open all the time, but when performing specific functions within the
program then the reappear as open. How would I get these files to be shown
as open all the time until the program closes?

Thanks,
Walt

I am not sure about the programs that you were using, please try "Process
Viewer" from Visual Studio Tools in the start menu. Click on the process,
then "Memory Detail" button. That button will be grayed out until the
Process Viewer has finished taking a snapshot. This could take a minute or
two. The drop down list in "Memory Detail" shows the list of loaded DLL's.

I don't think VB6 unload DLL's after a period of inactivity because it
doesn't make any sense to do so. If it does, it will lead to a loss of data
that the DLL maintains, and calling functions after a reload may have a
different result than expected.





.

Loading