Re: VB and dll's

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance



expvb wrote:
"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.



That sounds right regarding calling functions after a reload. I don't have the Visual Studio Tools, I'll have to get that one.

Do you think that if the operating system is not showing a dll as open that it may be loaded anyway?
.


Quantcast