3 ms·

It is a great achievement. But the question is: Is it really relevant? Couldn't they move the compatibility for larger parts to a VM or other independent Subsys

It is a great achievement. But the question is: Is it really relevant? Couldn't they move the compatibility for larger parts to a VM or other independent Subsystem? Of course even that isn't trivial, as one wants to share filesystem access (while I can imagine some overlay limiting access), might need COM and access to devices ... but I would assume they could push that a lot more actively. If they decided which GUI framework to focus on.

486sx33 2y ago
I think that VM software like Parallels has shown us that we are just now at the point where VMs can handle it all and feel native. Certainly NT could use a re write to eliminate all the legacy stuff…but instead they focus on copilot and nagging me not to leave windows edge internet explorer
wvenable 2y ago
> Couldn't they move the compatibility for larger parts to a VM or other independent Subsystem? A huge amount of the compatibility stuff is already moved out into separate code that isn't loaded unless needed. The problem too, though, is users don't want independent subsystems -- they want their OS to operate as a singular environment. Raymond Chen has mentioned this a few times on his blog when this sort of thing comes up. Backwards compatibility also really isn't the issue that people seem to think it is.
- dredmorbius 2y ago
  Independent subsystems need not be independent subsystems that the user must manage manually. The k8s / containers world on Linux ... approaches ... this. Right now that's still somewhat manual, but the idea that a given application might fire off with the environment it needs without layering the rest of the system with those compatibility requirements, and also, incidentally, sandboxing those apps from the rest of the system (specific interactions excepted) would permit both forward advance and backwards compatibility. A friend working at a virtualisation start-up back in the aughts told of one of the founders who'd worked for the guy who'd created BCPL, the programming language which preceded B, and later C. Turns out that when automotive engineers were starting to look into automated automobile controls, in the 1970s, C was considered too heavy-weight, and the systems were imploemented in BCPL. Some forty years later, the systems were still running, in BCPL, over multiple levels of emulation (at least two, possibly more, as I heard it). And, of course, faster than in the original bare-metal implementations. Emulation/virtualisation is actually a pretty good compatibility solution.
  - wvenable 2y ago
    Users don't want sandboxing! It's frustrating enough on iOS and Android. They want to be able to cut and paste, have all their files in one place, open files in multiple applications at the same time, have plugins, etc. Having compatibility requirements is almost the definition of an operating system. If you bundle every application with basically the entire OS needed to run them then what exactly have you created?
    - dredmorbius 2y ago
      There are a relatively limited set of high-value target platforms: MS DOS (still in some use), Win95, WinNT and successor versions. Perhaps additionally a few Linux or BSD variants. Note that it's possible to share some of that infrastructure by various mechanisms (e.g., union mounts, presumably read-only), so that even where you want apps sandboxed from one another, they can share OS-level resources (kernel, drivers, libraries). At a user level, sandboxing presumes some shared file space, as in "My Files", or shared download, or other spaces. Drag-and-drop through the GUI itself would tend to be independent of file-based access, I'd hope.
      - wvenable 2y ago
        What is gained by this? What would you get by virtualizing a WinAPI environment for app in Windows? (MS DOS compatibility is already gone from Windows). You get a whole bunch of indirection and solve a problem that doesn't exist.
        dredmorbius 2y ago
        Obvious obvious advantage is obviously obvious: the ability to run software which is either obsolete, incompatible with your present system, or simply not trusted. In my own case, I'd find benefits to spinning up, say, qemu running FreeDOS, WinNT, or various Unixen. Total overhead is low, and I get access to ancient software or data formats. Most offer shared data access through drive mapping, networking, Samba shares, etc. That's not what I'd suggested above as an integrated solution, but could easily become part of the foundation for something along those lines. Again, Kubernetes or other jail-based solutions would work where you need a different flavour that's compatible with your host OS kernel. Where different kernels or host architectures are needed, you'll want more comprehensive virtualisation.
nitwit005 2y ago
Generally speaking, the waste is only hard disk space. If no one ever loads some old DLL, it just sits there.
- johannes1234321 2y ago
  Nobody loads it, but the attacker. Either via a specially crafted program or via some COM service invoked from a Word document or something.
