undefined

points

[-]

It wasn't really the processor architecture. Segmented addressing was actually fairly easy if the processor was used only in the way that protected mode was envisioned as working. As the headlined article observes, a lot of this stuff simply wasn't necessary in OS/2 1.x, even though that too had DLLs, callback window procedures, and the multiple tiny/small/medium/large/compact/huge memory models.

The differences were (a) that DOS+Windows was designed so that the same programs could run in both real mode, with overlaying, and 286 protected mode, with segmented virtual memory; and (b) that to really save on RAM DOS+Windows had ideas such as the data segments for DLLs being globally shared across all processes. These added all of the complications mentioned in the headlined article and more besides. It was the operating system, not the processor architecture.

by kalleboo5 hours ago|

parent|

[-]

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

by canucker20161 hours ago|

parent|

[-]

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.

by JdeBP5 hours ago|

parent|

prev|

[-]

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.

by skissane3 hours ago|

parent|

[-]

> 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+)