{"id":36953,"date":"2004-12-17T07:00:00","date_gmt":"2004-12-17T07:00:00","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/oldnewthing\/2004\/12\/17\/how-did-windows-95-rebase-dlls\/"},"modified":"2004-12-17T07:00:00","modified_gmt":"2004-12-17T07:00:00","slug":"how-did-windows-95-rebase-dlls","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20041217-00\/?p=36953","title":{"rendered":"How did Windows 95 rebase DLLs?"},"content":{"rendered":"

Windows 95 handled DLL-rebasing very differently from Windows NT.<\/p>\n

When Windows NT detects that a DLL needs to be loaded at an address different from its preferred load address, it maps the entire DLL as copy-on-write, fixes it up (causing all pages that contain fixups to be dumped into the page file), then restores the read-only\/read-write state to the pages. (Larry Osterman went into greater detail on this subject earlier this year<\/a>.) <\/p>\n

Windows 95, on the other hand, rebases the DLL incrementally. This is another concession to Windows 95’s very tight memory requirements. Remember, it had to run on a 4MB machine. If it fixed up DLLs the way Windows NT did, then loading a 4MB DLL and fixing it up would consume all the memory on the machine, pushing out all the memory that was actually worth keeping! <\/p>\n

When a DLL needed to be rebased, Windows 95 would merely make a note of the DLL’s new base address, but wouldn’t do much else. The real work happened when the pages of the DLL ultimately got swapped in. The raw page was swapped off the disk, then the fix-ups were applied on the fly to the raw page, thereby relocating it. The fixed-up page was then mapped into the process’s address space and the program was allowed to continue. <\/p>\n

This method has the advantage that the cost of fixing up a page is not paid until the page is actually needed, which can be a significant savings for large DLLs of mostly-dead code. Furthermore, when a fixed-up page needed to be swapped out, it was merely discarded, because the fix-ups could just be applied to the raw page again. <\/p>\n

And there you have it, demand-paging rebased DLLs instead of fixing up the entire DLL at load time. What could possibly go wrong? <\/p>\n

Hint: It’s a problem that is peculiar to the x86. <\/p>\n

The problem is fix-up that straddle page boundaries. This happens only on the x86 because the x86 architecture is the weirdo<\/a>, with variable-length instructions that can start at any address. If a page contains a fix-up that extends partially off the start of the page, you cannot apply it accurately until you know whether or not the part of the fix-up you can’t see generated a carry. If it did, then you have to add one to your partial fix-up. <\/p>\n

To record this information, the memory manager associates a flag with each page of a relocated DLL that indicates whether the page contained a carry off the end. This flag can have one of three states: <\/p>\n