For our purposes, a module identifies an executable file that is loaded into memory. Typically, this is a dll or exe where a dll can be one of the derivative forms like ocx or vbx and an exe can be one of the derivative forms like com or scr. In some programming languages the line gets fuzzier since the vocabulary gets overloaded. For instance, Visual Basic and the MSOffice products use the term “module” to refer to what is essentially a file in C/C++ even though the final result is an exe, dll, etc. which is of course a “module” in operating system and Paul Bunyan speak. (Incidentally, that’s why the COM interface simply allows the programmer to define Module and File interchangeably.)

When we say “module” in the context of say “module name” we are referring to the text string that comes back from the Win32 function call GetModuleFileName. Sometimes this is Excel.exe, and other times it may even be the name of the Visual Basic IDE (e.g. VB5.exe) when debugging in interpreted mode.

A closely related topic is the idea of variables or settings that are said to be per process per module. We use static variables in our code that are kept in a per-process data segment. These variables govern things like component and context defaults, initialization settings, handles to synchronization objects, fail counts, pointers to user supplied exception handling routines, etc. Each module (in the operating system sense) gets its own copy of these variables and on a per-process basis. Thus a DLL that is used by process A and process B will ultimately have two sets of variables in memory. This is what allows a single DLL to have, for example, one default context while executing in process A’s space and another while executing in process B’s.