Windows NT Systems Programming: Spring 1999

[ Home | Syllabus | Course Notes | Assignments | Search]

Dynamic Linked Libraries

Why DLLs

• Separation and encapsulation of functionality
• Can be changed without recompiling
• Saves Disks space for executables
• Save Primary Memory space
• NO real disadvantages

Separate Compilation

• The library is compiled and linked independent of the application using it
• Header files tell the compiler how to compile both the library functions and the application program
• Actually, static libraries also do this (iostream.h)
• But for DLL, there needs to be stub code which can do the DYNAMIC loading (instead of relying on the linking phase of the generation of the executable.
• The application need not be aware of the differences between a static library and a DLL.

Simple Example: Library Side

Exported Function (snd.cpp)

// snd.cpp

#include <windows.h>

#include "snd.h" 
void MultiHonk(DWORD iterations)
{
  UINT i;

  for (i=0; i<iterations; i++)
  {
    Beep(200, 50);
    Sleep(1000);
  }
}

// Header file for library side

// snd.h

extern "C"
{
  void MultiHonk(DWORD iterations); // plain old function prototype
}

• F1: C++ uses the same calling convention and parameter-passing techniques as C, but naming conventions are different because of C++ decoration of external symbols. By causing C++ to drop name decoration, the extern "C" syntax makes it possible for a C++ module to share data and routines with other languages.

The Glue (snd.def)

; snd.def

LIBRARY snd

EXPORTS
	MultiHonk

• F2: Library can export multiple function interfaces or can keep some private

// Used by "lib" command e.g.

lib -def:snd.def -machine:i386 -out:snd.lib

Application Code

// honker1.cpp

// No evidence of using a DLL
#include <windows.h>
#include <stdlib.h>
#include <iostream.h>

#include "sndlt.h" // same as snd.h above

VOID main(VOID)
{
  DWORD iterations;
  CHAR iterStr[100];

  cout << "Enter the number of beeps to produce: ";
  cin.getline(iterStr, 100);

  iterations=atoi(iterStr);

  // make the beeps
  MultiHonk(iterations);
}

Using DLLs

Normally, they are created and stored in known directories.

APP=honker1
NODEBUG=1

!include <ntwin32.mak>

$(APP).exe: $(APP).obj
	$(link) $(conlflags) $(ldebug) \
	  $(conlibs) snd.lib $(APP).obj \
	  -out:$(APP).exe

$(APP).obj: $(APP).cpp sndlt.h
	$(cc) $(cflags) $(cdebug) $(cvars) \
	  $(APP).cpp

RunTime vs LoadTime Linking

The above example was made easier by using Load Time Linking.

RUN TIME LINKING:

• allows the application to decide when (and if) to load the library.
• Can run even if library is missing
• no change in DLL code for this to be used - PURELY a application decision

E.G. Loading the MAPI.DLL e-mail functions in WORD

Application using RunTime Linking

// sndrt.h

void (*MultiHonk)(DWORD iterations);

// honker2.cpp

#include <windows.h>
#include <stdlib.h>
#include <iostream.h>

#include "sndrt.h"

VOID main(VOID)
{
  DWORD iterations;
  CHAR iterStr[100];
  CHAR modName[MAX_PATH];
  HINSTANCE sndHandle;

  cout << "Enter the number of beeps to produce: ";
  cin.getline(iterStr, 100);

  iterations=atoi(iterStr);

  // map snd.dll into process
  sndHandle=LoadLibraryEx("snd", NULL, 0);

  if (sndHandle == NULL)
  {
    cerr << "Sorry, unable to use DLL." << endl;
    return;
  }
  else
  {
    // load function name with address mapped from
    // snd.dll
    MultiHonk=(void (*)(DWORD))GetProcAddress(
      sndHandle, "MultiHonk");

    if (MultiHonk == NULL)
    {
      cerr 
        << "Sorry, MultiHonk function not in DLL."
        << endl;
      // release the DLL
      FreeLibrary(sndHandle);
      return;
    }
    else
    {
      GetModuleFileName(sndHandle, modName,
        MAX_PATH);
      cout << "Using DLL: " << modName
        << endl;

      // make the beeps
      MultiHonk(iterations);
      // release the DLL
      FreeLibrary(sndHandle);
    }
  }
}

• F3: Functions in DLL declared as pointers to functions
• F4: Last parameter is whether to call the entry point function (if exists)
• F5: Gets address of function in library
• F6: returns path to DLL file loaded (just for fun).

DLL Entry Points

• Normally the DLL contains a set of related functions
• In any case, you may want to execute some set up functions when the DLL is loaded
  (NOTE: Each Process using the same DLL will call the entry point once, this allows the DLL to set up state information for that process).
• Sort of like a constructor/destructor.

Simple Demonstration

// snd.cpp

#include <windows.h>

#include "snd.h"

BOOL WINAPI SndEntryPoint(HINSTANCE dllHandle,
  DWORD reason, LPVOID situation)
{
  CHAR buf[80];

  switch(reason)
  {
    case DLL_PROCESS_ATTACH:
      if (situation)
        wsprintf(buf, "DLL statically loaded.");
      else
        wsprintf(buf, "DLL dynamically loaded.");
      break;

    case DLL_THREAD_ATTACH:
      wsprintf(buf, "New thread starting.");
      break;

    case DLL_PROCESS_DETACH:
      if (situation)
        wsprintf(buf, "DLL released by system.");
      else
        wsprintf(buf, "DLL released by program.");
      break;

    case DLL_THREAD_DETACH:
      wsprintf(buf, "Thread terminating.");
      break;

    default:
      return FALSE;
  }

  MessageBox(NULL, buf, "DLL Info",
    MB_OK | MB_ICONINFORMATION);
  return TRUE;
}

void MultiHonk(DWORD iterations)
{
  UINT i;

  for (i=0; i<iterations; i++)
  {
    Beep(200, 50);
    Sleep(1000);
  }
}

• F7: Entry point function called when DLL is attached/detached to a process/thread, return value whether DLL succeeds/fails
• F8: enumerated type for the above reason for calling
• F9: whether load or run time linked

Memory Models for DLLs

• Local Variables: no problem
• Global Static and Dynamic - trickier (since DLL is shared).
  Four different Models
  • One per Process: DLL contains a global variable pointing to dynamically allocated memory
    could initialize/destroy in entry point function or by explicit call.
  • One per Thread: use Thread Local Storage (TLS)
    Create TLS when process attaches, entry point for thread attach places pointer in TLS
  • Multiple per process: (calling program keeps pointer to allocated memory)
  • One shared all processes: use file mapping for shared memory
    • Need to build own memory allocator
    • Need to synchronize access
    • normal global variables are possible using .bss and .data SECTIONS in the DEF file

Example of ADT "stack" DLL

// stack.h

typedef struct _stacknode
{
	int data;
	struct _stacknode *next;
} stacknode, *stack;

extern "C"
{
	void init(stack *s);
	void push(stack *s, int i);
	int pop (stack *s);
	void destroy(stack *s);
}

// stack.cpp

#include <windows.h>
#include "stack.h"

void init(stack *top)
{
  *top=0;
}

void push(stack *top, int value)
{
  stacknode *temp;

  temp = (stacknode *) GlobalAlloc(GPTR, 
    sizeof stacknode);
  temp->data = value;
  temp->next = *top;
  *top = temp;
}

int pop(stack *top)
{
  stacknode *temp;
  int value;

  if (*top == 0) 
    return 0;
  temp = *top;
  value = (*top)->data;
  *top = (*top)->next;
  delete temp;
  return value;
}

void destroy(stack *top)
{
  while (*top != 0);
    pop(top);
}

• F10: Pointer to stack is "owned" by the application, which can create many stacks at the same time
• F11: A call to "new" would fail in a DLL, allocates on the heap, can control the memory allocation
• F12: resides in FIxed block in memory, initially set to zero

Copyright chris wild 1999.
For problems or questions regarding this web contact [Dr. Wild].
Last updated: December 28, 1998.