[kalleboo]

I understood it as Windows developers had to manually deal with segment limitations since Windows supported running on pre-286 CPUs without protected mode (Wikipedia says Windows 1-3 all supported the 8088). OS/2 just made the 286 a minimum requirement so they could rely on a CPU with more modern features.

The 68k didn't come with an MMU like the 286 so MacOS couldn't rely on virtual memory like OS/2 did but at least the flat memory space meant you didn't have to juggle 64k segments

[canucker2016]

But like real-mode Windows, the Macintosh OS was designed with small amounts of RAM. 32K limits pop up in various APIs. Handle memory allocation.

Not as much of a strait jacket as Windows segmented-memory programming, but compared to Unix, it did feel constricting.

[JdeBP]

Yes, outwith the idea of Family API programs (which couldn't use Presentation Manager and whatnot anyway) OS/2 1.x did target the 286 as a minimum. But that doesn't mean that DOS+Windows didn't use the features.

It did. It was bi-modal. There were at one point switches to the WIN command to tell it whether to come up in real mode or 286 protected mode. In the latter it definitely did use the features of protected mode.

It was the bi-modal nature that was the problem. Essentially, they had to design a whole layer that simulated when in real mode all of the load-on-demand stuff that the processor architecture supplied for free in 286 protected mode, and make it so that the thing would all work either way with no changes to applications.

[skissane]

> There were at one point switches to the WIN command to tell it whether to come up in real mode or 286 protected mode. In the latter it definitely did use the features of protected mode.

Windows 3.0’s WIN.COM supported:

/R for real mode (8086)

/S for standard mode (16-bit protected mode)

/E for 386 Enhanced Mode (32-bit virtual machine manager (VMM), running Windows in VM1, and DOS apps in VM2+)