[HN Gopher] A look back at memory models in 16-bit MS-DOS
___________________________________________________________________
A look back at memory models in 16-bit MS-DOS
Author : pjmlp
Score : 49 points
Date : 2020-08-09 15:49 UTC (1 days ago)
(HTM) web link (devblogs.microsoft.com)
(TXT) w3m dump (devblogs.microsoft.com)
| WalterBright wrote:
| At one point I added the "v" memory model for Zortech C++, which
| was a virtual memory system for code. Functions would be loaded
| from disk on demand, and discarded from memory when not needed.
| The loader would do all the fixups necessary. I was pretty proud
| of it, it was far better than the usual hierarchical overlay
| system.
|
| But by then people were using 286 DOS extenders which were
| better.
| mark-r wrote:
| I always considered myself very lucky that I didn't start
| programming Windows until it went 32-bit. I knew about near and
| far pointers but never had to worry about them because they
| weren't relevant to anything I did.
| jchw wrote:
| The near and far pointers bit is also the reason why in the
| Windows flavor of Systems Hungarian notation, you have a lot of
| "LP" prefixes; I believe it means Long Pointer and would give you
| a far pointer. It's typical to have one pointer typedef for Long
| Pointer, like LPBYTE, and sometimes one near, like
| PIMAGE_DOS_HEADER. Of course now it's all ignored so if you see
| someone writing LP in modern code chances are it's just
| tradition.
|
| Also, today the segment-jumping far call still exists on modern
| AMD64 machines, and is how you cross "heaven's gate" to go
| between 32 bit and 64 bit execution.
| jcranmer wrote:
| > Also, today the segment-jumpimg far call still exists on
| modern AMD64 machines, and is how you cross "heaven's gate" to
| go between 32 bit and 64 bit execution.
|
| Addendum: this model only exists on Windows. On Unixes,
| programs are entirely 64-bit or entirely 32-bit, so there's no
| LDT setup to have a 32-bit segment in 64-bit code. And there's
| no syscall on x86-64 to let userspace muck with the LDT as
| there is on x86-32.
| jchw wrote:
| Hm? I don't think this is true. It's CS 0x23 and 0x33 just
| like on Windows, no? This is, afaik, how Wine WoW64 works. I
| cannot find a definitive source, but for ex:
| https://stackoverflow.com/questions/24113729/switch-
| from-32b...
|
| I also think on Linux the x86 syscalls using software
| interrupts will still work in a 64 bit process, too.
| ajross wrote:
| It's worth pointing out that, outside the IT industry, very
| little "professional" software was actually written to use far
| data pointers as a default type (a long function call, on the
| other hand, was only a tiny bit slower than a near one -- this
| was pervasive). The overhead involved in doing the segment dance
| for every pointer indirection was simply too high to be
| practical.
|
| Almost all real mode software made use of some home-grown
| framework for managing large data across a segmented space.
| OliverJones wrote:
| One word: burgermaster.
| WalterBright wrote:
| > MS-DOS had an additional memory model known as Tiny, 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 extension, and it existed for backward compatibility
| with CP/M.
|
| The usual "tiny" memory model had all the segment registers ES DS
| SS CS set to the same value. It was loaded by simply copying the
| program file into memory and jumping to it.
|
| At Zortech we realized that it wasn't necessary for all the
| segment registers to be the same - it's just that the program
| file needed to be less than 64Kb. This meant the code plus the
| statically initialized data had to be less than 64Kb. SS and DS,
| though, could be changed to the start of the initialized data,
| and had access to 64Kb beyond that, enabling significantly larger
| programs while still using near pointers.
| russellbeattie wrote:
| Heh, I was about to point to that same paragraph because of how
| disingenuous the term "backwards compatibility" is. I'm sure
| the author wasn't intentionally trying to revise history and
| probably didn't think about the term much, but to set the
| record straight, DOS wasn't a _successor_ to CP /M, but a
| "quick and dirty" clone, then later an actual competitor. COM
| files were included in DOS to make sure programming for it was
| similar to programing for CP/M.[1]
|
| The story (which I'm sure many of you know) was that in 1979,
| Seattle Computer was selling an 8086 board, but CP/M didn't run
| on that CPU yet. So Tim Paterson solved the problem by whipping
| up QDOS to help sell more boards, cloning the architecture and
| APIs of CP/M directly from the manuals (without access to the
| actual source code).[2]
|
| The simplest sort of executable code is a COM file (doesn't get
| much simpler, actually), so if you're copying the way an OS
| works, that's pretty much where you'll start. It was about
| being a familiar paradigm for programmers, not some sort of
| cross-platform binary compatibility to an out of date OS as
| insinuated by the term "backwards compatible".
|
| 1. https://en.m.wikipedia.org/wiki/COM_file
|
| 2.
| http://bitsavers.org/pdf/imsai/dos-a/05_CPM_Interface_Guide_...
| bawolff wrote:
| Its totally reasonable to use back compat to mean "compatible
| with a legacy system made by someone else that our system
| replaced"
| toast0 wrote:
| Sure, but it wasn't that, it was "compatable with a
| contemporary system that did not survive as long as our
| system"
| mark-r wrote:
| I have a couple of friends who had that original Seattle
| Computer CPU board and the QDOS that came with it. I was very
| jealous. The sale to Microsoft came out of the clear blue.
| hazeii wrote:
| Did that predate TurboC 1.00? I always used the tiny model in
| that (being an assembly programmer used to flat memory spaces
| it was the only way to go).
| WalterBright wrote:
| Probably, as TurboC was a bit late to the game. But I'm not
| sure.
___________________________________________________________________
(page generated 2020-08-10 23:00 UTC)