What were the actual memory model definitions in MS-DOS?

Question

I've heard the phrase "memory model" used in relation to MS-DOS programming (and early Windows), with terms such as "small" and "compact".

But what were the actual definitions of these memory models?

---

Please note: I have been made aware of the fact these memory models are discussed in an answer to a different question but it is a very different question, involving only one aspect of the tiny model (which it calls "real mode flat model").

These differences were why I did not find this information on an initial search of RC. The question (which has now been proposed twice as a reason to close) can be found in the first comment to this question, if you wish to check it out and make your own decision.

Since the intent of the close-as-duplicate rule is to prevent duplicate questions, I believe this is still very much a valid question. I don't believe anyone here would think that searchers should have to go searching through all the answers to tangentially-related questions to find the information they need :-) That would make RC a far less useful site in my opinion.

Answer 1

The memory models all had to do with how much code and/or data your program was using. First some background.

The 8086⁽¹⁾ was based on earlier Intel chips where their address space was strictly 64K and you had access to all of that for both code and data, by using a 16-bit address.

However, with the 8086 allowing for more memory, they used an rather ingenious solution where special segment registers would choose the base of the memory you were allowed to use and you could then address the 64K at and beyond that point. This base could be a different value for code and data (and stack, for that matter).

The translation to turn segment register S and address A into a physical address P was P = S * 16 + A or, put another way:

  SSSS0
+  AAAA
  -----
  PPPPP

So a segment could start of any physical address that was a multiple of sixteen and this allowed a great deal of flexibility where you could place your code depending on how much space it needed. Multiple programs could exist in memory at the same time but, since there was no memory protection, you had to be careful.

The segment registers CS and DS decided where code and data addresses were in the physical address space (SS was for the stack and ES was an extra segment register).

These earlier Intel chips (the ones without segment registers, and limited to 64K) could be thought of as actually having all those segment registers but always set to zero. This would mean all code, data and stack all reside in the first 64K.

So, old programs that expected to contain all data, code, and stack in a single 64K chunk would hopefully be easily translatable for the newer chips and by just setting CS, DS, and SS to the same value when running them, would work fine. They would access only their 64K space since they had no knowledge of being able to change segment registers.

However, new programs could take advantage of this knowledge to allow for more than 64K of code and/or data, simply by changing segment registers at will.

You could access more than 64K of data by fiddling with DS or using special instructions that used ES instead. You could jump to code outside of your current CS segment by using a far call rather than a regular (near) call instruction.

As an aside, this scheme lasted well into the protected mode era, even after the simple calculation of a physical address was replaced with selectors that used tables to figure out physical addresses and also allowed limits on how much data you could access starting from that address (e.g., possibly less than 64K).

Having said all that, we turn now to the memory models. I'm not sure that all of these were "official" memory models (from Intel or MS-DOS) but they were in use by various products.

• Tiny: This was effectively the same as the pre-8086 scheme, allowing 64K for code, data, and stack. All of CS, DS, and SS were set to the same value. This was the memory model that COM files used (when started - they could of course change segment registers after that should they so desire). EXE files could use tiny models as well but also had the following models allowed to them.

• Small: Similar to tiny in that CS and DS would never change but they would be different values. This allowed for 64K code and a separate 64K data. In this case (and others below), you could have had SS either the same or different to DS, depending on your needs.

• Compact: A single unchanging CS was still used but DS was allowed to change. Hence code was limited to 64K but data could be substantially more.

• Medium: The "opposite" of compact, this used far calls so that CS could change but DS stayed at one value. Allowed for more than 64K of code but limited data to 64K.

• Large: Used far calls and multiple DS values, allowing for more than 64K of both code and data.

• Huge: Large, but with a small twist. Even though the large and compact models gave you more than 64K of data, each individual data item tended to be limited to 64K (within a single data segment). What the huge model added was the ability for a single data item to exceed 64K by using some form of "trickery" implemented in software.

Now you could combine memory models if, for example, you wanted to be mostly small model but wanted one function to far-callable. In that case, you would have to somehow notify your compiler that this function was a far-call one, such as using FAR in your code to mark it so (it would then adjust calls to it to be far calls).

You would also have to be very careful as the runtime libraries that were added to your code were usually selected for a specific memory model. So a small model program is not going to be very amenable to having the library functions called where the CS is different to its own.

The problem there is not so much the call since your far-callable code could far-call to the library. But the library itself will do a near return, not a far return. That wouldn't tend to end well :-)

---

⁽¹⁾ And the 8088, which was functionally the same as an 8086 but with an 8-bit data bus.

Answer 2

The memory models were defined by compilers for high-level languages, and were reasonably standard between Microsoft, Borland and Watcom. The Small, Medium, Compact and Large models appear to have originated with an Intel compiler from 1980.

