DevBlogs
November 13th, 2017

# On memory allocations larger than 64KB on 16-bit Windows

Allocating memory blocks larger than 64KB was tricky in 16-bit Windows because the nature of 16-bit segment:offset addressing meant that you could access the memory only 64KB at a time. Global memory allocations returned you a segment (or selector, if running protected mode Windows), and the memory started at offset zero in that selector. Things got complicated once you needed to read the byte that comes after offset `0xFFFF`.

For the purpose of discussion, let’s say that the value returned from `Global­Alloc` was `0x1234`. The first 64KB of the allocated memory are accessible as `1234:0000` through `1234:FFFF`.

In real mode, linear addresses are calculated by taking the segment number, multiplying by 16, and adding the offset. This means that `1234:0000` refer to linear byte `0x12340`, and `1234:FFFF` refer to linear byte `0x12340` + `0xFFFF` = `0x2233F`. The next linear byte is `0x22340`, which you could access as `2234:0000`.

Conclusion: When the offset wraps around, you add `0x1000` to the segment.

In standard mode, linear addresses are calculated by looking up the base address of the selector in the descriptor table, and adding the offset. When Windows allocated a block larger than 64KB, it allocated a block of consecutive selectors, so that the first selector pointed to the first 64KB of the allocated memory, the second selector pointed to second 64KB of the allocated memory, and so on.

Now, consecutive selectors do not have consecutive values, however. On the 80286, the bottom three bits of the selector are used for other purposes, so the numeric difference between consecutive selectors is actually 8. The first 64KB of the allocated memory are accessible as `1234:0000` through `1234:FFFF`, and the next byte after that is available as `123C:0000`.

This makes for a bit of trouble if you’re writing a program that needs to run in both real mode and protected mode. When you reach the end of the first 64KB block, how much do you increment the segment/selector by to reach the next 64KB block?

Enter the `__AHINCR` variable.

The `__AHINCR` variable is a variable exported from `KERNEL`. In real mode Windows, the value is `0x1000`. In protected mode Windows, the value is `0x0008`. When your program reaches the end of a 64KB block, it uses the `__AHINCR` value to decide how much to increment the segment/selector by in order to reach the next 64KB block.

Most programmers never saw this variable. It was hidden inside the code generated by the compiler.

With the introduction of enhanced mode Windows, the memory manager did a little more. Enhanced mode Windows used the 80386, “Now with 32-bit registers!✨” This means that the offset portion of a selector:offset address can be a 32-bit value.

The Windows memory manager assigned the selectors to the different 64KB chunks of data in the same way that the standard mode memory manager did, but instead of setting the selector limit to `0xFFFF`, it set the selector limit to extend to the entire remainder of the block. The first selector’s limit was the entire memory block. The second selector’s limit was the memory block minus 64KB. The third selector’s limit was the memory block minus 128KB. And so on until all the selectors were exhausted.

This arrangement meant that if you could convince your compiler to do it (or if you wrote code in assembly language directly), you could leave the selector alone and operate solely on the offset portion.

Windows 95 took advantage of this. The languages team produced a special version of the compiler that, with proper coaxing and appeasement, could be convinced to access memory using 32-bit offsets from a 16-bit selector, provided you declared the selector and the pointer in just the right way.

No lesson today. Just some reminiscing.

Topics
History

## Author

Raymond has been involved in the evolution of Windows for more than 30 years. In 2003, he began a Web site known as The Old New Thing which has grown in popularity far beyond his wildest imagination, a development which still gives him the heebie-jeebies. The Web site spawned a book, coincidentally also titled The Old New Thing (Addison Wesley 2007). He occasionally appears on the Windows Dev Docs Twitter account to tell stories which convey no useful information.