[pjscott]

I love how, on those OSes, you could freeze the whole thing solid with a three-byte program:

   cli   # clears interrupts
   loop: goto loop

This ballooned to a colossal four bytes if you put it in an EXE file, of course.

[mahmud]

You could do it from debug.com but that one doesn't have labels, so you will need to use an explicit jmp.

  C:\hack\lisp\cl-gdata\base>debug
  -a
  13EA:0100 cli
  13EA:0101 jmp 101
  13EA:0103
  -g 0100

[yesimahuman]

Technically speaking, how would an OS avoid that issue, without breaking compatibility (unless that is acceptable)?

[mahmud]

You can't be bug compatible for things that violate the processor's protection protocol. Access to certain bits of the EFLAGS register is unavailable to unprivileged code. In fact. Just because you were allowed to raid and pillage by Microsoft for a few years doesn't mean it's the norm.

[derefr]

Sure you can—just let them stomp all over a virtualized processor/memory space.

[dfox]

You cannot meaningfully virtualize access to EFLAGS:IF. You can either emulate(/JIT) almost whole CPU or ignore this issue. And anyway, turning of interrupts is something that essentially does not make sense for user process, so it is better to just disallow that (which is what almost everything else but non-NT windows does)

[JoeAltmaier]

It was usually used as an ultra- critical section. It would have been fine to simulate it as a scheduler-freeze for that process, preserving the meaning without getting hung up on the hardware implementation.

But instead, Intel decided to try to support actually messing with the interrupt enable state, resulting in years of highly-inefficient "solutions" e.g. trapping and simulating. Sigh.

[mfukar]

What's the (efficient) alternative?

[JoeAltmaier]

Any OS on that early hardware had this problem, right?