{"id":98575,"date":"2018-04-23T07:00:00","date_gmt":"2018-04-23T21:00:00","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/oldnewthing\/?p=98575"},"modified":"2019-03-13T00:46:17","modified_gmt":"2019-03-13T07:46:17","slug":"20180423-00","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20180423-00\/?p=98575","title":{"rendered":"The early history of redundant function pointer casts: MakeProcInstance"},"content":{"rendered":"

If you look through old code<\/a>, you see a lot of redundant function pointer casts. (If you’re writing new code, you should get rid of as many function pointer casts as possible, because a function pointer cast is a bug waiting to happen<\/a>.) Why does old code have so many redundant function pointer casts? <\/p>\n

Because back in the old days, they weren’t redundant. <\/p>\n

In the days of 16-bit Windows, function prologues were required to take very specific forms in order to make stack walking<\/a> work, and stack walking was necessary in order to simulate an MMU on a CPU that didn’t have one. <\/p>\n

Another rule for prologues has to do with state management. The full prologue for a far function looks like this: <\/p>\n

\n    mov     ax, ds\n    nop\n    inc     bp\n    push    bp\n    mov     bp, sp\n    push    ds\n    mov     ds, ax\n<\/pre>\n
Before we can dig into those instructions, we need to know a bit about how code segments worked in real-mode 16-bit Windows. In real-mode 16-bit Windows, there was a single address space for all applications because the CPU had no concept of per-process address spaces. The kernel simulated separate address spaces by managing instances<\/i>. The instance (represented by an instance handle<\/i>) specified the location of the data segment the code should operate on. If you have two copies of a program running, the code is shared, but each program has its own data. The instance handle tells you where that data is. <\/p>\n
And the instance handle is kept in the ds<\/code> register. <\/p>\n
Therefore, it is essential that every function have its ds<\/code> register set to the instance handle that describes where the code should find its data. You can think of it as a “global this<\/code> pointer for the process.” <\/p>\n
Okay, so let’s look at the function prologue again. First, it copies ds<\/code> to ax<\/code> via a two-byte mov ax, ds<\/code> instruction. Then there is a nop<\/code>. This pads the prologue size to three bytes. <\/p>\n
The next four instructions build the stack frame: The inc bp<\/code> marks the stack frame as a far frame<\/a>. The push bp<\/code> and mov bp, sp<\/code> build the bp<\/code> chain. And the push ds<\/code> saves the original ds<\/code> register, which also provides breathing room for return address patching<\/a>. <\/p>\n
And then we move ax<\/code> back into ds<\/code>. The instance handle just took a little tour of the ax<\/code> register and then returned back home. What was the point of that? <\/p>\n
Recall that in 16-bit Windows, every far function called from another segment was listed in the module’s Entry Table<\/a>. <\/p>\n
When a far function is placed in the exported function table, the loader patches the first three bytes of the function to three nop<\/code> instructions. Non-exported functions remain unchanged. This means that non-exported functions do the redundant ds<\/code> rigamarole. It’s a little extra work, but it’s ultimately harmless. <\/p>\n
The effect of patching out the initial mov ax, ds<\/code> is that the function ends up doing this: <\/p>\n