Re: VB and dll's
- From: "Tony Proctor" <tony_proctor@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Thu, 20 Jul 2006 11:51:12 +0100
Under the covers ActiveX/COM DLLs are loading with LoadLibrary, and released
with FreeLibrary. The only difference between such DLLs and normal
non-ActiveX ones is that COM-specific interfaces are exposed by them.
The data associated with an instance of an object from an ActiveX DLL may be
resident in memory or in the paging file. There's little control over this,
and it's generally best left to the O/S to handle for you. The best way to
guarantee it being in real memory is to make sure you have lots of it.
The code for a DLL is only unloaded when all processes have dropped their
references to it. Within each process, the DLL reference is not dropped
until all associated object instances have been destroyed, and even then the
VB run-time may get lazy about it and only drop it when it feels it needs
to. Check out the 'Retain in Memory' project option on VB DLLs. Setting this
will prevent the code from being unloaded by additionally raising the
reference count on the DLL.
An application can also prevent DLL code from being unloaded by creating an
instance of one of its classes, and hanging on to it - i.e. storing it in a
global variable.
When the code for a DLL is unloaded, it does not affect the paging file. All
executable code is paged in from the respective EXE/DLL file, and cannot be
modified (unless being debugged) so doesn't have to be paged back. When code
is debugged, some pages may be changed to 'Copy on Write' in order to make
sure that a break point only modifies the virtual page in one particular
process and not in every process using that same DLL.
Tony Proctor
"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
.
- Prev by Date: Re: VB.NET 2002 question from complete and utter newbie to programming
- Next by Date: Re: *.RES file and compiling problem
- Previous by thread: Re: Maximum size of resource string
- Next by thread: VB6 sstab
- Index(es):
Relevant Pages
|
