A Question about Multiple Instances of a DLL ???

[Chris Boss]

I have a question about multiple instances of a DLL in a single
application. I think I understand this, but I want to make sure I
understand it correctly.


This is the scenerio :


(1) EXE calls a DLL's functions (lets call the DLL MainDLL.dll)
By using a INC file with declares, this forces Windows to
automatically load the DLL when the EXE is loaded and run.
This is instance #1 .

(2) A second DLL is also called by the EXE (declaring the functions
in an INC file) (lets call this DLL MyDLL2.dll). This second DLL
explicitly calls functions in the first DLL (MainDLL.dll).

My question is :

How many different Instances of MainDLL.dll does this create for
the EXE application ?

Does the second DLL's (MyDLL2.dll) calls into MainDLL.dll cause
Windows to initialize a second Instance of the DLL (MainDLL.dll) ?

If there are two instances of the DLL (mainDLL.dll), then do they have
different data segments for storing global variables defined in the
DLL ?



------------------

[Edwin Knoppert]

All in one instance i'm affraid..

Simple test, exchange a varptr and test the data.
If you can, to bad, no classes


------------------

[Chris Boss]

Edwin;

I would assume this would mean that the Global variables defined
in the DLL (mainDLL.dll) will be using the same data segment so
they will be the same no matter whether the calls are made by the
EXE into the DLL or by the second DLL calling it !



------------------

[Bern Ertl]

Chris,

It is my understanding that the whole advantage to the Dynamic
Link Library is that one and only one copy of the library is loaded
in memory and shared by whatever applications / threads require it.



------------------
Bernard Ertl

[Chris Boss]

Bern;

I am not talking about "copies" of the DLL !

There is only one copy of any single DLL loaded into memory ,
no matter how many applications loaded it. They all share the same
code segment for the DLL's code.

What I am talking about is an Instance !

Windows stores counter for each time the same DLL is loaded and
creates a new Instance of it each time. The new Instance shares the
code segment, but each Instances has its own unique data segment for
variable storage. This way each app that loads the DLL appears to
have its own unique copy of the DLL (at least the data part).

The question above is dealing with instances ! I need to know whether
the second DLL creates a new instance of the DLL, in which there is
a new data segment for variable data storage.



------------------

[Semen Matusovski]

Don't think that it's a big problem to have a common segment.

   #Compile Exe
   #Dim All
   #Register None
   #Include "Win32Api.Inc"

   Declare Function Func1 Lib "Dll1.Dll" As Long   
   Declare Function Func2 Lib "Dll2.Dll" As Long

   CallBack Function BtnProc

      MsgBox "Func1 = " + Str$(Func1)
      MsgBox "Func2 = " + Str$(Func2)


   End Function

   Function PbMain()
      Local hDlg As Long     
      Dialog New 0, "test", , , 100, 25, %WS_CAPTION Or %WS_SYSMENU To hDlg
      Control Add Button, hDlg, 101, "Test", 5, 5, 90, 15 Call BtnProc
      Dialog Show Modal hDlg

   End Function          

   #Compile Dll "Dll1.Dll"
   #Register None
   #Dim All
   #Include "Win32Api.Inc"

   Function Func1 Export As Long
      Dim x As Long
      ! LEA EAX, CommonData
      ! MOV x, EAX

      ReDim ca(0) As Long At x
      If ca(0) = 0 Then VirtualProtect ByVal x, ByVal 8, ByVal %PAGE_EXECUTE_READWRITE, 0: ca(0) = 1 '  FlushInstructionCache GetCurrentProcess, ByVal x, ByVal 8
      Incr ca(1): Function = ca(1)
 
   End Function

   Sub PlaceForCommonData
CommonData:
     ! DD 0, 0
   End Sub
           

   #Compile Dll "Dll2.Dll"
   #Register None
   #Dim All
   #Include "Win32Api.Inc"

   Declare Function Func1 Lib "Dll1.Dll" As Long
   
   Function Func2 Export As Long
      Function = Func1
   End Function

------------------
E-MAIL: [email protected]

[Kev Peel]

Chris;

I am sure that the DLL is only loaded once per process, any other DLLs are 'latched' on the that process and therefor use the same storage inside.

To clarify...

I tried an experiment with this, I created a calling program that sets a variable in DLL1 (set to 'hello'), then I used the program to call DLL2 that also calls DLL1 to ask for the value of that variable, it was 'hello' as I expected.

Regards,



------------------
Kev G Peel
KGP Software, Bridgwater, UK.
mailto:[email protected][email protected]</A> http://www.kgpsoftware.com

