Hallo Jonathan!

Antwort auf eine Message von Jonathan de Boyne Pollard an Denis Tonn:

 JdBP> How are DLLs loaded and unloaded ?  In particular, how does OS/2
 JdBP> Warp keep track of which DLL_InitTerm functions it needs to call
 JdBP> when executing DosFreeModule ?  It seems to me that there is a

whats the problem? theoretical a simple recursive logic:

  unloadDLL(...)
  {
   list_of_required_dlls *list;
   for all elements in list do unloadDLL(element)
   unload from memory
   done
  }

and the list of required dlls is known, since when a dll is loaded, warp
can look into the file header and see what other dlls have to be loaded...

eq:

 yourDll gets loaded into memory
 yourDLL required (eq) CRT
 CRT gets loaded into memory
 CRT requires (eq) DosXXXX
 DosXXX gets loaded
 DosXXX requires nothing
 DosXXX::initTerm
 CRT::initTerm
 yourDLL:initTerm


now, there is a small problem here. more, its a bug in OS2 since (at least)
V2.0 (i have never tested it under 1.x).

the order in which the dlls gets unloaded depends on a lot of other things.
it depends eq. if the dll was already in memory when yourDll is loaded into
memory. 

and (at least) under V2.x the bug was heavy. sometime a DLL is unloaded
before the clients are unloaded. resulting in crashes. eq:

 CRT::initTerm
 CRTunload
 yourDLL::initTerm 
   still uses CRT calls resulting in crashes ...

VACPP solves this problem by doing their own refcounting 

 JdBP> *return* from those callbacks into ring 0 ?  And how does it cope
 JdBP> with the pathological, but permissible, case that the InitTerm
 JdBP> function of a module may itself call DosLoadModule or DosFreeModule
 JdBP> ?  Or the equally pathological case that the InitTerm function,

mh. have you tried to call these functions in dllinitterm?

here is one newer (1996) and a older mail regarding the unloading problem:

#: 172179 S4/IBM VisualAge C++
    31-Jan-96  02:11:56
Sb: #Destructors at exit(int)
Fm: ROGER PETT [IBM] 73251,1733
To: Dean Roddey 72170,1614 (X)

OS/2 is supposed to run DLL termination in the opposite order to the DLL
initialization.  Since static object destructors and CRT termination are done
in the DLL termination ocde, it is a problem if this does not happen.

Unfortunately, there *are* conditions where the DLL termination can run "out
of order".  It's a known OS/2 bug, and I understand that it is not fixable
without some rather major surgery (i.e. it's likely to introduce new bugs!).
Personally, I'd rather have the devil I know, since you can program your way
around it.  For example:
  In VAC++, the CRT exposes both _CRT_init() and _CRT_term(), and you should
call both, regardless of whether you statically or dynamically bind to the
runtime.   This is a change from C Set++.  We count the number of times the
runtime is initialized, and only completely shut down the runtime when the
number of _CRT_term() calls match the number of _CRT_init() calls.  This
insures the runtime stays "alive" until all its users have
terminated.  We get
away with this because the OS doesn't immediately unload the DLL after running
the DLL termination.

Roger..

#: 139997 S4/IBM C SET ++
    17-Apr-95  17:16:00
Sb: #139919-DLL's + CRT + traps.
Fm: ROGER PETT [IBM] 73251,1733
To: mario semo 100414,1025

Mario, I think you have been bitten by the OS/2 bug with garbles the unload
order of DLLs.  If the runtime DLL is terminated before your DLL, the printf()
will trap.  To confirm, remove the static SharedClass object.  If the abend
goes away - youve found the culprit.  The only workaround we have for this
right now is to write your own DLL Init/Term routine, and not run the static
destructors (the __ctordtorTerm() call).  We will have a workaround for this
in version 3.0 of the compiler....

Roger...



Servus, Mario!

--- FleetStreet 1.21 PR#2