[comp.windows.ms.programmer] DLL memory handling

jim@newmedia.UUCP (Jim Beveridge) (01/25/91)

The WEP (windows exit procedure) for my DLL tries to free the 
global memory that it had allocated over the course of time.  
Unfortunately, the moment I try and deference the first element
in the linked list, the entire system hangs.

If the DLL is explicitly loaded, the WEP works properly.  
If the DLL was implicitly loaded, all global memory appears 
to be freed _before_ the WEP is called.  This is a problem, 
because I need some information out of global memory to 
properly shut down the DLL.

How can I work around this problem?

(One suggestion has been to use a local heap instead of 
the global one.)

	Thanks, Jim

--
"If I wanted a .sig, I would have written one."

johnc@plxsun.uucp (John Ciccarelli) (01/26/91)

In article <433@newmedia.UUCP> jim@newmedia.UUCP (Jim Beveridge) writes:
>The WEP (windows exit procedure) for my DLL tries to free the 
>global memory that it had allocated over the course of time.  
>Unfortunately, the moment I try and deference the first element
>in the linked list, the entire system hangs.
>
>If the DLL is explicitly loaded, the WEP works properly.  
>If the DLL was implicitly loaded, all global memory appears 
>to be freed _before_ the WEP is called.  This is a problem, 
>because I need some information out of global memory to 
>properly shut down the DLL.


We had WEP problems too.  Here's what Microsoft ONLINE said;
note especially the restrictions mentioned in items 2 and 4.

-------- begin forwarded message from Microsoft ONLINE -------

Q66360 Windows Exit Procedure (WEP) for a Dynamic Link Library
Microsoft Windows Software Development Kit (WINSDK)
3.00
MS-DOS

Summary:

The window exit procedure (WEP) is designed to be the last function
called in the last reference to a DLL before the DLL is removed from
memory. In the WEP, the DLL performs any necessary clean up.

In Windows version 3.00, some details regarding the WEP are not
completely documented or tested. This article addresses four of these
issues and provides guidance for using a WEP.

More Information:

1. A WEP must be declared in the EXPORTS section of the DEF file for
   the DLL. For example:

      WEP  @1  RESIDENTNAME

   The keyword RESIDENTNAME makes the name of the function (WEP)
   resident at all times. It is NOT necessary to use the ordinal
   reference 1. This clarifies information presented on Pages 20-25
   through 20-27 of the "Microsoft Windows Software Development Kit
   Guide to Programming."

   There is a benefit to using the RESIDENTNAME option. When the
   Windows KERNEL wants to remove the DLL, it calls the WEP function
   by name. In low memory situations, it is possible for the DLL's
   nonresident name table to be discarded from memory. If so, the
   KERNEL must load the table to determine if a WEP function was
   declared for the DLL. The use of the RESIDENTNAME option forces
   Windows to keep the name entry for the WEP in memory at all times
   that the DLL is in use.

   Similarly, the WEP should be placed in a fixed code segment. If
   instead it is placed in a discardable segment, in low memory
   situations, Windows must load the WEP segment back from disk so
   that the WEP function can be called before the DLL is discarded.

   The following is the proper declaration of a WEP in a DLL:

      int FAR PASCAL WEP (int iParam)
      {
         return 1;
      }

   In the "Microsoft Windows Software Development Kit Guide to
   Programming," the WEP declarations in section 20.3.1 on page 20-20
   and section 20.6.3 on page 20-41 are incorrect. Change "VOID" to
   "int" and each WEP procedure returns the value of 1.

2. If a DLL is explicitly loaded via LoadLibrary(), its WEP will be
   called when the DLL is freed, via FreeLibrary(). If the DLL is
   implicitly loaded, the WEP may or may not be called (in Windows
   version 3.00). You can observe this behavior with CVW if the DLL
   has an initialization routine so that CVW is aware of the DLL's
   presence in the system. Please refer to section 20.3.1, page 20-21,
   in the guide to programming for more information on initializing a
   DLL.

3. If an application that uses a DLL closes properly, but leaves
   Windows in an unstable state, there may be a problem with the way
   the WEP is declared. As stated in item 1 above, the WEP should be
   placed in a fixed code segment. If the WEP is discarded under low
   memory conditions, the application may fail with an unrecoverable
   application error (UAE).

   In the DEF file for the DLL, the name listed in the LIBRARY
   statement must be in uppercase letters and must match the name of
   the DLL file.

4. The WEP may not contain any code that expects data from the DLL's
   data segment or from the calling application's stack because these
   segments may already have been discarded when the WEP is called.
   For this reason, if there is crucial clean up that the DLL must
   perform, create an explicit clean up function that the application
   can call before termination.

In summary, DLLs for Windows 3.00 require that a WEP be present. If
you choose to go without one, we cannot guarantee that your
application will run properly under future versions of Windows.

Keywords:  docerr

-------------------- end forwarded message ------------------
John Ciccarelli
Plexus Software, 5200 Great America Pkwy, Suite 200, Santa Clara CA 95054
email: ...sun!plx!johnc,  voice: 408-982-4842,  fax: 408-727-4864