7 ms·

Why don't we have a version of Windows without as much legacy support? Like a security hardened (or really just modern-only) version of Windows? I suspect most

Why don't we have a version of Windows without as much legacy support? Like a security hardened (or really just modern-only) version of Windows? I suspect most people would be fine using that version of Windows, and it would have less security problems.

derefr 6y ago
Much of the "point" of Windows as a platform at this point (i.e. the reason that developers stick with targeting Windows APIs, instead of re-developing their software for portability using Java or Qt or Electron or whatever-else) is backward-compatibility. People say that a lot, but it has a very specific meaning when talking about a platform SDK: "backward compatibility" here specifically means that if you wrote version N of your software for version N of Windows, then when you're writing version N+1 of your software targeting version N+1 of Windows, you don't need to re-write any of the old code. You can just start taking advantage of the new Windows API features in the new code you write, while leaving your old code that calls legacy Windows APIs alone. Almost all large Windows applications are written this way: a gradual sedimentary accretion of calls to whatever Windows APIs were modern at the time of writing. Even first-party software like Office still makes calls to kernel-shimmed 16-bit APIs, right alongside calls to the modern UWP APIs. But nevertheless: > Why don't we have a version of Windows without as much legacy support? Like a security hardened (or really just modern-only) version of Windows? We did get this; it was called Windows RT, which could only run software (re)developed specifically for the WinRT platform SDK. WinRT applications are automatically sandboxed; are able to be developed in many languages, including Rust and Javascript; and, while being native code (when you use a compiled language), are also architecture-agnostic—meaning mostly that you can easily build one deliverable for the Windows Store that contains binaries for x86, ARM, and any other arch Windows Store supports, and then by downloading your app people will transparently be downloading whichever sub-package their device needs. But, well, few developers bothered, because most major pieces of software would need to be majorly rewritten to support WinRT. It was mostly used for greenfield projects by existing companies; or as a target for new Windows porting efforts (e.g. of iOS/Android software.) Originally the incentive for using WinRT was supposed to be that only WinRT apps could be sold through the Windows Store; but since so few third-parties bit this bullet, Microsoft backed off and allowed all their biggest bigcorp partners—exactly the people they were really trying to convince—to just submit non-WinRT apps to the store. As of that moment, WinRT-the-SDK was dead in the water; basically no large project has been rewritten for it since then.
- mulmen 6y ago
  I was poking around in the task manager of my Win10 box the other day. I saw a process called ModernSomethingSomething.exe. I don't remember the name exactly. The "Modern" part stood out to me and I wondered what decade it was from.
