[dragontamer]

Pre-Vista Windows is simply insufficient from a security perspective compared to modern post-Vista Windows.

All XP-and-older versions of Windows allowed any program to access the hardware directly. Back then, a Win2000 program would need to access the "in" and "out" hardware instructions to talk with gamepads because... well... gamepads were read to directly through hardware instructions.

Don't look at me like that! USB wasn't really that common yet, and there were all sorts of weird specific hardware differences in controllers still. It was a different world. Gamepads were glorified potentiometers (https://en.wikipedia.org/wiki/Potentiometer) and game-ports were just ADC converters controlled by Windows. And assembly language knowledge was much more common too!

----------

Letting modern software touch the hardware directly like that is a security nightmare. Vista+ forced everyone to write signed device drivers and hide that direct-hardware access behind a layer of APIs (the Windows Driver API).

Today, if your video games touch hardware directly, you at least know about it... and the practice is discouraged (though still widely used for DRM and other such "features").

-------------

In any case, "stripped down" Windows 10 IoT core builds and runs on the Raspberry Pi.

[rep_lodsb]

Are you sure? I don't think any NT kernel allowed userspace code to directly access I/O ports. The earliest versions didn't even let graphics drivers do that, but that was changed (in either 3.51 or 4.0?) for performance reasons.

For compatibility with DOS and 16-bit Windows versions, the kernel may emulate I/O access, similar to modern virtual machines. For simple devices, that layer of emulation may be very thin (with some accesses going directly to the hardware), but that isn't a security problem. A simple polled ADC can't do any harm to the system, at worst you get garbage if multiple programs were to use it at the same time.

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

[danachow]

You are correct, the NT kernel did not allow direct IO access from user space - but there was a commonly used trick of using a small driver (the original one named giveio.sys) that manipulated the IOPL of the TSS through some undocumented kernel functions.