Hacker News Reader

Comment by ElectricalUnion | Hacker News Reader

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.

View on HN

186 didn't have protected mode :)

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:

https://rep-lodsb.mataroa.blog/blog/intel-286-secrets-ice-mo...

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.

I think the 286 was designed way before any of that was a consideration. It was first released in 1982, just a couple of months after the IBM PC.

From its Wikipedia article,

"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:

Getting MS-DOS games to run on Windows 95: The interrupt flag https://devblogs.microsoft.com/oldnewthing/20160411-00/?p=93...

Virtualbox switches to software tricks: https://docs.oracle.com/en/virtualization/virtualbox/6.0/adm...

"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."

ReactOS didnt even try. "ReactOS' NTVDM on the other hand, is a software emulator just like DOSBox": https://web.archive.org/web/20170723164052/http://community.... https://web.archive.org/web/20151216085857/http://community....

https://xem.github.io/minix86/manual/intel-x86-and-64-manual...

"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."

Pentium got Protected Mode Virtual Interrupts to half ass mitigate some of the symptoms, but doesnt fix the problem. https://www.felixcloutier.com/x86/popf:popfd:popfq

"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"

Reply on news.ycombinator.com