[Eric Pearson]

> I need to know whether the second DLL creates a
> new instance of the DLL, in which there is
> a new data segment for variable data storage.

Absolutely not. As far as I know, it is not possible for a process to have two instances of the same DLL.

-- Eric


[This message has been edited by Eric Pearson (edited June 19, 2001).]

[Mike Burns]

Taking Semen's program, as I understand it, there is only one instance
of d111.dll loaded. Accessing Func1 from d112.dll does not cause a second
instance or data area to be created for d111.dll.

Is there a scenario where a single exe (application) would
have multiple instances of the same dll active?

Mike



------------------

[Semen Matusovski]

Chris assumes that OS calls LibMain after each LoadLibrary.
I don't see any comments in MSDN, but experiments (at least, under Win2000) show that Windows calls LibMain "once".
So, there are no multiply instances in any meaning.

------------------
E-MAIL: [email protected]

[Dominic Mitchell]

On startup MainDLL.dll and MyDLL2.dll are implicitly loaded into the address space
of the exe and both have a usage count of one. Explicit loading of MainDLL.dll by
functions in MyDLL2.dll do not load a second instance of MainDLL.dll.
However, since MainDLL.dll is already mapped into the address space of the exe its
usage count will be incremented by calls to LoadLibrary and decremented by calls to
FreeLibrary. This means that asymmetrical use of LoadLibrary/FreeLibrary can lead
to MainDLL.dll being unmapped from the address space of the exe, a sure recipe for
a GPF.
Also, keep in mind that a dll owns nothing in Win32. Any memory allocated by the
dll is owned by the exe not the dll. In addition, the dll uses the stack of the
calling thread for any local variables that its functions might need.

PS
Just reread my post and realized it needs some clarification.
In the scenario described by Chris doing the following when the usage count of
MainDLL.dll is one should terminate the exe.

FreeLibrary GetModuleHandle("MainDLL.dll")

[This message has been edited by Dominic Mitchell (edited June 20, 2001).]

[Steve Mc Gregor]

I'm have several applications that use this logic and just one copy
of a DLL is loaded and all the changes made by any instance to DLL
variable is preserved for all other DLLs.

I use this struct when I use the SQLTools from DLL and the main exe
I initialize the SQLTools at the main exe then from any DLL I can
call any function. I also have exported some functions in the main
exe and called them from any DLL loaded by the main exe. So I can
interact with my DLLs and the main Exe.

Steve


------------------

[Eric Pearson]

> I don't see any comments in MSDN, but experiments (at
> least, under Win2000) show that Windows calls LibMain "once".

From Win32.HLP under LoadLibrary:

If the module is a DLL not already mapped for the calling process, the system calls the DLL's DllEntryPoint function with the DLL_PROCESS_ATTACH value.

So if the DLL is already mapped into the process, LibMain (DLLEntryPoint) is not called again.

-- Eric


------------------
Perfect Sync Development Tools
Perfect Sync Web Site
Contact Us: mailto:[email protected][email protected]</A>

[Chris Boss]

Dominic;

LoadLibrary isn't used in this instance. Both the EXE and the second DLL
reference the MainDLL.dll by using declares in an include file.

Is this "safe" !

The reason I ask is, a number of EZGUI users are writing reusable code
in the form of a DLL, which calls the EZGUI DLL. Then when they write
an EZGUI app, their EXE (the app itself) will make calls into the
EZGUI DLL and it will make calls into a DLL which also makes calls
into the EZGUI DLL.

I need to know if this is OK !

I never tried such a thing myself, but others are doing this.

EZGUI doesn't initialize anything in LibMain. It has an entrance
function which initializes all Global variables and Global Arrays,
which is called only once by the app itself (EXE). Any calls made
by DLLs won't call this entrance function.



------------------

[Eric Pearson]

> Is this "safe" !

YES.

-- Eric

[Cecil Williams]

Chris,

Eric hit the nail on the head. The app EXE implicitly loads the
apps DLL and the EZGUI DLL if it's not already loaded by another
process, and increments the reference count.
Now, when the EXE terminates, the apps DLL count would go to
zero(0) and Windows would unload the app DLL from memory and
the EZGUI DLL would remain in memory as long as it's reference
count is one or more. If the EZGUI DLL count goes to zero(0),
it's history also.

On another note pertaining to explicitly loading libraries,
calling FreeLibrary does not affect other processes using the
same library module.

Hope this helps!!

Cheers,
Cecil

------------------


[This message has been edited by Cecil Williams (edited June 20, 2001).]