Re: VB and dll's
- From: NYTRA <nytra@xxxxxxxx>
- Date: Thu, 13 Jul 2006 19:10:39 GMT
expvb wrote:
"expvb" <nobody@xxxxxxx> wrote in message news:eYKD1fppGHA.148@xxxxxxxxxxxxxxxxxxxxxxx
"NYTRA" <nytra@xxxxxxxx> wrote in message news:tXttg.56332$W97.43134@xxxxxxxxxxxxxxxxxxxxxxx
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.
It maybe not present in some versions of Visual Studio 6.0. I know that it is present in the professional and enterprise editions.
Do you think that if the operating system is not showing a dll as open that it may be loaded anyway?
I am not sure. I also don't know what dllshow views, or if the name was used by multiple vendors. Try this software, but I haven't used myself:
http://www.teamcti.com/pview/prcview.htm
I just tried PrcView on one of my apps. It shows loaded DLL's, not dependency information about DLL's which maybe loaded or not. When my App starts, it doesn't call any function in a DLL that I made, and that DLL doesn't show in the modules list. After making some activities, the app calls a function in the DLL and it shows up in PrcView. So it shows the actual DLL's used by the application. If the application unloaded the DLL, it will no longer appear in the list, but you have to reopen the modules list to see the changes.
If you see the DLL loaded all the time until your application terminates, then the reason of the slowness is that part of the DLL was swapped to disk. DLL's can be loaded and later parts of it are swapped to disk. Swapped to disk does not mean the DLL was closed.
Swapped to disk as in the pagefile.sys file? I understand that part, that's ok. It's when the OS shows them as open initially, but after a while they are not shown as open. With the program still running and nothing else going on with the machine.
.
- References:
- VB and dll's
- From: NYTRA
- Re: VB and dll's
- From: expvb
- Re: VB and dll's
- From: NYTRA
- Re: VB and dll's
- From: expvb
- Re: VB and dll's
- From: NYTRA
- Re: VB and dll's
- From: expvb
- Re: VB and dll's
- From: expvb
- VB and dll's
- Prev by Date: Re: VB and dll's
- Next by Date: Re: Validating dates
- Previous by thread: Re: VB and dll's
- Next by thread: Re: VB and dll's
- Index(es):