The 32-bit registers are accessible in real mode too, it only requires a prefix to each opcode (and the same is true when using the 16-bit registers in 32- or 64-bit mode). There is also no restriction on using the FS and GS registers in real mode, they work like any other segment register.
There really is surprisingly little difference between real and protected mode, it mainly affects how segment registers are loaded. Internally, each segment register has a base and limit field that is used the same regardless of mode.
Loading a segment register in real mode sets the base to the value shifted left by 4 bits, but leaves the limit unchanged. By briefly entering protected mode and loading descriptors with a limit of 4 GiB, it would remain that way after switching back to real mode, giving access to the full address space (this is called "flat real", "unreal", or "voodoo" mode).
Oh boy, when you see those game requirements. Today gamers would change GPUs not every year or so but kind of. Those software rendering engines are true gems because the guys who worked on them literally pushed CPU and RAM to their limits and beyond. Is also a reminder of how much you can do with so little. I highly respect and admire people that grew up chewing up assembly during the 80's and 90's, wished I had that pleasure.
I worked in the qualification department for a large memory company around y2k. We ran thousands of computers with samples of all our memory so we could spot issues early. One of our best tests was running Quake in a pre-recorded speed run mode. It could run through in about a minute or so. It torched the CPU and memory and was great at seeing if a system was going to have issues. =)
Interestingly the 286 had a protected mode but very few applications ever used it. There were upgrade kits with then stupid amounts of memory, like 16MB, for then astronomical prices. I wonder how often those were used for anything.
Information about Rational System's 286 extender seems to be limited.
What I found: Rational System were later renamed to Tenberry and their DOS/4G and DOS/4GW extenders were very popular (due to the latter being bundled with Waycom C). But they were for the 386.
The version that worked on the 286 was called DOS/16M, because it supported 16MB of address space. Someone summarises the API here [1]. I was kind of hoping someone might have uploaded the manual to archive.org, but no luck.
Not many I guess; the reason you basically required a "protected runtime" in the first place is because real mode (or a even better thing, the shiny new 386 virtual 8086 mode aka virtual real mode) was very important.
Until the 386, leaving the protected mode was either completly unsupported (I think 186) or you needed heroics involving bugs in the keyboard irc handler (I think 286). Because the OS and most "normal" applications and libraries back them being real-mode only, it means you were locked out of most of the filesystem I/O, and a program with limited filesystem I/O is a very limited program indeed.
On the 286, the only way out of protected mode was via a CPU reset. The keyboard controller (which was a separate chip on the motherboard, an 8042 microcontroller) had a documented command to do that, and one of the first things the BIOS entry point did was to check a flag indicating that the reset was intended to exit from protected mode, if so it gave control back to the application by jumping to a pointer it provided.
Another way to reset the CPU was to cause a "triple fault" - an exception that can't be handled will try to invoke the double fault handler, when that also fails the CPU shuts down, sending a special bus cycle that external hardware would detect and trigger the reset.
This actually became the preferred method since the keyboard controller was quite slow. So slow that it gives you enough time to run an undocumented instruction which dumps the entire CPU state:
Not bugs. IBM literally wired up the keyboard controller to trigger the CPU's reset pin on request as a workaround for getting back to real mode. But not every system has that feature. Some motherboard chipsets had an even faster method for triggering reset; it was all very non-standard.
But the most compatible way to get back to real mode on a 286 was by triggering a triple fault.
When the 286 was designed, there was the idea that no one would like to return to real mode and would happily adopt OS/2 (1.x, not the later graphical one), Xenix and similar OSes, that of course didn't happen, thus 386 had to sort that out.
"The problems led to Bill Gates famously referring to the 80286 as a "brain-dead chip",[25][when?] since it was clear that the new Microsoft Windows environment would not be able to run multiple MS-DOS applications with the 286. It was arguably responsible for the split between Microsoft and IBM, since IBM insisted that OS/2, originally a joint venture between IBM and Microsoft, would run on a 286 (and in text mode).
Other operating systems that used the protected mode of the 286 were Microsoft Xenix (around 1984),[26] Coherent,[27] and Minix.[28] These were less hindered by the limitations of the 80286 protected mode because they did not aim to run MS-DOS applications or other real-mode programs. In its successor 80386 chip, Intel enhanced the protected mode to address more memory and also added the separate virtual 8086 mode, a mode within protected mode with much better MS-DOS compatibility, in order to satisfy the diverging needs of the market."
386 got trapping privileged accesses wrong, not fixed in 486. Problem is Protected Mode programs (CPL 3) executing CLI and expecting POPF to restore interrupt flag - its ignored AND doesnt trap. Afaik no x86 CPU ever fixed it completely.
Microsoft had some hacks trying to detect and patch known common problem patterns:
"In particular, the recompiler is used when guest code disables interrupts and Oracle VM VirtualBox cannot figure out when they will be switched back on. In these situations, Oracle VM VirtualBox actually analyzes the guest code using its own disassembler."
"When the PVI flag is set to 1, the CPL is 3, and the IOPL is less than 3, the STI and CLI instructions set and clear
the VIF flag in the EFLAGS register, leaving IF unaffected. In this mode of operation, an application running in
protected mode and at a CPL of 3 can inhibit interrupts in the same manner as is described in Section 20.3.2, “Class
2—Maskable Hardware Interrupt Handling in Virtual-8086 Mode Using the Virtual Interrupt Mechanism”, for a
virtual-8086 mode task. When the application executes the CLI instruction, the processor clears the VIF flag. If the
processor receives a maskable hardware interrupt, the processor invokes the protected-mode interrupt handler.
This handler checks the state of the VIF flag in the EFLAGS register. If the VIF flag is clear (indicating that the active
task does not want to have interrupts handled now), the handler sets the VIP flag in the EFLAGS image on the stack
and returns to the privilege-level 3 application, which continues program execution. When the application executes
a STI instruction to set the VIF flag, the processor automatically invokes the general-protection exception handler,
which can then handle the pending interrupt. After handing the pending interrupt, the handler typically sets the VIF
flag and clears the VIP flag in the EFLAGS image on the stack and executes a return to the application program. The
next time the processor receives a maskable hardware interrupt, the processor will handle it in the normal manner
for interrupts received while the processor is operating at a CPL of 3."
"The protected-mode virtual-interrupt feature — enabled by setting CR4.PVI — affects the CLI and STI instructions in the same manner as the virtual-8086 mode extensions. POPF, however, is not affected by CR4.PVI"
With 32-bit DOS extenders, VESA VGA BIOS extensions and Gravis Ultrasound, we really did have everything — except an operating system. Who needs one anyway.
Yeah. Until we wanted multitasking. Separate address spaces, shared resources, protection, eventually security. That's when the "operating system" came in. DOS was allowed to live as a virtualized task, but it wasn't the same.
I did get tambourine_man's reference, though. Nice!
Don't be trite in a technical conversation. While I agree that those things are bad, it adds nothing here, and besides only a minority of Operating Systems does what you say.
We even have HxDOS, which runs Win32 applications, including console applications. For example, even a modern version of 7-zip (console version) runs perfectly on ancient DOS computers.
This is something I was able to achieve independently back in 2001 by writing a small DOS program that switched CPU into 32-bit protected mode, loaded a PE (portable executable) exe file into the memory together with DLL modules it depended upon.
The next step was to write KERNEL32.dll etc modules that were used by executable files of interest. It turned out to be a relatively easy task - only a handful of Win32 modules and their API functions were actually used by the real programs I was trying to run under the DOS. And those API implementations were mostly stubs that translated, say, I/O calls from a program into corresponding DOS calls.
Having that trick upon my sleeve, I vividly remember of being able to run 32-bit Borland C++ compiler (bcc32.exe) and linker for Windows under the raw DOS environment. Don't ask why, I did it because I could.
Okay, I won't ask why you did it, but I know I would have liked to run their IDE under DOS instead of Windows. Back in that era, Windows was very slow and clunky, and I was pretty unhappy when I "upgraded" to Borland 4.0 (IIRC) which required Windows.
Fortunately, I switched to Linux around the same time.
I had similar intentions - I was deep into OS development back then, so I wanted to have a 32-bit C/C++ compiler that would effortlessly target 80386+ CPUs.
Borland C++ was my favorite one because it supported official x86 assembly syntax (Intel). In contrast, GNU tools of the day had their own kinky x86 syntax which made me uneasy. It so happened that the Borland compiler that was able to target a 32-bit CPU, required a 32-bit CPU itself to run. DOS only provided 16-bit environment. That's why I went to those lengths of writing a custom 32-bit PE loader that would allow me to run some 32-bit Windows applications right under the DOS.
DOS was a preferable environment because it was fast and allowed booting your own OS kernels without doing a full computer reboot - you just ran an executable loader and it took control away from the DOS and gave it to your OS. And then when you "exited" your OS, instead of rebooting, it was returning back to the DOS provided that the OS kernel you were running was careful enough to preserve/restore the RAM content upon exit.
It gave a huge productivity boost back then. Later, however, I switched to Windows and was using Bochs (open-source x86 PC emulator) to effortlessly run the OS I was working on.
I once asked GNU people why they had such weird non-standard syntax for inline x86 assembly. Their answer was that the GNU syntax was just easier to implement in their existing toolchain of the day. Their big idea was to have a semi-universal implementation of the assembler where a particular CPU syntax was just a small, mostly declarative piece of code and configuration. The support of the canonical Intel syntax for x86 assembly would require significantly more efforts. As far as I know, the idea of a weird but universal assembly syntax came from the original Unix developed by AT&T. My take was: come on, it's just a syntax, a relatively miniscule effort required to implement the idiomatic x86 assembly support is nothing compared to pains a custom non-standard syntax may give to people.
Aside from the software, I’d love a modern version of this laptop too. Sturdy keys with lots of travel, just the right screen size. Imagine a unibody built of this form factor, with modern SSD and RAM. The amount of battery one could fit in at that thickness would last you a week in a single charge.
There really is surprisingly little difference between real and protected mode, it mainly affects how segment registers are loaded. Internally, each segment register has a base and limit field that is used the same regardless of mode.
Loading a segment register in real mode sets the base to the value shifted left by 4 bits, but leaves the limit unchanged. By briefly entering protected mode and loading descriptors with a limit of 4 GiB, it would remain that way after switching back to real mode, giving access to the full address space (this is called "flat real", "unreal", or "voodoo" mode).