- asveikau 6y ago
  > Even first-party software like Office still makes calls to kernel-shimmed 16-bit APIs, right alongside calls to the modern UWP APIs. This is a bit of a misleading statement, because Win16 and Win95 had a different kernel interface than exists today: namely kernel.dll, then kernel32.dll -- those all used to be very simple traps into kernel mode. Then NT-based Windows made those and others into user-mode wrappers for the "real" syscall interface living in ntdll.dll. To prevent people from writing software that wouldn't run on 9x, and to provide flexibility to change ntdll at will, they resisted making ntdll a public, documented API for a very long time. So basically, all Win32 apps today are written against a shim for a legacy kernel interface, any time they open a file, etc. Regarding your description of WinRT.... You are missing that WinRT was not very capable and missing a lot of functionality. There is a bit of a problem with 21st century Microsoft in this regard. They cannot re-create their prior 1990s successes. They don't know how to write app platforms anymore, without deprecating them a short number of years later because oops, they turned out to be inadequate.. So the only way to have a decent Windows app is to write against the stuff that's been working for ~25 years and they haven't managed to break yet. That is the reason you won't see, say, a browser rendering engine not depend on Win32. It's not because they don't have the time or ability to rewrite. (Google Chrome's Windows engineers, I don't know if you noticed this from reading their source tree or looking at their blog posts, but they are damn good.) It's because WinRT is missing stuff and it can't be done. See also: Microsoft's various quests to provide a next-gen app framework. WinForms, WPF, Silverlight... They can't get anything to stick like Win32 did, and many later attempts end up with worse quality and shorter lifetimes than the earlier ones.
  - WorldMaker 6y ago
    WinRT is more capable and has more functionality. The added permissions sandbox and tougher (battery-life focused) app cycles blinded a lot of developers. The biggest problem with the WinRT stack has never been capabilities: it's been migration paths from legacy Win32 brownfields. (Had Microsoft delivered more of WinRT earlier to older versions of Windows such as XP and 7 as stepping stones, and/or had Microsoft delivered more of the XAML Islands-style interop between Win32 HWND world and WinRT CoreWindow world there probably would have been a lot faster adoption and lot less hand wringing from developers.) Under the hood, WinRT isn't even that different from Win32 "best practices": ignoring the sandbox and app lifecycle it's a subtly better version of COM in its own apartment. > That is the reason you won't see, say, a browser rendering engine not depend on Win32. What are you even talking about? IE11's Trident rendering engine fork that became Spartan/EdgeHTML was (and sort of still is in that it will be supported for a while left) entirely WinRT native from Windows 8.1 up until New Edge/Edgmium. Even Chromium is adopting some of the WinRT libraries for rendering on Windows. For instance, by default for many versions of Chromium it uses DirectWrite (when running on Windows 10) for font rendering, and DirectWrite is the font rendering system from WinRT/UWP. > See also: Microsoft's various quests to provide a next-gen app framework. WinForms, WPF, Silverlight... They can't get anything to stick like Win32 did, and many later attempts end up with worse quality and shorter lifetimes than the earlier ones. This also makes less sense than you think it does. WinForms is a simple .NET wrapper around Win32. It's practically the same thing. The way Microsoft sees it, and WPF and Silverlight (which at one point was known as WPF/E for Everywhere) were the Alpha/Beta stages of what became WinRT/UWP. Microsoft remembered (it was originally a design goal of WPF that got cut for time/effort in the Longhorn struggle) they needed to move back to COM or a COM-like space from focusing on the .NET VM space only, because they do have a lot of brownfield C/C++ and other language applications such as Office. (Here again, pretty much the history of both the reasons behind WinRT and its successes/failures are all about the brownfields of development.)
bepvte 6y ago
Windows has moved several legacy features to the "Add and remove windows features" menu, but not nearly enough
toast0 6y ago
Who would buy a version of Windows that doesn't run the Windows back catalog? If you don't want to run programs, you could get a Chromebook.
Lammy 6y ago
WindowsRT?
robotnikman 6y ago
From what I've seen so far, Windows 10X is heading in this direction. For business uses though, that backwards compatibility is absolutely key. From my work in IT I've seen countless applications originally developed for much older versions of windows, where the developer is no longer releasing updates or has even gone out of business altogether. Yet some important part of the business still runs on that software for some reason, so it needs to work. This is where backwards compatibility in Windows is a huge strength. The average home user probably can do without such legacy features (other than maybe playing old games which may rely on them), but for businesses its pretty important
notriddle 6y ago
Because supporting the "long tail" is basically Microsoft Windows's entire selling point. Everything works with Windows. I can run Linux software on Windows. I can run run greenfield web applications on Windows (the new Edge is being built for this purpose, but even Chrome for Windows was satisfactory, as long as it's easy to install). I can run old web applications on Windows. I can run old win32 applications on Windows, even stuff using emulated 16-bit APIs. About the only thing you can't run on Windows is XCode. I wonder how big of a bribe Microsoft has tried to propose to Apple to get XCode for Windows, because developing iPhone applications is an enormous gap in Microsoft's moat. The locked-down RT tablets were a horrible blot on an otherwise great brand. "Everything works with Windows" is a terrific selling point.
- WorldMaker 6y ago
  > About the only thing you can't run on Windows is XCode. I wonder how big of a bribe Microsoft has tried to propose to Apple to get XCode for Windows, because developing iPhone applications is an enormous gap in Microsoft's moat. Because this is a fun tangent, it's part of the reason Azure DevOps has one of the largest collections of macOS machines in any cloud, and I'm sure it is mostly used for building iOS apps. The number of tools Microsoft has built or acquihired to Develop/CI/CD iOS apps is quite high counting the various versions of App Center (and its predecessor HockeyApp), Xamarin, etc.
