5 ms·

My third home computer was an IBM PS/2 Model 30 286. I was already an systems architecture nerd at that age, and so I was excited to get this new machine. I bel

My third home computer was an IBM PS/2 Model 30 286. I was already an systems architecture nerd at that age, and so I was excited to get this new machine. I believe it came equipped with 256KiB RAM and 20MB HDD, among other things. Of course I ran DOS for the most part, and DOS did absolutely nothing with 286's special protected-mode features. Really, Windows 3.1 didn't do anything with it either. Later, I eschewed DOS, upgraded to 2MiB RAM, and installed Minix, which turned into a really fun exploration of protected mode and its strict limitations, like the 64/64 code/data limit on each task. 286 protected mode, for its segmented memory model and all the fascinating advanced features, was more or less neglected by the consumer OSes of its time, and they bided their time until the fully 32-bit 386 with its flat memory model, able to address a huge amount of physical RAM. In retrospect, probably the correct decision. The 286 was a logical transition along the 8-to-32-bit path.

npsomaratna 3y ago
That reminds me of the undocumented LOADALL instruction, and how you could use it to access memory without switching to protected mode. Good times!
pavlov 3y ago
There was also OS/2 which was co-created by Microsoft and IBM as the DOS replacement. At IBM’s insistence it was designed to target the 286 protected mode. Bill Gates grumbled a lot about that, he would have preferred to wait to use the 386 instead. And he was right because no interesting applications emerged for OS/2 1.x.
- bell-cot 3y ago
  Given how [cough] successful the 386-specific version of OS/2 was, even after IBM put a load of money and marketing behind it...perhaps the real problem was not the 286's protected mode.
  - pavlov 3y ago
    I don't know. MS and IBM wasted several years trying to make OS/2 for 286. If they'd started on a 386-only system back in 1985 when the cooperation was signed, maybe they could have shipped a compelling 32-bit GUI operating system by 1989 and avoided the acrimony that broke the alliance. (Probably not though — the technology choices were only one ingredient in the divorce.)
    - bell-cot 3y ago
      OS/2 for '286 came out in 1987. Then it took them 5 more years to get the '386 version out the door. Vs. tiny SCO was able to get the '386 version of their (Unix-based) Xenix OS out the door in 1987.
      - lproven 3y ago
        This is absolutely true, but the thing is, SCO didn't have to be backwards compatible with a damned thing. Also note that the base addition of Xenix didn't support graphics, or sound, or networking, or come with a C compiler or anything. It was basically a runtime, for text only apps, and most machines only ran a single app. I put in dozens of boxes running Xenix back then. In my world, the bulk of them ran one binary: an accountancy application provided by Tetra Corporation, and we sold one called Tetraplan. SCO Xenix was a wonderful little operating system, extremely resource efficient, and astonishingly stable in use. Some of those boxes had uptimes in years. But that's relatively easy when it's not connected to anything, not connected to the outside world in any way, and only runs a single program. I am absolutely not denigrating Xenix. Xenix was my first experience of UNIX of any kind, I supported it for years, right into the 21st-century for one exceptional customer, and it caused me remarkably little pain of any kind. It was great. But it was not a mass market, general-purpose product.
        pavlov 3y ago
        The funny thing is that Xenix was a Microsoft product. They originally licensed it to SCO who created the x86 port, then eventually sold it entirely to SCO in 1987. If things had turned out slightly differently, Microsoft's 32-bit OS in the 1990s would have been Unix.
