The story as it used to be told (when I lived in Redmond) was that he showed BillG and someone asked BillG “you know what this means, right?” (referring to their OS2 partnership with IBM), and BillG responded: “Yeah, fuck IBM.”
The page doesn’t explain why the CPU needed a separate, incompatible “protect mode” to access more memory. I learned more about that from the following Wikipedia pages, which I have summarized.
Real mode, also called real address mode, was once the only mode of Intel CPUs, so operating systems already supported it. In this mode, addresses always correspond to real locations in memory. For backwards compatibility, x86 CPUs still start up in real mode, though modern operating systems turn on protected mode when booting so as to be able to access more than 1 MiB of memory.
Protected mode, also called protected virtual address mode, enables virtual memory, paging, and other features. The mode was backwards incompatible with real mode because it reinterpreted some bits of a memory address to point to memory indirectly via an entry inside a descriptor table. It also reinterpreted two bits as defining the privilege of the memory request.
Protected mode was introduced in the Intel 80286 processor, the one mentioned in the article. The Wikipedia article on the processor has sections on its protected mode and its OS support.
Also… “protect mode”? I had never heard anyone call it that way, ever. It has always been “protected mode” to me. (Sorry, had to mention it somewhere; not related to what you asked.)
Also… “protect mode”? I had never heard anyone call it that way, ever.
I have discovered this since sharing the post. :-( Apparently my shorthand form that I’ve been using for over a third of a century is Bad and Wrong and Incorrect. My mistake.
Not your fault! The article is full of “protect mode” as well, so I assumed the title here was intentional. I suppose someone edited the article content before publishing it and “fixed” protected with protect?
I was an early adopter of Windows – I used Windows 2 in production on my own work computer in 1988/1989, and I told my boss and my boss’ boss at work that Windows 3 was going to be huge and they should both stock up with as many copies as they could get, and that they should let me train the staff on Windows.
They laughed at me. They did not.
We sold out of all 17 (seventeen) copies of Windows 3.0 before 9AM on the day of release, and the company was flooded with enquiries. There was huge interest and nobody else other than me had ever used Windows as an environment. (We sold apps with Runtime Windows, such as Excel, Pagemaker, and the radical Omnis database, AFAIK the first GUI database for the PC, in which my company developed a bespoke app.) But the company regarded Windows as a joke product.
After 6 months of overwork due to being the only person who could support all the customers with Windows 3.0, I quit.
But, yes, at the time, around the start of the 1990s, that was a common term: Windows ran in “protect mode” and it was “protect mode” that let it use XMS as more program RAM and so on. Few other “protect mode” OSes existed: OS/2 1.x, SCO Xenix, and Novell Netware were about it.
Yes, protected mode might have been more accurate, but it was known by the shorter name.
This is not history to me. I am at work right now (and should not be commenting here) and this was an earlier stage of my job. I only switched to being a Linux guy in the 21st century. The first part of my career was as an expert Windows support guy.
As another person who lived through those times, I agree that “protect mode” was commonly heard, though it was also common to hear “protected mode”.
Not that this is by any means definitive, considering how common shortening of such things in a config file context is/was, but this conversation made me think of the OS/2 CONFIG.SYS setting: “PROTECTONLY=NO”. I always looked forward to the day that every app was built for OS/2 and I’d be able to flip that to YES. Still waiting!
It does SMP, it can run thousands of DOS and 16-bit Windows apps, dozens of OS/2 apps, and some Win32 and FOSS/xNix apps. It’s tiny and amazingly quick compared to any modern OS, and I very much include Linux in that. No Linux comes close in performance and about the only thing that even could compete is TinyCoreLinux running from RAM. Alpine Linux is tiny and runs well on early 64-bit kit such as a high-end Core 2 Duo, and ArcaOS absolutely stomps it. It boots faster, apps load faster, it’s more responsive, and it takes less space on disk or RAM.
An ArcaOS with PAE support in the kernel would deliver quite a lot of what I want from an OS even now.
I just don’t have much use for it… :-/
It’s blisteringly quick on low-end kit, but then, so is Windows XP, especially XP64, and XP has a lot more apps and is much easier to get running. It’s just horribly insecure.
Lol I enjoyed the article, thanks. I bet OS/2 (er, ArcaOS) does indeed run pretty quick on modern hardware compared to how it ran on my IBM PS/2 Model 70 that packed an almost unimaginably large 6 MB of RAM!
I’ll always love OS/2, both for it being the first “real OS” that I ever ran (and igniting a life-long interest in systems software) and for the lessons I learned as a teenager watching people on Usenet fall further and further into denial that it was all over for it (because of Macro$oft and the corrupt Ziff-Davis, natch). Oh to go back to a time with such low-stakes internet brainrot.
I recently did something that I felt guilty about, because I enjoyed it too much: put XP on a recent machine and went online. It was so fast and responsive, and at that time, you could still get free XP antivirus. You can get tools to find drivers, modern browsers that can handle 202x social networks etc…
It is a forbidden pleasure.
By comparison with modern OSes, WinXP is sleek and fast. Especially XP64 in 8GB of RAM.
I reviewed MS Office 97 when it came out. I hated it: bloated, sluggish, buggy. Now, it’s tiny and fast. It runs perfectly on WINE, including installing the service releases. Time makes a lot of difference. But it’s one suite.
XP makes one look at modern Windows and Linux and realise how appallingly sluggish everything is today.
But ArcaOS flies on machines that are low-end for XP. It can use up to 64 cores, it can just about do wifi and multihead true-colour accelerated graphics, USB2, UEFI… it has browsers, it has the yum command and repos with FOSS ports. It is surprisingly capable for a late-1990s OS.
The only big thing it can’t do is access >4GB RAM, except for a big fast RAMdisk.
It reminded me why I thought XP was a bloated mess in 2001.
My father’s company got its first Windows 3 install bundled with an app. A vector drawing program, I think it was called MetaDesign, decided it was cheaper to write a Windows 3 app and bundle a copy of Windows for DOS users than to write or license a vector drawing library and printer drivers for DOS. Before that, they used GEM, but once they had Windows installed it was easy to sell them more Windows apps.
I never ran 3.0 in protected mode though, only ever on real mode on an 8086 or 386 Enhanced Mode on an 80386 or newer. I was quite happy with that, because the 80286’s segmentation model was a thing that you teach in computer architecture courses as a cautionary tale.
This was a standard thing to do in the Windows 2 era. It was known as “runtime Windows” and the result was most of a Windows installation, but rejigged: there was no WIN.COM and instead users ran the binary of the app itself from DOS, which loaded Windows with the app as “shell”. Quit the app, Windows shut down.
It worked fine. I had a client in London, Mentorn – they’re still around – whose accounts department ran on Excel, but which didn’t use Windows for anything else. So it was Excel + runtime Windows.
Other apps that did this were Pagemaker and Omnis, the first Windows database.
Snag: it was the plain unaugmented Windows, not Windows/286 or Windows/386. So, it could only use 640kB of RAM and run in Real Mode.
If you installed several such apps, each got its own copy of Runtime Windows.
But if you then installed a full copy of standalone Windows (2 or later) on the machine, you could browse to the app’s directory, run the binary, and it ran normally under full Windows, including interop with other apps. The app was stock and it was Windows that was modified, AFAICT.
I do not recall ever seeing Runtime Windows 3. With Windows 2’s fugly MS-DOS Executive replaced by the perfectly usable Program Manager, Win3 made a quite decent DOS shell that users liked, and some used it with no other apps.
I never ran 3.0 in protected mode though
(!)
It was a thing.
Mainly for me on 386 machines with only 1MB of RAM. Win3 & 3.1 wanted 2MB minimum for 386 Enhanced Mode and if they had less they’d load in Standard Mode by default.
(286s were mostly too slow to comfortably run Windows. Indeed Windows 3 was a major driver of adoption of the 386 via the budget 386SX with a 16-bit bus.
((Aside to the aside: clock-for-lock, the 80286 was quicker than the 80386. But the normal speed of 286 PCs was 8MHz to 10MHz with a few 12MHz. I know of a single 20MHz 286 machine that was ever made, by Dell. Many 10-12MHz 286s had slower RAM and so ran with wait states. CPU cache only became a thing with high-end 386DX machines and most 286s had no cache, so if the RAM couldn’t keep up, the CPU just had to go slower.
(((Most IBM 286 PS/2 models shipped with slow RAM and wait states: in other words, the 286-based PS/2s for which IBM crippled OS/2 1.x and destroyed its chances in the market were lousy slow 286s and unsuitable for running OS/2 1.x, which was about the most demandingh 286 OS ever released, bigger and slower than Netware 2, or Xenix 286, or Concurrent DOS 286.)))
/* I am nesting way too deep here */
The 386SX ran from 16MHz to up to 33 or even 40MHz in some late models. So, 386SX machines were in fact faster than 286s, not because the CPU was inherently quicker – it wasn’t – but because it was clocked faster.
Also, few non-IBM 286s had VGA. Windows on EGA wasn’t very pleasant.))
So, there were lots of decent 386 machines, both 386DX and some 386SX, that were specced to run DOS and only had a meg or two of RAM. I saw some with 1.5 or 1.6MB RAM: 640kB plus 1MB of extended memory. Odd, but cheap.
You could force them to run in Enhanced Mode. I forget the switch now. win /e or something. It worked. You got pre-emption of DOS apps in V86 mode “VMs”, you got virtual memory. It was dog slow but it worked. It wasn’t very stable but Windows 3 wasn’t very stable.
Secondly, Windows could only run in Standard Mode if under another 386 multitasker. So, it ran in Standard Mode under DESQview/386, and DESQview/X, and Concurrent DOS 386, and a few other things.
So it was very much a thing and quite common.)
When I posted here on Lobsters in the past that Windows/286 ran in Standard Mode a lot of people got angry and contradicted me. It seems to me that there still is not a categorical, ex-cathedra statement of exactly how Windows 2 in 286 mode worked.
But Windows 3 in Standard Mode was quite good and made effective use of up to 15.6MB of XMS if you had it – on a 286.
This was a standard thing to do in the Windows 2 era
It’s possible that I misremember. It could have been Windows 2. I think 3.0 was the first one that they rolled out company-wide.
It was a thing.
I know, I just never owned a 286, and the 386s I owned had 4 or 5 MiB of RAM, so there was no point in pretending to be a 286. I went straight from 3.0 in Real mode to 3.1 in Enhanced Mode.
Windows 3.0 ran on my Amstrad PC1640 HD20 (with the hard disk upgraded to a massive 40 MB!). With 640 KiB of RAM, you could run Windows and 1-2 apps. It had an EGA monitor, so you mostly ran one app maximised anyway, which reduced the value of multitasking.
Give it a try. As I recall, it is merely running in “real mode” with the HMA enabled, and with a special version of USER in the HMA. At least that is what the docs included with it say.
What windows/286 does appear to have is an EMS 4.0 / EEMS aware KERNEL, and so it can possibly page below 640K if the h/w implements it. i.e. if the board, chipset and memory cards are set for minimal base memory, and EMS “backfill”.
Or at least that is the impression I got a number of years ago when I had a try at disassembling some of its KERNEL.* I looks like that was removed/deleted/replaced when the Windows 3.0 scheme with support for DPMI was eventually created. Which would make sense, as it is simpler.
I’d have to suggest that you’d need to offer proof for windows/286 operating in “standard” i.e. 286 protected mode, as that goes against everything I’ve seen written in the past. So maybe take those images from the site above, and get them working in such a mode.
A place I worked at during 88 - 89 had a copy of Windows/386 and Windows/286, and us developers had Acer 286 machines with (usually) 1M RAM and EGA (some lucky folks had 2M). As I recall, none of us tried running those particular Windows versions. Trying Windows/386 would have been pointless (despite there being a handfull of 386 machines), and we did give plain windows a go. Yes it was painful in EGA (or even CGA) mode.
On the other hand, Windows/286 knows how to use LIM 4.0 boards to store and swap executable code. Older versions didn’t even know how to use LIM EMS 3.0.
Give it a try. As I recall, it is merely running in “real mode” with the HMA enabled, and with a special version of USER in the HMA.
Interesting stuff. Thanks, and for the PC Mag link.
I am not bothered enough to try to run up some kind of 286 PC emulator to try it out. I do not miss Windows 2.x at all and have no urge to return.
It’s very interesting to me, though, that pivotal parts of the development of IT in the 1980s and 1990s is being forgotten now… because without knowing this stuff, some things about how it is today make no sense at all.
This industry needs to know its history much better.
Thanks for sharing the post. I suggested a title change to “Protected…” and if a few others do as well, we can stop discussing your shorthand and it’ll be easier to stick to the substance of the article. I enjoyed the post you shared from landley.net as well.
I find this tremendously interesting, because my head was firmly in Mac space at this time, so I missed much of it.
Can someone explain why, in the x86 memory model, it was designed with overlapping segments? It seems like needless complication and only limits the total addressable space.
I can’t speak to why they did it, but can say it was really useful.
It means you can have a 64Kb segment - perhaps a COM file - and load it at any 16 byte boundary. If the program internally only used near pointers, segments couldn’t overlap, and memory was physically addressed, the program could only be placed at a 64Kb boundary.
It means if you have a program with 48Kb of code and 48Kb of data, it only needs 96Kb of RAM. If the code and data were on different segments and there was no overlap, it would need 128Kb.
Protected mode approached the problem by adding a redirection layer (the LDT) so a program can start on a segment boundary, have multiple variable sized segments, and the operating system gets to decide where those segments start in physical memory.
Remember that, when the 8086/8088 were first designed, Intel was attempting to extend the current limit of 64kB. One megabyte was an immense increase over that. In theory they could have increased it further, but every increase in maximum memory size required an extra pin on the chip to communicate the memory address. The 8086 was already overloading four pins to get to 20-bit memory addresses without altering the 40-pin socket size that the 8080 had already made standard. There would have been much greater friction to adopting the 8086 if it didn’t fit with existing hardware. Without a clear need for >1MB storage at the time, it was an entirely reasonable and practical decision.
Ignoring 12 bits from the segment register doesn’t actually get you anything, though; it just imposes an arbitrary limitation. To you it might feel more natural, but anyone could choose to use it in that fashion if they wanted (by only setting the top four bits and keeping the lower 12 bits off). Whereas the 8086’s method allows for other possible uses (e.g. perhaps using the segment register to create a sliding window across a large data object).
It’s 1978. Intel is designing their ultimate CPU to end CPUs (the iAPX 432), but in the meantime, it was apparent that a 64K limit was going to be an issue in the short term. So they quickly designed the 8086 as a kind of 16-bit version of the 8080 (with some inspiration from the Z80). It wasn’t object-code compatible, but it was (more or less) source compatible with it [1]. But 16-bits can only address 64K, so to get around that they went with a segment addressing scheme with four segments, code, data, stack and an extra one just because. And they limited the address space to 20 bits because 1) it would have made the chip larger and thus more expensive, and 2) memory was still very expensive anyway. It was never meant to last as long as it did.
At the same time, Motorola was designing the 68000, a much nicer 32-bit architecture that wasn’t object or source compatible with anything prior that it had. At the time, it wasn’t known which was the better option. Now, we know who won.
[1] You could write an assembler that accepted 8080/Z80 mnemonics and generated 8086 object code. It woudn’t be optimal code, but it would be something to get you running quickly on a new architecture when assembly language was still the way to go.
There’s a little bit more to it. The ‘obvious’ way of having a 20-bit address space is to add a 4-bit segment register that provide the high bits, but this makes it impossible to have dynamically sized segments. With the overlapping model, you can choose how many bits come from each, on a per-segment basis (there’s no memory protection, so this is purely a book-keeping exercise). A segment ID can give you anything from 16 bytes to 64 KiB (just make sure you tell the OS how much you’re using so it doesn’t put other things there!). If you had to allocate 64 KiB for every segment, you’d end up running out of memory. A DOS memory map often had half a dozen TSRs squeezed into around 60-100 KiB of RAM, with a 4-bit selector they’d have each needed a separate 64 KiB and you’d have run out of space.
In a few cases, it was even useful to have overlapping segments, so you could name the same memory via two segments.
Moving to a 32-bit architecture made all registers and ALU paths 32 bits, which added a lot of cost. Back then, yields were low, so doubling the area increased the costs by a lot more than double. Doubling the area halves the number of chips and a single defect can make the entire chip defective, so you get fewer than half as many usable chips from a wafer of chips that are double the size.
I think the m68k had some variants with a 16-bit data bus (so two bus cycles to load or store a full register, plus whatever the memory latency was), but the 8086 could be scaled down further to an 8-bit data bus. It could run mostly 8-bit code using the 8-bit subregisters and then the load latency didn’t matter because you’re not loading a full register’s contents. The original IBM PC used this version so that it could use 8-bit data paths everywhere on the motherboard and save costs (the 386sx was introduced for the same reason: a 16-bit data bus on a 32-bit processor).
The m68k was a better architecture but it was a lot more expensive to build a system around, and even the cost difference from an 8080 or Z80 to an 8088 was non-trivial. The original IBM PC cost around $5,000 in today’s money (I think that’s for the version with 64 KiB of RAM and a BASIC interpreter in ROM). that’s a lot more than a 6502 or Z80-based home computer of the same era, which would typically have 16 KiB of RAM (32-64 KiB in later models - the Commodore 64 had 64 KiB and was released a year after the IBM PC and cost less than half as much).
The original m68000 had a 16 bit data bus - internal and external. I believe the 68020 was the first with a 32 bit ALU, and a 32 bit external data bus.
There was an 8 bit data bus version, the m68008, as used in the Sinclair QL.
Wow, a 32-bit processor on an 8-bit data bus must have been really awful. It looks like it didn’t have any caches, so even instruction fetch must have taken two cycles to return a 16-bit instruction, even with burst reads (slower if you take a branch). No wonder the performance was bad. As I recall, m68k was a variable-width instruction set, and maybe larger instructions did more work so loading a 32-bit instruction may have better amortised the load time (this was back in the days when CPU performance was measured in cycles per instruction not instructions per cycle). A full register-width load would be four cycles (the address registers might have been three, if they just unconditionally set the top bits to zero?).
Wow, a 32-bit processor on an 8-bit data bus must have been really awful.
It was not impressive, even when new. One of the sad things is that several successor models of the Sinclair QL line – such as the CST Thor – kept the 68008, or kept the 8-bit motherboard but with a faster CPU, which could not overcome the bandwidth issues.
However, the 68008 sold for a while for the same reason that the 80386SX sold: the motherboards were easier to design and manufacture, so they were cheaper, and the RAM was much cheaper because it essentially used the RAM of the previous processor generation.
386SX machines had a 16-bit motherboard and 16-bit RAM, which was well known to the PC industry from years of making 80286 machines with 16-bit motherboards and 16-bit RAM… these just needed to run a bit quicker. But not massively quicker because the PC-AT or ISA bus was still the only option an it only ran at 8MHz unless the vendor wanted to push it and risk incompatibility.
Nearly a decade earlier, the QL was internally 32-bit in places, but it needed just an 8-bit motherboard and 8-bit RAM.
At launch, the QL cost £399, equivalent to £1,600 ($2,000) today. A bargain compared to the $2,495 Macintosh, which would be $7,600 (£6,000) today.
When it was new, filling a QL’s memory bus with RAM would have cost something like £10,000 in contemporary terms. If you had £10K ($20K US) spare you didn’t buy a QL, you bought a SUN-1 or something.
One of the single most impressive homebrew computers I’ve seen is the Kiwi, a 68008 machine with 4MB of RAM that can even run EmuTOS.
(Well strictly the 68000 implementation architecture is 16 bit, just that the registers allowed for 32 bit use. Certainly some early C compilers treated it as 16 bit, gaining performance over if they’’d had ‘int’ as 32 bit)
There is an area in the 8086/8088 architecture where the 8 bit version (8088) struck me as better than the 68000/68008 approach. That is apart from the 8086 having some 1 byte instructions, and (probably - I can’t recall) odd length instructions >= 3 bytes.
Specifically the split between the Bus Interface Unit, the Execution Unit, and the Prefetch Queue in the 8086/8088. AFAICT, the 68008 always had do perform reads in groups of two byte fetches when reading instructions, as each instruction was a multiple of 16 bits.
Now there is a “two-word, tightly-coupled, instruction prefetch mechanism” in the 68000 family. Whereas the 8086/8088 had a 6 or 4 byte (depending upon chip) asynchronous prefetch qeue. I suspect the latter worked better in the 8 bit implementations.
There is a loop mode available on the 68010, which allows for speed up of loops within the length the of the overlapped instruction fetch/decode/execute pipeline. That pipeline (sans loop mode) was apparently there in the 68000, but I believe the pipeline runs in fixed lockstep, not allowing the semi-decoupled asynchronous behaviour of the 8086/8088.
Back to the QL, I seem to recall some part of the system design an implementation crippled it over and above the 68008’s limitations. Namely that some parts of the system did cycle stealing, and that bugs in some of the support chips (and/or Sinclair’s usual penny-pinching) made things slower still.
We’re seeing something similar now, though in a very different domain. One of the big reasons that CXL.mem is getting interest is that cloud providers are putting the latest DDR standard in new machines and have a lot of the previous generation that’s destined for landfill if no one can think of anything to do with it. If you’re on the remote end of a CXL connection (typically 1500 cycles latency) then the difference between DDR4 and DDR5 performance is not that massive. If you can use local DDR5 and remote DDR4, you can provide a lot more RAM to customers, basically for free. And RAM is the limit for a lot of cloud scalability: you can often pad other workloads into unused CPU time, but RAM is spatially multiplexed and the few (small) vendors that overprovision RAM and do swapping have truly appalling performance, but if you can use slower (but still within an order of magnitude) RAM for cool data and, ideally, share common cool data across nodes then there are big savings.
It’s basically PCIe over a wider network. Reinventing mainframe backplanes with more modern technology. CXL.mem is the subset required for memory, there are additional standards for putting richer compute things on the far end.
Now all we need is the Raymond Chen “DVD commentary.”
This is the version I found years ago via the Old New Thing…
https://www.landley.net/history/mirror/ms/davidweise.html
The story as it used to be told (when I lived in Redmond) was that he showed BillG and someone asked BillG “you know what this means, right?” (referring to their OS2 partnership with IBM), and BillG responded: “Yeah, fuck IBM.”
The page doesn’t explain why the CPU needed a separate, incompatible “protect mode” to access more memory. I learned more about that from the following Wikipedia pages, which I have summarized.
Real mode, also called real address mode, was once the only mode of Intel CPUs, so operating systems already supported it. In this mode, addresses always correspond to real locations in memory. For backwards compatibility, x86 CPUs still start up in real mode, though modern operating systems turn on protected mode when booting so as to be able to access more than 1 MiB of memory.
Protected mode, also called protected virtual address mode, enables virtual memory, paging, and other features. The mode was backwards incompatible with real mode because it reinterpreted some bits of a memory address to point to memory indirectly via an entry inside a descriptor table. It also reinterpreted two bits as defining the privilege of the memory request.
Protected mode was introduced in the Intel 80286 processor, the one mentioned in the article. The Wikipedia article on the processor has sections on its protected mode and its OS support.
May I suggest two articles I wrote at the beginning of the year that go deep into this topic? :)
One is https://blogsystem5.substack.com/p/from-0-to-1-mb-in-dos and talks about the real mode limitations and difficulties mentioned in the article. The other is https://blogsystem5.substack.com/p/beyond-the-1-mb-barrier-in-dos and talks about protected mode and the DOS extenders also mentioned in the article. Hope they are a useful summary to later navigate other Wikipedia content!
Also… “protect mode”? I had never heard anyone call it that way, ever. It has always been “protected mode” to me. (Sorry, had to mention it somewhere; not related to what you asked.)
Me neither, and I’ve known about protected mode since the 90s.
I have discovered this since sharing the post. :-( Apparently my shorthand form that I’ve been using for over a third of a century is Bad and Wrong and Incorrect. My mistake.
Not your fault! The article is full of “protect mode” as well, so I assumed the title here was intentional. I suppose someone edited the article content before publishing it and “fixed” protected with protect?
Does a double take
So it is.
OK, so, I think I retract my apology, then.
I was an early adopter of Windows – I used Windows 2 in production on my own work computer in 1988/1989, and I told my boss and my boss’ boss at work that Windows 3 was going to be huge and they should both stock up with as many copies as they could get, and that they should let me train the staff on Windows.
They laughed at me. They did not.
We sold out of all 17 (seventeen) copies of Windows 3.0 before 9AM on the day of release, and the company was flooded with enquiries. There was huge interest and nobody else other than me had ever used Windows as an environment. (We sold apps with Runtime Windows, such as Excel, Pagemaker, and the radical Omnis database, AFAIK the first GUI database for the PC, in which my company developed a bespoke app.) But the company regarded Windows as a joke product.
After 6 months of overwork due to being the only person who could support all the customers with Windows 3.0, I quit.
But, yes, at the time, around the start of the 1990s, that was a common term: Windows ran in “protect mode” and it was “protect mode” that let it use XMS as more program RAM and so on. Few other “protect mode” OSes existed: OS/2 1.x, SCO Xenix, and Novell Netware were about it.
Yes, protected mode might have been more accurate, but it was known by the shorter name.
This is not history to me. I am at work right now (and should not be commenting here) and this was an earlier stage of my job. I only switched to being a Linux guy in the 21st century. The first part of my career was as an expert Windows support guy.
As another person who lived through those times, I agree that “protect mode” was commonly heard, though it was also common to hear “protected mode”.
Not that this is by any means definitive, considering how common shortening of such things in a config file context is/was, but this conversation made me think of the OS/2 CONFIG.SYS setting: “PROTECTONLY=NO”. I always looked forward to the day that every app was built for OS/2 and I’d be able to flip that to YES. Still waiting!
Thank you!
Tried ArcaOS? :-)
Honestly, it’s pretty good. I tried it.
It does SMP, it can run thousands of DOS and 16-bit Windows apps, dozens of OS/2 apps, and some Win32 and FOSS/xNix apps. It’s tiny and amazingly quick compared to any modern OS, and I very much include Linux in that. No Linux comes close in performance and about the only thing that even could compete is TinyCoreLinux running from RAM. Alpine Linux is tiny and runs well on early 64-bit kit such as a high-end Core 2 Duo, and ArcaOS absolutely stomps it. It boots faster, apps load faster, it’s more responsive, and it takes less space on disk or RAM.
An ArcaOS with PAE support in the kernel would deliver quite a lot of what I want from an OS even now.
I just don’t have much use for it… :-/
It’s blisteringly quick on low-end kit, but then, so is Windows XP, especially XP64, and XP has a lot more apps and is much easier to get running. It’s just horribly insecure.
Lol I enjoyed the article, thanks. I bet OS/2 (er, ArcaOS) does indeed run pretty quick on modern hardware compared to how it ran on my IBM PS/2 Model 70 that packed an almost unimaginably large 6 MB of RAM!
I’ll always love OS/2, both for it being the first “real OS” that I ever ran (and igniting a life-long interest in systems software) and for the lessons I learned as a teenager watching people on Usenet fall further and further into denial that it was all over for it (because of Macro$oft and the corrupt Ziff-Davis, natch). Oh to go back to a time with such low-stakes internet brainrot.
Thanks!
Yes, I agree.
I recently did something that I felt guilty about, because I enjoyed it too much: put XP on a recent machine and went online. It was so fast and responsive, and at that time, you could still get free XP antivirus. You can get tools to find drivers, modern browsers that can handle 202x social networks etc…
It is a forbidden pleasure.
By comparison with modern OSes, WinXP is sleek and fast. Especially XP64 in 8GB of RAM.
I reviewed MS Office 97 when it came out. I hated it: bloated, sluggish, buggy. Now, it’s tiny and fast. It runs perfectly on WINE, including installing the service releases. Time makes a lot of difference. But it’s one suite.
XP makes one look at modern Windows and Linux and realise how appallingly sluggish everything is today.
But ArcaOS flies on machines that are low-end for XP. It can use up to 64 cores, it can just about do wifi and multihead true-colour accelerated graphics, USB2, UEFI… it has browsers, it has the
yumcommand and repos with FOSS ports. It is surprisingly capable for a late-1990s OS.The only big thing it can’t do is access >4GB RAM, except for a big fast RAMdisk.
It reminded me why I thought XP was a bloated mess in 2001.
[Comment removed by author]
My father’s company got its first Windows 3 install bundled with an app. A vector drawing program, I think it was called MetaDesign, decided it was cheaper to write a Windows 3 app and bundle a copy of Windows for DOS users than to write or license a vector drawing library and printer drivers for DOS. Before that, they used GEM, but once they had Windows installed it was easy to sell them more Windows apps.
I never ran 3.0 in protected mode though, only ever on real mode on an 8086 or 386 Enhanced Mode on an 80386 or newer. I was quite happy with that, because the 80286’s segmentation model was a thing that you teach in computer architecture courses as a cautionary tale.
This was a standard thing to do in the Windows 2 era. It was known as “runtime Windows” and the result was most of a Windows installation, but rejigged: there was no
WIN.COMand instead users ran the binary of the app itself from DOS, which loaded Windows with the app as “shell”. Quit the app, Windows shut down.It worked fine. I had a client in London, Mentorn – they’re still around – whose accounts department ran on Excel, but which didn’t use Windows for anything else. So it was Excel + runtime Windows.
Other apps that did this were Pagemaker and Omnis, the first Windows database.
Snag: it was the plain unaugmented Windows, not Windows/286 or Windows/386. So, it could only use 640kB of RAM and run in Real Mode.
If you installed several such apps, each got its own copy of Runtime Windows.
But if you then installed a full copy of standalone Windows (2 or later) on the machine, you could browse to the app’s directory, run the binary, and it ran normally under full Windows, including interop with other apps. The app was stock and it was Windows that was modified, AFAICT.
I do not recall ever seeing Runtime Windows 3. With Windows 2’s fugly MS-DOS Executive replaced by the perfectly usable Program Manager, Win3 made a quite decent DOS shell that users liked, and some used it with no other apps.
(!)
It was a thing.
Mainly for me on 386 machines with only 1MB of RAM. Win3 & 3.1 wanted 2MB minimum for 386 Enhanced Mode and if they had less they’d load in Standard Mode by default.
(286s were mostly too slow to comfortably run Windows. Indeed Windows 3 was a major driver of adoption of the 386 via the budget 386SX with a 16-bit bus.
((Aside to the aside: clock-for-lock, the 80286 was quicker than the 80386. But the normal speed of 286 PCs was 8MHz to 10MHz with a few 12MHz. I know of a single 20MHz 286 machine that was ever made, by Dell. Many 10-12MHz 286s had slower RAM and so ran with wait states. CPU cache only became a thing with high-end 386DX machines and most 286s had no cache, so if the RAM couldn’t keep up, the CPU just had to go slower.
(((Most IBM 286 PS/2 models shipped with slow RAM and wait states: in other words, the 286-based PS/2s for which IBM crippled OS/2 1.x and destroyed its chances in the market were lousy slow 286s and unsuitable for running OS/2 1.x, which was about the most demandingh 286 OS ever released, bigger and slower than Netware 2, or Xenix 286, or Concurrent DOS 286.)))
/* I am nesting way too deep here */
The 386SX ran from 16MHz to up to 33 or even 40MHz in some late models. So, 386SX machines were in fact faster than 286s, not because the CPU was inherently quicker – it wasn’t – but because it was clocked faster.
Also, few non-IBM 286s had VGA. Windows on EGA wasn’t very pleasant.))
So, there were lots of decent 386 machines, both 386DX and some 386SX, that were specced to run DOS and only had a meg or two of RAM. I saw some with 1.5 or 1.6MB RAM: 640kB plus 1MB of extended memory. Odd, but cheap.
You could force them to run in Enhanced Mode. I forget the switch now.
win /eor something. It worked. You got pre-emption of DOS apps in V86 mode “VMs”, you got virtual memory. It was dog slow but it worked. It wasn’t very stable but Windows 3 wasn’t very stable.Secondly, Windows could only run in Standard Mode if under another 386 multitasker. So, it ran in Standard Mode under DESQview/386, and DESQview/X, and Concurrent DOS 386, and a few other things.
So it was very much a thing and quite common.)
When I posted here on Lobsters in the past that Windows/286 ran in Standard Mode a lot of people got angry and contradicted me. It seems to me that there still is not a categorical, ex-cathedra statement of exactly how Windows 2 in 286 mode worked.
But Windows 3 in Standard Mode was quite good and made effective use of up to 15.6MB of XMS if you had it – on a 286.
It’s possible that I misremember. It could have been Windows 2. I think 3.0 was the first one that they rolled out company-wide.
I know, I just never owned a 286, and the 386s I owned had 4 or 5 MiB of RAM, so there was no point in pretending to be a 286. I went straight from 3.0 in Real mode to 3.1 in Enhanced Mode.
Windows 3.0 ran on my Amstrad PC1640 HD20 (with the hard disk upgraded to a massive 40 MB!). With 640 KiB of RAM, you could run Windows and 1-2 apps. It had an EGA monitor, so you mostly ran one app maximised anyway, which reduced the value of multitasking.
See here: https://winworldpc.com/product/windows-20/windows-286
Give it a try. As I recall, it is merely running in “real mode” with the HMA enabled, and with a special version of USER in the HMA. At least that is what the docs included with it say.
What windows/286 does appear to have is an EMS 4.0 / EEMS aware KERNEL, and so it can possibly page below 640K if the h/w implements it. i.e. if the board, chipset and memory cards are set for minimal base memory, and EMS “backfill”.
Or at least that is the impression I got a number of years ago when I had a try at disassembling some of its KERNEL.* I looks like that was removed/deleted/replaced when the Windows 3.0 scheme with support for DPMI was eventually created. Which would make sense, as it is simpler.
I’d have to suggest that you’d need to offer proof for windows/286 operating in “standard” i.e. 286 protected mode, as that goes against everything I’ve seen written in the past. So maybe take those images from the site above, and get them working in such a mode.
A place I worked at during 88 - 89 had a copy of Windows/386 and Windows/286, and us developers had Acer 286 machines with (usually) 1M RAM and EGA (some lucky folks had 2M). As I recall, none of us tried running those particular Windows versions. Trying Windows/386 would have been pointless (despite there being a handfull of 386 machines), and we did give plain windows a go. Yes it was painful in EGA (or even CGA) mode.
Interesting stuff. Thanks, and for the PC Mag link.
I am not bothered enough to try to run up some kind of 286 PC emulator to try it out. I do not miss Windows 2.x at all and have no urge to return.
It’s very interesting to me, though, that pivotal parts of the development of IT in the 1980s and 1990s is being forgotten now… because without knowing this stuff, some things about how it is today make no sense at all.
This industry needs to know its history much better.
Thanks for sharing the post. I suggested a title change to “Protected…” and if a few others do as well, we can stop discussing your shorthand and it’ll be easier to stick to the substance of the article. I enjoyed the post you shared from landley.net as well.
I find this tremendously interesting, because my head was firmly in Mac space at this time, so I missed much of it.
These days, it’s already the firmware (UEFI) that enters protected mode. It’s also the only mode supported by long mode. (aka 64-bit mode, aka x86-64)
Can someone explain why, in the x86 memory model, it was designed with overlapping segments? It seems like needless complication and only limits the total addressable space.
I can’t speak to why they did it, but can say it was really useful.
It means you can have a 64Kb segment - perhaps a COM file - and load it at any 16 byte boundary. If the program internally only used near pointers, segments couldn’t overlap, and memory was physically addressed, the program could only be placed at a 64Kb boundary.
It means if you have a program with 48Kb of code and 48Kb of data, it only needs 96Kb of RAM. If the code and data were on different segments and there was no overlap, it would need 128Kb.
Protected mode approached the problem by adding a redirection layer (the LDT) so a program can start on a segment boundary, have multiple variable sized segments, and the operating system gets to decide where those segments start in physical memory.
Remember that, when the 8086/8088 were first designed, Intel was attempting to extend the current limit of 64kB. One megabyte was an immense increase over that. In theory they could have increased it further, but every increase in maximum memory size required an extra pin on the chip to communicate the memory address. The 8086 was already overloading four pins to get to 20-bit memory addresses without altering the 40-pin socket size that the 8080 had already made standard. There would have been much greater friction to adopting the 8086 if it didn’t fit with existing hardware. Without a clear need for >1MB storage at the time, it was an entirely reasonable and practical decision.
I don’t understand why that requires the inane segment overlap though? Why not only look at the bottom 20 bits of the address?
Ignoring 12 bits from the segment register doesn’t actually get you anything, though; it just imposes an arbitrary limitation. To you it might feel more natural, but anyone could choose to use it in that fashion if they wanted (by only setting the top four bits and keeping the lower 12 bits off). Whereas the 8086’s method allows for other possible uses (e.g. perhaps using the segment register to create a sliding window across a large data object).
It’s 1978. Intel is designing their ultimate CPU to end CPUs (the iAPX 432), but in the meantime, it was apparent that a 64K limit was going to be an issue in the short term. So they quickly designed the 8086 as a kind of 16-bit version of the 8080 (with some inspiration from the Z80). It wasn’t object-code compatible, but it was (more or less) source compatible with it [1]. But 16-bits can only address 64K, so to get around that they went with a segment addressing scheme with four segments, code, data, stack and an extra one just because. And they limited the address space to 20 bits because 1) it would have made the chip larger and thus more expensive, and 2) memory was still very expensive anyway. It was never meant to last as long as it did.
At the same time, Motorola was designing the 68000, a much nicer 32-bit architecture that wasn’t object or source compatible with anything prior that it had. At the time, it wasn’t known which was the better option. Now, we know who won.
[1] You could write an assembler that accepted 8080/Z80 mnemonics and generated 8086 object code. It woudn’t be optimal code, but it would be something to get you running quickly on a new architecture when assembly language was still the way to go.
There’s a little bit more to it. The ‘obvious’ way of having a 20-bit address space is to add a 4-bit segment register that provide the high bits, but this makes it impossible to have dynamically sized segments. With the overlapping model, you can choose how many bits come from each, on a per-segment basis (there’s no memory protection, so this is purely a book-keeping exercise). A segment ID can give you anything from 16 bytes to 64 KiB (just make sure you tell the OS how much you’re using so it doesn’t put other things there!). If you had to allocate 64 KiB for every segment, you’d end up running out of memory. A DOS memory map often had half a dozen TSRs squeezed into around 60-100 KiB of RAM, with a 4-bit selector they’d have each needed a separate 64 KiB and you’d have run out of space.
In a few cases, it was even useful to have overlapping segments, so you could name the same memory via two segments.
Moving to a 32-bit architecture made all registers and ALU paths 32 bits, which added a lot of cost. Back then, yields were low, so doubling the area increased the costs by a lot more than double. Doubling the area halves the number of chips and a single defect can make the entire chip defective, so you get fewer than half as many usable chips from a wafer of chips that are double the size.
I think the m68k had some variants with a 16-bit data bus (so two bus cycles to load or store a full register, plus whatever the memory latency was), but the 8086 could be scaled down further to an 8-bit data bus. It could run mostly 8-bit code using the 8-bit subregisters and then the load latency didn’t matter because you’re not loading a full register’s contents. The original IBM PC used this version so that it could use 8-bit data paths everywhere on the motherboard and save costs (the 386sx was introduced for the same reason: a 16-bit data bus on a 32-bit processor).
The m68k was a better architecture but it was a lot more expensive to build a system around, and even the cost difference from an 8080 or Z80 to an 8088 was non-trivial. The original IBM PC cost around $5,000 in today’s money (I think that’s for the version with 64 KiB of RAM and a BASIC interpreter in ROM). that’s a lot more than a 6502 or Z80-based home computer of the same era, which would typically have 16 KiB of RAM (32-64 KiB in later models - the Commodore 64 had 64 KiB and was released a year after the IBM PC and cost less than half as much).
The original m68000 had a 16 bit data bus - internal and external. I believe the 68020 was the first with a 32 bit ALU, and a 32 bit external data bus.
There was an 8 bit data bus version, the m68008, as used in the Sinclair QL.
Wow, a 32-bit processor on an 8-bit data bus must have been really awful. It looks like it didn’t have any caches, so even instruction fetch must have taken two cycles to return a 16-bit instruction, even with burst reads (slower if you take a branch). No wonder the performance was bad. As I recall, m68k was a variable-width instruction set, and maybe larger instructions did more work so loading a 32-bit instruction may have better amortised the load time (this was back in the days when CPU performance was measured in cycles per instruction not instructions per cycle). A full register-width load would be four cycles (the address registers might have been three, if they just unconditionally set the top bits to zero?).
I am glad I live in the future.
It was not impressive, even when new. One of the sad things is that several successor models of the Sinclair QL line – such as the CST Thor – kept the 68008, or kept the 8-bit motherboard but with a faster CPU, which could not overcome the bandwidth issues.
However, the 68008 sold for a while for the same reason that the 80386SX sold: the motherboards were easier to design and manufacture, so they were cheaper, and the RAM was much cheaper because it essentially used the RAM of the previous processor generation.
386SX machines had a 16-bit motherboard and 16-bit RAM, which was well known to the PC industry from years of making 80286 machines with 16-bit motherboards and 16-bit RAM… these just needed to run a bit quicker. But not massively quicker because the PC-AT or ISA bus was still the only option an it only ran at 8MHz unless the vendor wanted to push it and risk incompatibility.
Nearly a decade earlier, the QL was internally 32-bit in places, but it needed just an 8-bit motherboard and 8-bit RAM.
I wrote about the QL at the start of the year when it turned 40.
I will quote myself:
When it was new, filling a QL’s memory bus with RAM would have cost something like £10,000 in contemporary terms. If you had £10K ($20K US) spare you didn’t buy a QL, you bought a SUN-1 or something.
One of the single most impressive homebrew computers I’ve seen is the Kiwi, a 68008 machine with 4MB of RAM that can even run EmuTOS.
(Well strictly the 68000 implementation architecture is 16 bit, just that the registers allowed for 32 bit use. Certainly some early C compilers treated it as 16 bit, gaining performance over if they’’d had ‘int’ as 32 bit)
There is an area in the 8086/8088 architecture where the 8 bit version (8088) struck me as better than the 68000/68008 approach. That is apart from the 8086 having some 1 byte instructions, and (probably - I can’t recall) odd length instructions >= 3 bytes.
Specifically the split between the Bus Interface Unit, the Execution Unit, and the Prefetch Queue in the 8086/8088. AFAICT, the 68008 always had do perform reads in groups of two byte fetches when reading instructions, as each instruction was a multiple of 16 bits.
Now there is a “two-word, tightly-coupled, instruction prefetch mechanism” in the 68000 family. Whereas the 8086/8088 had a 6 or 4 byte (depending upon chip) asynchronous prefetch qeue. I suspect the latter worked better in the 8 bit implementations.
There is a loop mode available on the 68010, which allows for speed up of loops within the length the of the overlapped instruction fetch/decode/execute pipeline. That pipeline (sans loop mode) was apparently there in the 68000, but I believe the pipeline runs in fixed lockstep, not allowing the semi-decoupled asynchronous behaviour of the 8086/8088.
Back to the QL, I seem to recall some part of the system design an implementation crippled it over and above the 68008’s limitations. Namely that some parts of the system did cycle stealing, and that bugs in some of the support chips (and/or Sinclair’s usual penny-pinching) made things slower still.
We’re seeing something similar now, though in a very different domain. One of the big reasons that CXL.mem is getting interest is that cloud providers are putting the latest DDR standard in new machines and have a lot of the previous generation that’s destined for landfill if no one can think of anything to do with it. If you’re on the remote end of a CXL connection (typically 1500 cycles latency) then the difference between DDR4 and DDR5 performance is not that massive. If you can use local DDR5 and remote DDR4, you can provide a lot more RAM to customers, basically for free. And RAM is the limit for a lot of cloud scalability: you can often pad other workloads into unused CPU time, but RAM is spatially multiplexed and the few (small) vendors that overprovision RAM and do swapping have truly appalling performance, but if you can use slower (but still within an order of magnitude) RAM for cool data and, ideally, share common cool data across nodes then there are big savings.
Oh my. RAMbus, but over the network?
My initial reaction, instant but totally ill-informed, is horror and revulsion. That’s the nastiest ugliest hack I have heard about since iSCSI.
It’s basically PCIe over a wider network. Reinventing mainframe backplanes with more modern technology. CXL.mem is the subset required for memory, there are additional standards for putting richer compute things on the far end.
That does admittedly sound less ugly…