First, a brief explanation of how the 8086 architecture worked. It was a 16-bit CPU that could only address memory in chunks called segments. Each segment was 65,536 bytes in size, because that was the number of bytes 16 bits could address. A program could use four segment registers at a time, SS (stack), CS (code), DS (data), and ES (extra). A 16-bit pointer within one of these segments was a near pointer. Originally, these segments could start at any 16-byte “paragraph” of the one-megabyte “conventional memory,” so a far pointer needed 32 bits to hold a 20-bit addres. Later machines added the ability to switch between segments of “expanded” or “extended” memory, to protect memory as not writable or not executable, as well as adding two more segment registers, FS (doesn’t stand for) and GS (anything).

I wrote a long answer a while back about the reasons Intel made this choice. It made sense at the time, but only because the engineers believed that Intel would someday be able to break backward compatibility with it and move on.

Memory models defined whether a program would assume all its code was in a single segment, all its data, both or neither. This determined whether the program could assume any arbitrary function it called was in the same code segment, or any data it accessed was already in its data segment, and therefore whether it needed extra memory to store the segment and extra code to update the segment register. Assembly language didn’t really need a formal memory model, as the programmer could always decide whether to write a near or a far instruction. High-level languages, though, needed to make a trade-off between using the smaller near pointers, which were more efficient, and the wider far pointers, which could support more than 64K of code or data. (Similarly, programmers today sometimes write 32-bit code on a 64-bit machine because 32-bit pointers use less memory.) The terminology that became standard was:

• The Small memory model had one segment for all the code, and another for all the data. All pointers were, by default, near pointers.
• The Compact model had no more than 64K of code, so all jumps and calls could be near, but could deal with more than 64K of data. In particular, it could give the stack its own segment, and be at less risk of a stack overflow. Jumps, calls and function pointers in languages that had them were all near, but pointers to data were far by default. This was probably the most commonly-used model on MS-DOS.
• The Medium model had no more than 64K of data, and more than 64K but less than 640K of code. (MS-DOS was not able to load code above address 0xA0000, at least not the normal way, because that was where IBM had decided to put the video memory on the original PC.)
• The Large model used far pointers by default, and could support more than 64K of both code and data.

Importantly, although the Compact or Large models supported more than 64K of data, no individual array, structure or object was allowed to be larger than 64K. Each such object needed to fit within a single segment. (This is also why C and C++ still do not allow you to compare or subtract two pointers from separate objects. This would break on an architecture that uses segments.)

A program using a larger model might still be able to use near pointers locally, or place a family of functions into the same segment group where they could call each other with near calls. One with a smaller memory model might have a few far functions outside the main code segment, or only a few pieces of far data, and fit the rest under the 64K limit.

There were a few other memory models as well.

• Borland Turbo C, and a few other compilers, supported a Tiny memory model, where all code and data fit into a single 64K segment.

This existed for historical reasons. Intel had based its 8086 on an earlier CPU, the Intel 8080. The 8080 only supported 64K of memory and 16-bit addresses, without segments. There were a lot of programs written for it, and in particular, the circumstances of MS-DOS’ creation (a fascinating story which anyone reading this far down the page on a retrocomputing site already has heard some version of) meant that MS-DOS 1.0 supported a .COM format for executables based on CP/M for the 8080. The primary use of the Tiny model was that a program that used it could be compiled to a smaller .COM executable, rather than the .EXE format.

Later on, compilers added a sixth model.

• The Huge model used far pointers for code and data, but treated data as a flat address space. The difference between Large and Huge was that, if pointer arithmetic on a far data pointer overflowed the bottom 16 bits, they would wrap around. If pointer arithmetic on a huge data pointer overflowed the bottom 16 bits, it would increment the segment.

This had the minor benefit that two data pointers were aliases of each other if and only if they were encoded with the same bits, and the much more important advantage that arrays and structures were now allowed to be more than 64K in size.

Finally, some MS-DOS programs (most but not all of them, games) in the ’90s began using DOS extenders. Many of these used undocumented tricks to let a DOS program use a flat, 32-bit memory space. Toward the end of DOS’ lifespan, these became standardized as DPMI and other interfaces.

Answer 3

For early versions of Windows, there were 3 more memory models. 286 protected mode, up to 16 MB of memory, where segment registers became selectors. These were called huge pointers. The selectors were incremented by 8 (instead of 4096), to advance to the next 64K bytes of data. GlobalAlloc() was use to allocate "huge" data blocks and return a "huge" pointer.

For 386, there was Winmem32, a 32 bit flat memory model, but Watcom compilers were the only ones to support this as a memory model, while Microsoft included an example assembly snippet to use this feature. This made Watcom compilers popular for a while, but it didn't last long, because Window 95 and Windows NT were released not much later.

For 386, there was also Win32S, which used a portion of the Windows NT API.