- mschaef 3y ago
  >At IBM’s insistence it was designed to target the 286 protected mode. > Bill Gates grumbled a lot about that,... And he was right because no interesting applications emerged for OS/2 1.x 286 protected mode wasn't the issue... Windows 3.0 was also largely built around 286 protected mode and it's where most of the interesting PC application development happened for years. OS/2's early issues were really related to the cost of the OS (x2-3 windows), the equipment needed to run it (at least 3MB RAM), and delays in both the networking and GUI capabilities. OS/2 also required a wholesale commitment to use it, due to the lack of a decent DOS story, which is in contrast to Windows (that ran on DOS, more or less).
  - garaetjjte 3y ago
    But Windows also didn't have decent DOS story until Windows/386.
    - mschaef 3y ago
      There were a couple things Windows did better regarding DOS when compared to OS/2: * Windows ran on a DOS file system, so data portability was transparent. * You could easily quit Windows to get back to something close to whatever DOS environment you had before. * There was a runtime version of Windows that could be packaged with applications (Excel mainly, iirc) to make it possible to sell Windows apps to DOS users. * Windows had support for LIM/EMS (which users might already have to run large Lotus 1-2-3 spreadsheets). None of this was a great way to run DOS apps under Windows, but it did make it easier to transition from DOS to Windows slowly, without a wholesale jump, and the risk that entailed. It was easier (and cheaper) for a DOS user to experiment with Windows than it was with OS/2. The lower barrier to entry is worth a lot.
  - lproven 3y ago
    You are getting cause and effect backwards. > 286 protected mode wasn't the issue... Yes, it was. I evaluated OS/2 1.0 professionally, when it was new; did you? The 286 protected mode was an issue, because it meant that OS/2 could not multitask dos applications — exactly as Concurrent DOS could not on the shipping 286 hardware. > Windows 3.0 was also largely built around 286 protected mode Not really, no. 1. Windows 2 had an edition built around 286 protected mode. This was nothing new for Windows 3.0. The problem is that the 286's protected mode didn't deliver anything that was very useful for dos applications, and in the 1980s, DOS applications were the sole driving factor behind the PC industry. In fact, Windows/286 actually delivered one main benefit: you got an extra 64 kB of RAM. That was it. It wasn't really worth having. Windows 2 also had a 386 edition, generally known as Windows/386. That delivered the core functionality that was the useful thing in the 386 in the 1980s: hardware assisted multitasking of DOS applications. 2. You cite Windows 3.0, but that's not relevant to a discussion of OS/2 1.X, because Windows 3.0 is what happened as a result of OS/2 1.X. OS/2 1.x was a 1980s product. Windows 3.0 came out in 1990, a few months after OS/2 1.2. Windows 3.0 happened in response to the failure of OS/2 1.X, and OS/2 1.X failed because it ran on the 286 processor, when it should've run on the 386 processor — as Microsoft wanted. Windows 2 was able to multitask dos applications, in software, but the problem with doing it that way is that they all had to fit into 640 kB of RAM. And by the late 1980s, a single DOS application barely fit into 640 kB! Windows 3.x was able to multitask DOS applications as well, and it could do it on 8086, on 286, and on 386. The difference is that on a 386, each DOS application got it own 640 kB. So if you had 4 MB of RAM, you could multitask a whole bunch of them. And it sold because the single same edition ran on all three processors, so you didn't have to choose which one you needed in advance, and buy the right product. The one product did it all. And if you upgraded the hardware, you got the additional facilities, with that same copy of the software. (Remember, no product activation in those days!)
- sacnoradhq 3y ago
  OS/2 had both MS-DOS 5 and Windows 3.x compatibility, first by running a copy of Windows in a VDM and then later through integration. OS/2 was also very damn stable. 286 protected mode was bug-ridden and lacked features. 386 protected mode fixed most of them to make it more stable and usable.
justin_ 3y ago
AIUI, another big problem with the 80286 was that it did not support returning to real mode after switching to protected mode. This made compatibility a huge issue, which was a big problem for Microsoft. The 80836, besides marking a switch to 32-bit, added virtual 8086 mode, which allowed for emulating real mode after already having switched to protected mode. https://web.archive.org/web/20021003235610/http://osdev.berlios.de/v86.html https://web.archive.org/web/20021003235610/http://osdev.berl... This "virtual 8086" mode is what was used for the VMM kernel of Windows 9x, and later the NTVDM system on 32-bit versions of Windows NT. I remember being able to run some DOS software on Windows XP (but it wasn't perfect).
achairapart 3y ago
There was an OS especially made for the new 286 and its protected mode: Concurrent DOS by Digital Research (aka Gary Killdall). This OS would function strictly in protected-mode, allowing users to take full advantage of the protected mode to perform multi-user, multitasking operations while running 8086 emulation. But, by an irony of fate, this only worked on the B-1 prototype step of the chip. When Intel went out for production with a new C-1 step, it broke everything and Concurrent DOS was delayed[0] until it was too late, and then the OS was recycled as a Point of Sale for cash register software[1]. [0]: https://books.google.com/books?id=2y4EAAAAMBAJ&pg=PA17&redir_esc=y#v=onepage&q&f=false https://books.google.com/books?id=2y4EAAAAMBAJ&pg=PA17&redir... (Super DOS awaits new 80286) [1]: https://books.google.com/books?id=oi8EAAAAMBAJ&pg=PA12&redir_esc=y#v=onepage&q&f=false https://books.google.com/books?id=oi8EAAAAMBAJ&pg=PA12&redir... (IBM to use a DRI Operating System)
- nekoashide 3y ago
  And now I know why that weird version of DOS existed a few decades ago when I was working on cash registers. Back then you ran across a lot of DOS compatible OS's and documentation. As long as all the same commands worked you were usually fine.
