[wilhil]

Up until a few years ago I had to support a .Net 2 app for a global company.

I had a few Windows 2000 VMs and they were a joy to use.

Started in seconds - I could have LOADS of snapshots that would only take up a handful of MBs and generally speaking, it was excellent.

Only reason I stopped was because I no longer needed to run that project.

I'm not stuck in the past - I get why things get slower and are more complex... but, sometimes I do wish we could go backwards a little!

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