How did protected-mode 16-bit Windows fix up jumps to functions that got discarded?

Raymond Chen


Commenter Neil presumes that

Windows 286 and later simply fixed up the movable entry table with
jmp selector:offset instructions once and for all

It could have, but it went one step further.

Recall that the point of the movable entry table is to provide
a fixed location that always refers to a specific function,
no matter where that function happens to be.
This was necessary because real mode has no memory manager.

But protected mode does have a memory manager.
Why not let the memory manager do the work?
That is, after all, its job.

In protected-mode 16-bit Windows, the movable entry
table was ignored.
When one piece of code needed to reference another piece of code,
it simply jumped to or called it
by its selector:offset.

    push    ax
    call    0987:6543

(Exercise: Why didn’t I use
call 1234:5678 as the sample address?)

The selector was patched directly into the code as part of
(We saw this

several years ago

in another context.)

When a segment is relocated in memory,
there is no stack walking to

patch up return addresses

to point to thunks,
and no

editing of the movable entry points

to point to the
new location.
All that happens is that the base address in the
descriptor table entry for the selector is updated to
point to the new linear address of the segment.
And when a segment is discarded,
the descriptor table entry is marked not present,
so that any future reference to it will raise a
selector not present exception,
which the kernel handles by reloading the selector.

Things are a lot easier when you have a memory manager around.
A lot of the head-exploding engineering in real-mode windows was in
all the work of
simulating a memory manager on a CPU that didn’t have one!


Comments are closed.