dsl 6y ago
> Why don't we have a version of Windows without as much legacy support? Microsoft makes a ton of money selling the exact opposite. There is an edition of Windows called "POSReady" that is used in Point of Sale, ATMs, and other embedded devices. Microsoft guarentees drivers won't change, no patches will be issued, and almost all security controls are disabled. If you build on top of it, the underlying OS will never change.
Rusky 6y ago
That was/is the whole idea behind WindowsRT, Windows 10S, and Windows 10X, which go all-in on UWP/MSIX/whatever which are sandboxed and heavily restrict access to older APIs. So we have plenty of versions of Windows like that, but they are not doing very well in market share so far. It turns out it's hard to get everything people want to keep working on such a version.
- WorldMaker 6y ago
  > which go all-in on UWP/MSIX/whatever which are sandboxed and heavily restrict access to older APIs. Not all MSIX/Store installs are sandboxed [0] these days (and that's been the case for multiple versions of Windows 10 now). You can ship any Win32 application in an MSIX today, and even put them on the Store. The Store reflects that they have much more unrestricted permissions than a sandboxed application. (Example applications in the Store include iTunes and Photoshop.) 10S still supports any Win32 application willing to package an MSIX and upload it to the Store. 10X is expected (there haven't been a lot of direct details, there may be more next week in the virtual BUILD conference) to support all the same Win32 applications, with just a slight further indirection of moving Win32 space into a lightweight VM similar to (but not entirely related to) the modern (32-bit only) Win32 emulation system in recent versions of Windows 10 on ARM (or similar to in a different way the sort of lightweight VM that WSL2 uses to boot up the Linux kernel). [0] Technically, parts of them are still virtualized to make install/uninstall cleaner, but that level of virtualization has been a part of many classic/legacy EXE/MSI installs since Windows Vista. You can argue the semantics of whether or not that is still sandboxing, but it is definitely far removed from UWP-native modern permissions-oriented sandboxes.

derefr 6y ago

Much of the "point" of Windows as a platform at this point (i.e. the reason that developers stick with targeting Windows APIs, instead of re-developing their software for portability using Java or Qt or Electron or whatever-else) is backward-compatibility. People say that a lot, but it has a very specific meaning when talking about a platform SDK: "backward compatibility" here specifically means that if you wrote version N of your software for version N of Windows, then when you're writing version N+1 of your software targeting version N+1 of Windows, you don't need to re-write any of the old code. You can just start taking advantage of the new Windows API features in the new code you write, while leaving your old code that calls legacy Windows APIs alone. Almost all large Windows applications are written this way: a gradual sedimentary accretion of calls to whatever Windows APIs were modern at the time of writing. Even first-party software like Office still makes calls to kernel-shimmed 16-bit APIs, right alongside calls to the modern UWP APIs. But nevertheless: > Why don't we have a version of Windows without as much legacy support? Like a security hardened (or really just modern-only) version of Windows? We did get this; it was called Windows RT, which could only run software (re)developed specifically for the WinRT platform SDK. WinRT applications are automatically sandboxed; are able to be developed in many languages, including Rust and Javascript; and, while being native code (when you use a compiled language), are also architecture-agnostic—meaning mostly that you can easily build one deliverable for the Windows Store that contains binaries for x86, ARM, and any other arch Windows Store supports, and then by downloading your app people will transparently be downloading whichever sub-package their device needs. But, well, few developers bothered, because most major pieces of software would need to be majorly rewritten to support WinRT. It was mostly used for greenfield projects by existing companies; or as a target for new Windows porting efforts (e.g. of iOS/Android software.) Originally the incentive for using WinRT was supposed to be that only WinRT apps could be sold through the Windows Store; but since so few third-parties bit this bullet, Microsoft backed off and allowed all their biggest bigcorp partners—exactly the people they were really trying to convince—to just submit non-WinRT apps to the store. As of that moment, WinRT-the-SDK was dead in the water; basically no large project has been rewritten for it since then.