jimbokun 2y ago
By moving the Win32 API onto Windows NT kernel, isn't that essentially what Microsoft did?

486sx33 2y ago

I think that VM software like Parallels has shown us that we are just now at the point where VMs can handle it all and feel native. Certainly NT could use a re write to eliminate all the legacy stuff…but instead they focus on copilot and nagging me not to leave windows edge internet explorer

wvenable 2y ago

> Couldn't they move the compatibility for larger parts to a VM or other independent Subsystem? A huge amount of the compatibility stuff is already moved out into separate code that isn't loaded unless needed. The problem too, though, is users don't want independent subsystems -- they want their OS to operate as a singular environment. Raymond Chen has mentioned this a few times on his blog when this sort of thing comes up. Backwards compatibility also really isn't the issue that people seem to think it is.

dredmorbius 2y ago
Independent subsystems need not be independent subsystems that the user must manage manually. The k8s / containers world on Linux ... approaches ... this. Right now that's still somewhat manual, but the idea that a given application might fire off with the environment it needs without layering the rest of the system with those compatibility requirements, and also, incidentally, sandboxing those apps from the rest of the system (specific interactions excepted) would permit both forward advance and backwards compatibility. A friend working at a virtualisation start-up back in the aughts told of one of the founders who'd worked for the guy who'd created BCPL, the programming language which preceded B, and later C. Turns out that when automotive engineers were starting to look into automated automobile controls, in the 1970s, C was considered too heavy-weight, and the systems were imploemented in BCPL. Some forty years later, the systems were still running, in BCPL, over multiple levels of emulation (at least two, possibly more, as I heard it). And, of course, faster than in the original bare-metal implementations. Emulation/virtualisation is actually a pretty good compatibility solution.
- wvenable 2y ago
  Users don't want sandboxing! It's frustrating enough on iOS and Android. They want to be able to cut and paste, have all their files in one place, open files in multiple applications at the same time, have plugins, etc. Having compatibility requirements is almost the definition of an operating system. If you bundle every application with basically the entire OS needed to run them then what exactly have you created?
  - dredmorbius 2y ago
    There are a relatively limited set of high-value target platforms: MS DOS (still in some use), Win95, WinNT and successor versions. Perhaps additionally a few Linux or BSD variants. Note that it's possible to share some of that infrastructure by various mechanisms (e.g., union mounts, presumably read-only), so that even where you want apps sandboxed from one another, they can share OS-level resources (kernel, drivers, libraries). At a user level, sandboxing presumes some shared file space, as in "My Files", or shared download, or other spaces. Drag-and-drop through the GUI itself would tend to be independent of file-based access, I'd hope.
    - wvenable 2y ago
      What is gained by this? What would you get by virtualizing a WinAPI environment for app in Windows? (MS DOS compatibility is already gone from Windows). You get a whole bunch of indirection and solve a problem that doesn't exist.
      - dredmorbius 2y ago
        Obvious obvious advantage is obviously obvious: the ability to run software which is either obsolete, incompatible with your present system, or simply not trusted. In my own case, I'd find benefits to spinning up, say, qemu running FreeDOS, WinNT, or various Unixen. Total overhead is low, and I get access to ancient software or data formats. Most offer shared data access through drive mapping, networking, Samba shares, etc. That's not what I'd suggested above as an integrated solution, but could easily become part of the foundation for something along those lines. Again, Kubernetes or other jail-based solutions would work where you need a different flavour that's compatible with your host OS kernel. Where different kernels or host architectures are needed, you'll want more comprehensive virtualisation.

nitwit005 2y ago

Generally speaking, the waste is only hard disk space. If no one ever loads some old DLL, it just sits there.

johannes1234321 2y ago
Nobody loads it, but the attacker. Either via a specially crafted program or via some COM service invoked from a Word document or something.

jimbokun 2y ago

By moving the Win32 API onto Windows NT kernel, isn't that essentially what Microsoft did?