- rep_lodsb 3y ago
  The 8086 emulation would work by trapping every segment register load, emulating the instruction's real mode semantics, and then loading the new CPU state using the undocumented LOADALL instruction. In principle this should work on any stepping. I'm not sure how Digital Research implemented it, but they might have relied on some detail of the exception handling that changed between steppings. For example, if early steppings left "invalid" values in segment registers instead of zeroing them, DR might have used these instead of going to the effort of emulating the faulting instruction? Concurrent DOS/286 became FlexOS, which seems to be available here (but I haven't tested it to see if this actually includes the real-mode emulation, it might have been a feature that was only in the prototype): http://bitsavers.trailing-edge.com/bits/DigitalResearch/FlexOS/ http://bitsavers.trailing-edge.com/bits/DigitalResearch/Flex... In any case, this way of running real mode code might just be too impractical. For "large model" programs using more than 64K data, every pointer dereference would have to be trapped and emulated, taking possibly thousands of clock cycles instead of just a few. You could optimize accesses to code and static data segments by defining protected-mode selectors for those, but running code that e.g. walks a linked list allocated on the heap might be intolerably slow. Also all of the memory allocated to the program would have to be in one contiguous block, since there is no linear->physical address translation in the 286.
PaulHoule 3y ago
Before I got a 286 around 1987 or so I had a TRS-80 Color Computer and then a Coco 3. Those booted into BASIC but could run OS-9 which was a miniature Unix-like operating system w/ a C compiler, bytecode based structured BASIC, and even a graphical windowing system. I did all the data entry and analysis for a customer survey my uncle needed and spent the money to get a new 286 machine at 12MHz which utterly devastated 8-bit machines in performance. It was so fast that it could emulate the Z80 for CP/M development much faster than any real Z-80! At that time people were jumping ship from 8-bit platforms frequently onto the PC because it had finally become superior in all respects, you could even write good games for the EGA. Some people were going to Amiga and such platforms but the 68k turned out to be a dead end. My uncle told me later on that the information I'd gotten for him had saved his employer a vast amount of money, knowing that I should have asked for enough money to buy a 386 machine and a used car.

npsomaratna 3y ago

That reminds me of the undocumented LOADALL instruction, and how you could use it to access memory without switching to protected mode. Good times!

pavlov 3y ago

There was also OS/2 which was co-created by Microsoft and IBM as the DOS replacement. At IBM’s insistence it was designed to target the 286 protected mode. Bill Gates grumbled a lot about that, he would have preferred to wait to use the 386 instead. And he was right because no interesting applications emerged for OS/2 1.x.

bell-cot 3y ago
Given how [cough] successful the 386-specific version of OS/2 was, even after IBM put a load of money and marketing behind it...perhaps the real problem was not the 286's protected mode.
- pavlov 3y ago
  I don't know. MS and IBM wasted several years trying to make OS/2 for 286. If they'd started on a 386-only system back in 1985 when the cooperation was signed, maybe they could have shipped a compelling 32-bit GUI operating system by 1989 and avoided the acrimony that broke the alliance. (Probably not though — the technology choices were only one ingredient in the divorce.)
  - bell-cot 3y ago
    OS/2 for '286 came out in 1987. Then it took them 5 more years to get the '386 version out the door. Vs. tiny SCO was able to get the '386 version of their (Unix-based) Xenix OS out the door in 1987.
    - lproven 3y ago
      This is absolutely true, but the thing is, SCO didn't have to be backwards compatible with a damned thing. Also note that the base addition of Xenix didn't support graphics, or sound, or networking, or come with a C compiler or anything. It was basically a runtime, for text only apps, and most machines only ran a single app. I put in dozens of boxes running Xenix back then. In my world, the bulk of them ran one binary: an accountancy application provided by Tetra Corporation, and we sold one called Tetraplan. SCO Xenix was a wonderful little operating system, extremely resource efficient, and astonishingly stable in use. Some of those boxes had uptimes in years. But that's relatively easy when it's not connected to anything, not connected to the outside world in any way, and only runs a single program. I am absolutely not denigrating Xenix. Xenix was my first experience of UNIX of any kind, I supported it for years, right into the 21st-century for one exceptional customer, and it caused me remarkably little pain of any kind. It was great. But it was not a mass market, general-purpose product.
      - pavlov 3y ago
        The funny thing is that Xenix was a Microsoft product. They originally licensed it to SCO who created the x86 port, then eventually sold it entirely to SCO in 1987. If things had turned out slightly differently, Microsoft's 32-bit OS in the 1990s would have been Unix.
mschaef 3y ago
>At IBM’s insistence it was designed to target the 286 protected mode. > Bill Gates grumbled a lot about that,... And he was right because no interesting applications emerged for OS/2 1.x 286 protected mode wasn't the issue... Windows 3.0 was also largely built around 286 protected mode and it's where most of the interesting PC application development happened for years. OS/2's early issues were really related to the cost of the OS (x2-3 windows), the equipment needed to run it (at least 3MB RAM), and delays in both the networking and GUI capabilities. OS/2 also required a wholesale commitment to use it, due to the lack of a decent DOS story, which is in contrast to Windows (that ran on DOS, more or less).
- garaetjjte 3y ago
  But Windows also didn't have decent DOS story until Windows/386.
  - mschaef 3y ago
    There were a couple things Windows did better regarding DOS when compared to OS/2: * Windows ran on a DOS file system, so data portability was transparent. * You could easily quit Windows to get back to something close to whatever DOS environment you had before. * There was a runtime version of Windows that could be packaged with applications (Excel mainly, iirc) to make it possible to sell Windows apps to DOS users. * Windows had support for LIM/EMS (which users might already have to run large Lotus 1-2-3 spreadsheets). None of this was a great way to run DOS apps under Windows, but it did make it easier to transition from DOS to Windows slowly, without a wholesale jump, and the risk that entailed. It was easier (and cheaper) for a DOS user to experiment with Windows than it was with OS/2. The lower barrier to entry is worth a lot.
- lproven 3y ago
  You are getting cause and effect backwards. > 286 protected mode wasn't the issue... Yes, it was. I evaluated OS/2 1.0 professionally, when it was new; did you? The 286 protected mode was an issue, because it meant that OS/2 could not multitask dos applications — exactly as Concurrent DOS could not on the shipping 286 hardware. > Windows 3.0 was also largely built around 286 protected mode Not really, no. 1. Windows 2 had an edition built around 286 protected mode. This was nothing new for Windows 3.0. The problem is that the 286's protected mode didn't deliver anything that was very useful for dos applications, and in the 1980s, DOS applications were the sole driving factor behind the PC industry. In fact, Windows/286 actually delivered one main benefit: you got an extra 64 kB of RAM. That was it. It wasn't really worth having. Windows 2 also had a 386 edition, generally known as Windows/386. That delivered the core functionality that was the useful thing in the 386 in the 1980s: hardware assisted multitasking of DOS applications. 2. You cite Windows 3.0, but that's not relevant to a discussion of OS/2 1.X, because Windows 3.0 is what happened as a result of OS/2 1.X. OS/2 1.x was a 1980s product. Windows 3.0 came out in 1990, a few months after OS/2 1.2. Windows 3.0 happened in response to the failure of OS/2 1.X, and OS/2 1.X failed because it ran on the 286 processor, when it should've run on the 386 processor — as Microsoft wanted. Windows 2 was able to multitask dos applications, in software, but the problem with doing it that way is that they all had to fit into 640 kB of RAM. And by the late 1980s, a single DOS application barely fit into 640 kB! Windows 3.x was able to multitask DOS applications as well, and it could do it on 8086, on 286, and on 386. The difference is that on a 386, each DOS application got it own 640 kB. So if you had 4 MB of RAM, you could multitask a whole bunch of them. And it sold because the single same edition ran on all three processors, so you didn't have to choose which one you needed in advance, and buy the right product. The one product did it all. And if you upgraded the hardware, you got the additional facilities, with that same copy of the software. (Remember, no product activation in those days!)
sacnoradhq 3y ago
OS/2 had both MS-DOS 5 and Windows 3.x compatibility, first by running a copy of Windows in a VDM and then later through integration. OS/2 was also very damn stable. 286 protected mode was bug-ridden and lacked features. 386 protected mode fixed most of them to make it more stable and usable.

justin_ 3y ago

AIUI, another big problem with the 80286 was that it did not support returning to real mode after switching to protected mode. This made compatibility a huge issue, which was a big problem for Microsoft. The 80836, besides marking a switch to 32-bit, added virtual 8086 mode, which allowed for emulating real mode after already having switched to protected mode. https://web.archive.org/web/20021003235610/http://osdev.berlios.de/v86.html https://web.archive.org/web/20021003235610/http://osdev.berl... This "virtual 8086" mode is what was used for the VMM kernel of Windows 9x, and later the NTVDM system on 32-bit versions of Windows NT. I remember being able to run some DOS software on Windows XP (but it wasn't perfect).

achairapart 3y ago

There was an OS especially made for the new 286 and its protected mode: Concurrent DOS by Digital Research (aka Gary Killdall). This OS would function strictly in protected-mode, allowing users to take full advantage of the protected mode to perform multi-user, multitasking operations while running 8086 emulation. But, by an irony of fate, this only worked on the B-1 prototype step of the chip. When Intel went out for production with a new C-1 step, it broke everything and Concurrent DOS was delayed[0] until it was too late, and then the OS was recycled as a Point of Sale for cash register software[1]. [0]: https://books.google.com/books?id=2y4EAAAAMBAJ&pg=PA17&redir_esc=y#v=onepage&q&f=false https://books.google.com/books?id=2y4EAAAAMBAJ&pg=PA17&redir... (Super DOS awaits new 80286) [1]: https://books.google.com/books?id=oi8EAAAAMBAJ&pg=PA12&redir_esc=y#v=onepage&q&f=false https://books.google.com/books?id=oi8EAAAAMBAJ&pg=PA12&redir... (IBM to use a DRI Operating System)

nekoashide 3y ago
And now I know why that weird version of DOS existed a few decades ago when I was working on cash registers. Back then you ran across a lot of DOS compatible OS's and documentation. As long as all the same commands worked you were usually fine.
rep_lodsb 3y ago
The 8086 emulation would work by trapping every segment register load, emulating the instruction's real mode semantics, and then loading the new CPU state using the undocumented LOADALL instruction. In principle this should work on any stepping. I'm not sure how Digital Research implemented it, but they might have relied on some detail of the exception handling that changed between steppings. For example, if early steppings left "invalid" values in segment registers instead of zeroing them, DR might have used these instead of going to the effort of emulating the faulting instruction? Concurrent DOS/286 became FlexOS, which seems to be available here (but I haven't tested it to see if this actually includes the real-mode emulation, it might have been a feature that was only in the prototype): http://bitsavers.trailing-edge.com/bits/DigitalResearch/FlexOS/ http://bitsavers.trailing-edge.com/bits/DigitalResearch/Flex... In any case, this way of running real mode code might just be too impractical. For "large model" programs using more than 64K data, every pointer dereference would have to be trapped and emulated, taking possibly thousands of clock cycles instead of just a few. You could optimize accesses to code and static data segments by defining protected-mode selectors for those, but running code that e.g. walks a linked list allocated on the heap might be intolerably slow. Also all of the memory allocated to the program would have to be in one contiguous block, since there is no linear->physical address translation in the 286.

PaulHoule 3y ago

Before I got a 286 around 1987 or so I had a TRS-80 Color Computer and then a Coco 3. Those booted into BASIC but could run OS-9 which was a miniature Unix-like operating system w/ a C compiler, bytecode based structured BASIC, and even a graphical windowing system. I did all the data entry and analysis for a customer survey my uncle needed and spent the money to get a new 286 machine at 12MHz which utterly devastated 8-bit machines in performance. It was so fast that it could emulate the Z80 for CP/M development much faster than any real Z-80! At that time people were jumping ship from 8-bit platforms frequently onto the PC because it had finally become superior in all respects, you could even write good games for the EGA. Some people were going to Amiga and such platforms but the 68k turned out to be a dead end. My uncle told me later on that the information I'd gotten for him had saved his employer a vast amount of money, knowing that I should have asked for enough money to buy a 386 machine and a used car.