mulmen 6y ago
I was poking around in the task manager of my Win10 box the other day. I saw a process called ModernSomethingSomething.exe. I don't remember the name exactly. The "Modern" part stood out to me and I wondered what decade it was from.
asveikau 6y ago
> Even first-party software like Office still makes calls to kernel-shimmed 16-bit APIs, right alongside calls to the modern UWP APIs. This is a bit of a misleading statement, because Win16 and Win95 had a different kernel interface than exists today: namely kernel.dll, then kernel32.dll -- those all used to be very simple traps into kernel mode. Then NT-based Windows made those and others into user-mode wrappers for the "real" syscall interface living in ntdll.dll. To prevent people from writing software that wouldn't run on 9x, and to provide flexibility to change ntdll at will, they resisted making ntdll a public, documented API for a very long time. So basically, all Win32 apps today are written against a shim for a legacy kernel interface, any time they open a file, etc. Regarding your description of WinRT.... You are missing that WinRT was not very capable and missing a lot of functionality. There is a bit of a problem with 21st century Microsoft in this regard. They cannot re-create their prior 1990s successes. They don't know how to write app platforms anymore, without deprecating them a short number of years later because oops, they turned out to be inadequate.. So the only way to have a decent Windows app is to write against the stuff that's been working for ~25 years and they haven't managed to break yet. That is the reason you won't see, say, a browser rendering engine not depend on Win32. It's not because they don't have the time or ability to rewrite. (Google Chrome's Windows engineers, I don't know if you noticed this from reading their source tree or looking at their blog posts, but they are damn good.) It's because WinRT is missing stuff and it can't be done. See also: Microsoft's various quests to provide a next-gen app framework. WinForms, WPF, Silverlight... They can't get anything to stick like Win32 did, and many later attempts end up with worse quality and shorter lifetimes than the earlier ones.
- WorldMaker 6y ago
  WinRT is more capable and has more functionality. The added permissions sandbox and tougher (battery-life focused) app cycles blinded a lot of developers. The biggest problem with the WinRT stack has never been capabilities: it's been migration paths from legacy Win32 brownfields. (Had Microsoft delivered more of WinRT earlier to older versions of Windows such as XP and 7 as stepping stones, and/or had Microsoft delivered more of the XAML Islands-style interop between Win32 HWND world and WinRT CoreWindow world there probably would have been a lot faster adoption and lot less hand wringing from developers.) Under the hood, WinRT isn't even that different from Win32 "best practices": ignoring the sandbox and app lifecycle it's a subtly better version of COM in its own apartment. > That is the reason you won't see, say, a browser rendering engine not depend on Win32. What are you even talking about? IE11's Trident rendering engine fork that became Spartan/EdgeHTML was (and sort of still is in that it will be supported for a while left) entirely WinRT native from Windows 8.1 up until New Edge/Edgmium. Even Chromium is adopting some of the WinRT libraries for rendering on Windows. For instance, by default for many versions of Chromium it uses DirectWrite (when running on Windows 10) for font rendering, and DirectWrite is the font rendering system from WinRT/UWP. > See also: Microsoft's various quests to provide a next-gen app framework. WinForms, WPF, Silverlight... They can't get anything to stick like Win32 did, and many later attempts end up with worse quality and shorter lifetimes than the earlier ones. This also makes less sense than you think it does. WinForms is a simple .NET wrapper around Win32. It's practically the same thing. The way Microsoft sees it, and WPF and Silverlight (which at one point was known as WPF/E for Everywhere) were the Alpha/Beta stages of what became WinRT/UWP. Microsoft remembered (it was originally a design goal of WPF that got cut for time/effort in the Longhorn struggle) they needed to move back to COM or a COM-like space from focusing on the .NET VM space only, because they do have a lot of brownfield C/C++ and other language applications such as Office. (Here again, pretty much the history of both the reasons behind WinRT and its successes/failures are all about the brownfields of development.)

