What did MakeProcInstance do?
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 HINSTANCE
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.
the 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
set up.
When you no longer needed the code fragment,
you freed it with the FreeProcInstance function.
Those who have worked with ATL have seen this sort of code fragment
generation already in the CStdCallThunk class.
The operation is entirely analogous with MakeProcInstance.
You initialize the CStdCallThunk with a function pointer
and a 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.
It was
Michael Geary
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...
