[dragontamer]

IIRC, the big one was Serial-ports and Parallel-ports (which were commonly used for all sorts of custom equipment, especially in the medical field).

IIRC, user-mode programs of WinXP (and earlier, including Win2k) were able to directly access these hardware ports. Which meant that WinXP / Win2k had far better latency, leading to obscure hardware bugs to anyone who upgraded from XP -> Vista (or later). Even if you rewrote the program to use Win Vista+ style COM ports, it wasn't good enough.

So a lot of people stayed back on WinXP / Win NT.

---------

16-bit programs were DOS / segmented mode. Win95 remained compatible. IIRC, Win2k forced you into 32-bit flat-mode programs, which had some security benefits.

But these 32-bit "flat mode" security benefits were not enough, and were still a far cry from the expectations of the modern computer user.

[danachow]

You are not remembering correctly. No flavor of Windows NT (this includes 2000 and XP) gave direct hardware access out of the box.

There were a couple of undocumented but well known NT kernel functions to manipulate the task IO permission level (eg Ke386SetIoAccessMap) and there was a commonly used hack/gaping security hole to manipulate these with a 3rd party driver that was built to do nothing except that (probably the most commonly shared one went by the name of GIVEIO.SYS - first presented in Dr Dobbs Journal in the 90s). This would work similarly on Vista and 7 as it would on the older OSes.

Win2k didn’t so much as force you into flat mode as it was a completely different kernel architecture from Windows 98/95 - the “security benefits” include the myriad other ways that NT is an actual multiuser OS vs 98/95 being a glorified DOS extender. The Windows 11 kernel is an NT descendant through 2000/XP and the preceding NT 4/3 releases preceding those.

* The above mentioned driver has even been updated by internets for 64-but Windows https://www-user.tu-chemnitz.de/~heha/hsn/giveio64.zip/readm...

[rep_lodsb]

As long as the hardware isn't DMA-capable or has to be shared, allowing programs direct access isn't a security violation. Since everything runs in protected mode, the kernel is still "in charge", and can limit what I/O should go directly to the hardware. This is supported by the processor, which has a per-task bitmap of allowed I/O ports.

Virtualization was introduced on IBM mainframes in the 1970s, and in a somewhat more limited version has been present in 32-bit x86 operating systems (even Windows 3.x could run several virtual DOS machines at the same time).

Every 32-bit version of Windows still supports running 16-bit programs. Microsoft could have continued supporting 16-bit protected mode even on 64-bit, or even used the newer virtualization features (in place of V86 mode) to run real mode code, but choose not to.

As for the expectations of modern computer users, those that don't know how any of this stuff works probably believe that everything has to get slower, more restrictive, and less backward compatible in the name of Security :(

[dragontamer]

> As long as the hardware isn't DMA-capable or has to be shared

We're talking about Parallel-Ports here, aka "The Printer Port". Any printer program written "old-school" would have tried to send data to LPT-1, except you have an X-Ray machine sitting there confused at these messages its getting.

The proper technique of printing, is not to directly contact the LPT-1 port and shove data into it... its to talk to Windows's printer spool and interact indirectly.

The user then configures the LPT-1 port: is it to be managed by the printer spool? Or should LPT-1 port be divvyed out to a particular program and reserved through another manner?

---------

There's absolutely a security concern about random programs sending messages to the hardware. Maybe the OS doesn't have a security issue, but those medical devices could have commands (such as rewriting firmware) sitting on those ports.

You'd want to make sure that only approved programs directly interacted with those kinds of hardware devices... with the protocols that are appropriately specified by the user.