bepvte 6y ago

Windows has moved several legacy features to the "Add and remove windows features" menu, but not nearly enough

toast0 6y ago

Who would buy a version of Windows that doesn't run the Windows back catalog? If you don't want to run programs, you could get a Chromebook.

Lammy 6y ago

WindowsRT?

robotnikman 6y ago

From what I've seen so far, Windows 10X is heading in this direction. For business uses though, that backwards compatibility is absolutely key. From my work in IT I've seen countless applications originally developed for much older versions of windows, where the developer is no longer releasing updates or has even gone out of business altogether. Yet some important part of the business still runs on that software for some reason, so it needs to work. This is where backwards compatibility in Windows is a huge strength. The average home user probably can do without such legacy features (other than maybe playing old games which may rely on them), but for businesses its pretty important

notriddle 6y ago

Because supporting the "long tail" is basically Microsoft Windows's entire selling point. Everything works with Windows. I can run Linux software on Windows. I can run run greenfield web applications on Windows (the new Edge is being built for this purpose, but even Chrome for Windows was satisfactory, as long as it's easy to install). I can run old web applications on Windows. I can run old win32 applications on Windows, even stuff using emulated 16-bit APIs. About the only thing you can't run on Windows is XCode. I wonder how big of a bribe Microsoft has tried to propose to Apple to get XCode for Windows, because developing iPhone applications is an enormous gap in Microsoft's moat. The locked-down RT tablets were a horrible blot on an otherwise great brand. "Everything works with Windows" is a terrific selling point.

WorldMaker 6y ago
> About the only thing you can't run on Windows is XCode. I wonder how big of a bribe Microsoft has tried to propose to Apple to get XCode for Windows, because developing iPhone applications is an enormous gap in Microsoft's moat. Because this is a fun tangent, it's part of the reason Azure DevOps has one of the largest collections of macOS machines in any cloud, and I'm sure it is mostly used for building iOS apps. The number of tools Microsoft has built or acquihired to Develop/CI/CD iOS apps is quite high counting the various versions of App Center (and its predecessor HockeyApp), Xamarin, etc.

dsl 6y ago

> Why don't we have a version of Windows without as much legacy support? Microsoft makes a ton of money selling the exact opposite. There is an edition of Windows called "POSReady" that is used in Point of Sale, ATMs, and other embedded devices. Microsoft guarentees drivers won't change, no patches will be issued, and almost all security controls are disabled. If you build on top of it, the underlying OS will never change.

Rusky 6y ago

That was/is the whole idea behind WindowsRT, Windows 10S, and Windows 10X, which go all-in on UWP/MSIX/whatever which are sandboxed and heavily restrict access to older APIs. So we have plenty of versions of Windows like that, but they are not doing very well in market share so far. It turns out it's hard to get everything people want to keep working on such a version.

WorldMaker 6y ago
> which go all-in on UWP/MSIX/whatever which are sandboxed and heavily restrict access to older APIs. Not all MSIX/Store installs are sandboxed [0] these days (and that's been the case for multiple versions of Windows 10 now). You can ship any Win32 application in an MSIX today, and even put them on the Store. The Store reflects that they have much more unrestricted permissions than a sandboxed application. (Example applications in the Store include iTunes and Photoshop.) 10S still supports any Win32 application willing to package an MSIX and upload it to the Store. 10X is expected (there haven't been a lot of direct details, there may be more next week in the virtual BUILD conference) to support all the same Win32 applications, with just a slight further indirection of moving Win32 space into a lightweight VM similar to (but not entirely related to) the modern (32-bit only) Win32 emulation system in recent versions of Windows 10 on ARM (or similar to in a different way the sort of lightweight VM that WSL2 uses to boot up the Linux kernel). [0] Technically, parts of them are still virtualized to make install/uninstall cleaner, but that level of virtualization has been a part of many classic/legacy EXE/MSI installs since Windows Vista. You can argue the semantics of whether or not that is still sandboxing, but it is definitely far removed from UWP-native modern permissions-oriented sandboxes.