What did MakeProcInstance do?

Raymond Chen

February 7th, 20080 0

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 HINSTANCEwas the mechanism for identifying a data segment;i.e., a bunch of memory that represents the set of variablesin use by a module.If you had two copies of Notepad running, there was one copy ofthe code but two sets of variables (one for each copy).It is the second set of variables that establishes the secondcopy 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’sbeing called for.For example, if one copy of Notepad callsEnumFonts and passes a callback function,the function needs to know which copy of Notepad it is running inso that it can access the correct set of variables.That’s what the MakeProcInstance function was for.

The parameters to MakeProcInstance are a function pointerand an instance handle.the MakeProcInstance function generated code on the flywhich set the data segment register equal to theinstance handle and then jumped to the original function pointer.The return value of MakeProcInstance is a pointer to thatdynamically-generated code fragment(known as a thunk),and you used that code fragment as the function pointer wheneveryou needed another function to call you back.That way, when your function was called, its variables were properlyset 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 fragmentgeneration already in the CStdCallThunk class.The operation is entirely analogous with MakeProcInstance.You initialize the CStdCallThunk with a function pointerand a this parameter, and it generates code on the flywhich converts a static function into a C++ member functionby setting the this pointer before calling the functionyou used to initialize the thunk.

The creation of these code fragments on 16-bit Windows had to bedone by the kernel because the 8086 processor did not havea 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 memorywere kept so it can update the pointers.If a data segment moved, the kernel had to go fix up all theMakeProcInstance thunks so that they used the newinstance handle instead of the old one.

It wasMichael Gearywho discovered that all thisMakeProcInstance work was unnecessary.If the callback function resided in a DLL,then the function could hard-code its instance handleand just load it at the start of the function;this technique ultimately became known as __loadds.Since DLLs were single-instance, the DLL already knewwhich set of variables it was supposed to use since therewas only one set of DLL variables to begin with!(Of course, the hard-coded value had to be recorded as a fix-upsince the instance handle is determined at run time.Plus the kernel needed to know which values to update if the instancehandle 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 sameselector by convention.And in a strange bit of coming full circle which I discovered as I wroteup this reminiscence,Michael Geary’s copy ofthe original readme for his FixDS program that brought this techniqueto the public contains an introduction which links back to me…

Raymond Chen