Early-to-middle IBM-PC history (was: End-user uses for x86-64)

Ben Scott dragonhawk at gmail.com
Sun Feb 18 20:46:37 EST 2007


On 2/18/07, Tom Buskey <tom at buskey.name> wrote:
> I had VGA on my '286.  And Minix and Windows 3.0.

  I installed an 8-bit ISA Western Digital Paradise VGA card in my
Tandy 1000 SL, which had an 8088 and 640 KB of RAM.  There was no way
in hell I was going to run MS Windows, but PC/GEOS looked a lot better
(vs a monochrome CGA mode).

> There was the memory thing too.  The 286 in DOS couldn't do much beyond
> 1MB(16MB?) ...

  MS-DOS was, is, and always will be limited to the 1 MB address space
of the original 8086-based IBM-PC design, in 64 KB segments at a time.
 That's further eaten into by space reserved for hardware ROM and I/O.
 On most systems, there was (up to) 640 KB for software ("conventional
memory") and 384 KB for hardware ("high memory").  (If you had a
Hercules monochrome graphics adapter, you could bump conventional
memory to 700-something KB, as the Herc mapped it's hardware into
different regions.)

> EMS was originally a hardware spec to address more memory.

  That's incorrect.  EMS (Expanded Memory Specification) was another
memory windowing scheme.  You put RAM on an expansion card.  The CPU
could not address it in any way.  You could, however, invoke hardware
I/O routines that would swap a block of memory from conventional to
EMS banks (or vice versa).  You still could only address 64 KB at a
time, though, and no more than 1 MB total.

> XMS was a software hack that didn't work on the 8088.

  XMS (Extended Memory Specification) was the standard that evolved
for accessing (from DOS) CPU-addressable memory above 1 MB.  DOS and
DOS programs still ran in real mode, but a memory manager (an add-on
product in the DOS world) could switch blocks of memory in and out of
the DOS real mode memory space (similar to how EMS worked).

  The 8086/8 could not address more than 1 MB.  The 80286 could -- up
to 16 MB, as you note.  That's a huge jump, so of course DOS
programmers wanted to access it, but were stuck in a 16-bit segment.
Hence the need for XMS.

> The 386 could do EMS (& XMS) in software ...

  Not really correct.  EMS and XMS are both software interfaces.  EMS
existed to allow the many different hardware-incompatible memory
expansion hards to provide a consistent interface to DOS software.
Yes, that's right, under DOS, even your RAM needed a device driver.
XMS existed because even though the hardware could touch more memory,
DOS software still couldn't.

  CPU-addressable memory above 1 MB was possible with the 80286.  It
wasn't used by most programs, because the 286 couldn't switch back to
real mode once switched into protected mode, and a lot of DOS software
isn't compatible with protected mode.  It was done by some software
through -- typically business applications that wanted to work with
more than 64 KB at a time.

  Software emulators were available that turned used XMS to provide
EMS (for software that was only EMS aware), but that's nothing to do
with the i386.

  The i386's major changes were that it enabled a 32-bit address
space, it could switch back to real mode (out of protected mode), and
it offered virtual 8086 mode.  Suddenly, you could reliably multitask
DOS programs.  Multitasking was available before, but without memory
protection.  Now, when one of the DOS programs went bonkers and
trashed memory, instead of a reboot, you could just kill the "DOS
box".

  Sure the i386 was faster.  Faster is always appreciated.  But no
matter how fast you ran a 286, you couldn't reliably multitask DOS
programs.  That was the "killer app" for Win 3.0 for many
people-doing-ordinary-tasks-like-reading-email-browsing-the-web-writing-letters-looking-at-pictures-and-calculating-their-taxes.
 Sure, it sucked like a black hole, but DOS still sucked more.  After
swimming in sewage, even NJ looks like paradise.  ;-)

  The additional address space also enables practical use of larger
memories.  I know you're married to the idea that any Turing-complete
design can do anything any *other* Turing-complete design can, but
here in the real world, we actually want to get work done, and we
don't have time to wait for the infinitely long paper tape to move
back and forth.

> I don't think Windows 95 would run on a '286 ...

  Correct.

> ... but I also think the DOS market was pretty much done at that point.

  HAH!  One of the major complaints about '95 was that some DOS
software wouldn't run anymore.  There was a whole "MS-DOS
Compatibility Mode" which was essentially an automatic dual-boot: It
would shut down the whole OS to run one DOS program.  Hell, people
still run DOS crap *today*.  It's like System/360; it saw enough use
that it's never going away.  People will be running DOS programs in
DOS emulators (prolly running *those* emulators under some *other*
emulator) long after we're all dead and buried.

  This is, incidentally, one of the "limitations" of x86-64.  In long
mode (64-bit mode), you cannot run 16-bit real mode code.  At all.
There's no virtual mode, either.  So 64-bit Windows cannot run DOS or
Win16 code (of which there is still a depressingly large amount).
That's one reason most Windows systems are still 32-bit OS installs.
Of course, it means all the cool x86-64 stuff just ends up being used
primarily as a really, *really* fast i386.

> Remember having to quit a program completely before running another one?

  Heh.  Yah.  I ended up using multi-program environments early on.
PC/GEOS offered preemptive multitasking (without memory protection) on
an 8086.  Then I started using DESQview... :)

> As time went on, the market chased speed.

  Apparently, you never had to fight to get 3 KB more out of
conventional memory, to load just one more TSR or that much of a
bigger program.  The ability to address more than 64 KB at a time was
wanted by everyone else on the planet except you.

-- Ben


More information about the gnhlug-discuss mailing list