MakeProcInstance doesn't do anything.
#define MakeProcInstance(lpProc,hInstance) (lpProc)
What's the point of a macro that doesn't do anything?
It did something back in 16-bit Windows.
Recall that in 16-bit Windows, the
was the mechanism for identifying a data segment;
i.e., a bunch of memory that represents the set of variables
in use by a module.
If you had two copies of Notepad running, there was one copy of
the code but two sets of variables (one for each copy).
It is the second set of variables that establishes the second
copy of Notepad.
When you set up a callback function, such as a window procedure,
the callback function needs to know which set of variables it's
being called for.
For example, if one copy of Notepad calls
EnumFonts and passes a callback function,
the function needs to know which copy of Notepad it is running in
so that it can access the correct set of variables.
That's what the
MakeProcInstance function was for.
The parameters to
MakeProcInstance are a function pointer
and an instance handle.
MakeProcInstance function generated code on the fly
which set the data segment register equal to the
instance handle and then jumped to the original function pointer.
The return value of
MakeProcInstance is a pointer to that
dynamically-generated code fragment
(known as a thunk),
and you used that code fragment as the function pointer whenever
you needed another function to call you back.
That way, when your function was called, its variables were properly
When you no longer needed the code fragment,
you freed it with the
Those who have worked with ATL have seen this sort of code fragment
generation already in the
The operation is entirely analogous with
You initialize the
CStdCallThunk with a function pointer
this parameter, and it generates code on the fly
which converts a static function into a C++ member function
by setting the
this pointer before calling the function
you used to initialize the thunk.
The creation of these code fragments on 16-bit Windows had to be
done by the kernel because the 8086 processor did not have
a memory management unit.
There was no indirection through a translation table;
all addresses were physical.
As a result, if the memory manager had to move memory around,
it also had to know where all the references to the moved memory
were kept so it can update the pointers.
If a data segment moved, the kernel had to go fix up all the
MakeProcInstance thunks so that they used the new
instance handle instead of the old one.
who discovered that all this
MakeProcInstance work was unnecessary.
If the callback function resided in a DLL,
then the function could hard-code its instance handle
and just load it at the start of the function;
this technique ultimately became known as __loadds.
Since DLLs were single-instance, the DLL already knew
which set of variables it was supposed to use since there
was only one set of DLL variables to begin with!
(Of course, the hard-coded value had to be recorded as a fix-up
since the instance handle is determined at run time.
Plus the kernel needed to know which values to update if the instance
handle changed values.)
On the other hand, if the callback function resided in an executable,
then it could obtain its instance handle from the stack selector;
this technique ultimately became known as __export.
Each program ran on a single stack (no multi-threading here),
and the stack, data segment, and local heap all resided in the same
selector by convention.
And in a strange bit of coming full circle which I discovered as I wrote
up this reminiscence,
Michael Geary's copy of
the original readme for his FixDS program that brought this technique
to the public contains an introduction which links back to me...