{"id":104012,"date":"2020-07-28T07:00:00","date_gmt":"2020-07-28T14:00:00","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/oldnewthing\/?p=104012"},"modified":"2020-07-28T08:40:38","modified_gmt":"2020-07-28T15:40:38","slug":"20200728-00","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20200728-00\/?p=104012","title":{"rendered":"A look back at memory models in 16-bit MS-DOS"},"content":{"rendered":"

In MS-DOS and 16-bit Windows programming, you had to deal with memory models. This terms does not refer to processor architecture memory models (how processors interact with memory) but rather how a program internally organizes itself. The operating system itself doesn’t know anything about application memory models; it’s just a convenient way of talking about how a program deals with different types of code and data.<\/p>\n

The terms for the memory models came from the C compiler, since this informed the compiler what type of code to generate. The four basic models fit into a nice table:<\/p>\n\n\n\n\n\n\n
\u00a0<\/th>\nData pointer size<\/th>\n<\/tr>\n
Near<\/th>\nFar<\/th>\n<\/tr>\n
Code pointer size<\/span><\/th>\nNear<\/th>\nSmall<\/td>\nCompact<\/td>\n<\/tr>\n
Far<\/th>\nMedium<\/td>\nLarge<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

The 8086 used segmented memory, which means that a pointer consists of two parts: A segment and an offset. A far pointer<\/i> consists of both the segment and the offset. A near pointer<\/i> consists of only the offset, with the segment implied.<\/p>\n

Once you had more than 64KB of code or more than 64KB of data, you had to switch to far code pointers or far data pointers (respectively) in order to refer to everything you needed.<\/p>\n

Most of my programs were Compact<\/i>, meaning that there wasn’t a lot of code, but there was a lot of data. That’s because the programs I wrote tended to do a lot of data processing.<\/p>\n

The Medium<\/i> model was useful for programs that had a lot of code but not a lot of data. User interface code often fell into this category, because you had to write a lot of code to manage a dialog box, but the result of all that work was just a text string (from an edit box) and some flags (from some check boxes). Many computer games also fell into this category, because you had a lot of game logic, but not a lot of game state.<\/p>\n

MS-DOS had an additional memory model known as Tiny<\/i>, in which the code and data were all combined into a single 64KB segment. This was the memory model required by programs that ended with the .COM<\/code> extension, and it existed for backward compatibility with CP\/M. CP\/M ran on the 8080 processor which supported a maximum of 64KB of memory.<\/p>\n

Far pointers could access any memory in the 1MB address space of the 8086, but each object was still limited to 64KB because pointer arithmetic was performed only on the offset portion of the pointer. Huge<\/i> pointers could refer to memory blocks larger than 64KB by adjusting the segment whenever the offset overflowed<\/a>.\u00b9 Pointer arithmetic with huge pointers was computationally expensive, so you didn’t use them much.\u00b2<\/p>\n

You weren’t limited to the above memory models. You could make up your own, known as mixed model programming<\/i>. For example, you could say that most of your program is Small<\/i> memory model, but there’s one place where you need to access memory outside the default data segment, so you declared an explicit far pointer for that purpose. Similarly, you could define an explicitly far function to move it out of the default code segment.<\/p>\n

The memory model specified the default behavior, so if you called, say, memcpy<\/code>, you got a version whose pointer size matched your memory model. If you had a Small<\/i> or Medium<\/i> model program and wanted to copy memory that was outside your default data segment, you could call the _fmemcpy<\/code> function, which was the same as memcpy<\/code> except that it took far pointers. (If you used the Compact<\/i> or Large<\/i> memory model, then memcpy<\/code> and _fmemcpy<\/code> were identical.)<\/p>\n

One of my former colleagues is back in school and was talking with his (younger) advisor. Somehow, the topic turned to the 8086 processor. My colleague and his friend explained segmented addressing, near and far pointers, how pointer equality and comparison behaved,\u00b3 the mysterious A20 gate<\/a>, and how the real mode boot sector worked. “The look of horror on his face at how segment registers used to work was priceless.”<\/p>\n

I quickly corrected my colleague. “‘Used to work’? They still work that way!”<\/p>\n

Bonus chatter<\/b>: You can see the remnants of 16-bit memory models in the macros NEAR<\/code> and FAR<\/code> defined by windows.h<\/code>. They don’t mean anything any more, but they remain for source code backward compatibility<\/a>.<\/p>\n

\u00b9 In MS-DOS, huge pointers operated by putting the upper 16 bits of the 20-bit address in the segment and putting the remaining 4 bits in the offset. The offset of a huge pointer in MS-DOS was always less than 16.<\/p>\n

\u00b2 In 16-bit Windows, there was a system function called hmemcpy<\/code>, which copied memory blocks that could be larger than 64KB. And now you know what the h<\/code> prefix stood for.<\/p>\n

\u00b3 Segmented memory is a great source of counterexamples. For example, in a segmented memory model, you could have a pointer p<\/var> to a buffer of size N<\/var>, and another pointer q<\/var> could satisfy the inequalities<\/p>\n

p <= q && q <= p + N\r\n<\/pre>\n
despite not pointing into the buffer.<\/p>\n
This is one of the reasons why the C and C++ programming languages do not specify the result of comparisons between pointers that do not point to elements of the same array.<\/p>\n","protected":false},"excerpt":{"rendered":"
Ways of dealing with the fractured address space.<\/p>\n","protected":false},"author":1069,"featured_media":111744,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[2],"class_list":["post-104012","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-history"],"acf":[],"blog_post_summary":"
Ways of dealing with the fractured address space.<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/104012","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/users\/1069"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/comments?post=104012"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/104012\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media\/111744"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media?parent=104012"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=104012"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=104012"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}