3 ms·

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 c

by wilhil 5y ago

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 5y ago
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 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 5y ago
  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 5y ago
    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.
    - rep_lodsb 5y ago
      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 5y ago
        > 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.

by wilhil 5y ago

dragontamer 5y ago

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 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 5y ago
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 5y ago
  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.
  - rep_lodsb 5y ago
    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 5y ago
      > 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.