5 ms·

This got me thinking, why are installers still necessary on Windows? Why have they never adopted a packaged solution similar to .app on macOS?

horsawlarway 4y ago
Microsoft store applications are conceptually similar to the dmg/app approach macOS has taken (and have most of the same limitations and restrictions). A few design decisions from the early Windows days tend to keep installers around on windows, though. Windows uses a single shared registry for persistent application settings (instead of something like a plist/config file local to the application) which has some clear upsides because settings are centralized and can be deployed fairly easily by admins and applications can read settings for other applications and change behavior accordingly - But... it also means applications need a step to configure those settings at install time. Additionally - Windows is a MUCH more diverse ecosystem than macOS in terms of hardware (and the associated software). Installers give applications a chance to ensure all required dependencies are correctly in place. Finally - There's a lot of work and tooling for enterprise customers in Microsoft's MSI toolchain. Not the least of which - they can allow enterprise customers to verify the exact state changes on the end machine that will occur as a result of installation, and to do updates as patches rather than complete replacements, making them much faster and less network intensive (matters when you're deploying a patch to something like say Visual Studio, which is 40+GB on disk on the small end). Basically - Installation is a lot more complicated with a wide variety of business use-cases, much less hardware control, and a strong legacy of supporting old software.
- WorldMaker 4y ago
  > Windows uses a single shared registry for persistent application settings (instead of something like a plist/config file local to the application) The NT Registry was intended for Kernel settings only. Persisting application settings to it was a bug that didn't get squashed early enough, in part because Windows 95 copied the idea without understanding the design/architecture/reasoning behind it. It is a bug that will live on "forever" for backwards compatibility.
  - hyperman1 4y ago
    That's not as I understood it. It appeared in windows 3.1 (or before?). There, it listed what COM components were available and how to start them. These components were meant to be available for all applications, so e.g. embedding 1 component like a spreadsheet in any other OLE application like avword processor could work, even for applications never meant to be connected together. So it was at first meant as some meeting center, where anyone could drop anything for anyone else. Meanwhile, the .ini files became a bit long in the tooth, so NT and 95 both adopted it as a config store. When you use a meeting center for personal config, it makes sense that other passerby's would notice and start to mess with your config. This was both a blessing and a curse: It allowed all kinds of deep integration, but also injects all kinds of other peoples bugs in your code.
    - WorldMaker 4y ago
      My understanding: OLE 1.0 in the Windows 3.x era (which was a predecessor to COM, but not yet COM, and an evolutionary baby step between DDE [passing data through Windows messages] and COM) did not use "the" Registry but more complex DLL VTABLEs and INI files. Meanwhile the NT Registry was built for the NT Kernel settings store, and primarily just the NT Kernel. But COM did think to use the Registry as a central store of COM component registration. In part because the Kernel may need to call COM components sometimes. Largely because COM relied on it, the NT Registry was then backported (sideported?) to Windows 95. So yes, I agree with you that my understanding is that COM is largely to blame for the inflation of the NT Registry from "just a Kernel data store" to something larger. But my understanding is that while COM still needed a central registry, the Registry was never intended to replace INI files. That was a combination of accidents/mistakes by general developers at the time: 1. The Windows 1.x to 3.x INI reading/writing functions developed for a single user operating system had an unfortunate default to reading/writing files out of the current working directory which in Windows 3.x was still often C:\WINDOWS (but sometimes the application's install directory) 2. Windows 95 (correctly) added permissions restrictions to C:\Windows and C:\Program Files and asked developers to start using User folders instead (such as %LocalAppData% and %Documents%) 3. The INI APIs stopped working by default because they still defaulted to C:\WINDOWS or application folders for backward compatibility with Win16 apps. 4. Developers misunderstood this to mean that INI files were dead (because of those bad defaults causing the APIs to "glitch"/not work as expected/not work at all in Win32 apps) 5. Developers saw COM registrations going to the Registry and thought that was the replacement for INI files (in part because OLE 1.0 had used INI files in that registration way) 6. Because the Windows 95 Registry was already a weird port/fork of the NT Registry there weren't enough eyeballs on it from the NT Kernel team to try to push the brakes hard enough against the accidents/mistakes above Certainly the cat is more than out of the bag this many decades later. But the moral of the story is that the Registry as used for application configuration (as opposed to mostly Kernel configuration) is an unhappy accident. Unhappy for the NT Kernel team that tried to optimize the Registry for Kernel operations only to see it flooded by application developers. Unhappy for application developers because it made install/uninstall more complex, baroque, and ugly than it ever needed to be in Windows 95+. Unhappy for users in how messy the Registry can get (when not sandboxed) and how easy to accidentally corrupt it can be when trying to "clean" it.
kazinator 4y ago
Why is ad hoc stuff like "Homebrew" still necessary on MacOS? Why hasn't MacOS adopted something official like .MSI files on Windows?
- DANK_YACHT 4y ago
  Homebrew is a package manager. Windows has its own package manager: https://docs.microsoft.com/en-us/windows/package-manager/ https://docs.microsoft.com/en-us/windows/package-manager/ I guess MSI isn't a panacea after all. Here is a not so savory story on how winget came to be: https://keivan.io/the-day-appget-died/ https://keivan.io/the-day-appget-died/
gwbas1c 4y ago
Even the .app system has issues: - The whole dmg file where you have to drag the app to your applications folder is quite confusing compared to the app store experience. - Ever try to uninstall a Mac app? Merely deleting the .app file still leaves behind everything else. The everything else can be very large files in your ~/Library folder. It's not always straightforward where those files are, and how to find them. (Think of a virtual disk drive product like Google Drive, Dropbox, Onedrive, ect, where the backing storage is usually hidden.) - Some products legitimately need to install things, like Finder extensions or drivers.
WorldMaker 4y ago
MSIX (formerly APPX) packages exist on Windows and have had a "double click to install" experience since Windows 10 Anniversary Edition. They've supported Win32 apps for as long as they've been called MSIX rather than APPX.

horsawlarway 4y ago

Microsoft store applications are conceptually similar to the dmg/app approach macOS has taken (and have most of the same limitations and restrictions). A few design decisions from the early Windows days tend to keep installers around on windows, though. Windows uses a single shared registry for persistent application settings (instead of something like a plist/config file local to the application) which has some clear upsides because settings are centralized and can be deployed fairly easily by admins and applications can read settings for other applications and change behavior accordingly - But... it also means applications need a step to configure those settings at install time. Additionally - Windows is a MUCH more diverse ecosystem than macOS in terms of hardware (and the associated software). Installers give applications a chance to ensure all required dependencies are correctly in place. Finally - There's a lot of work and tooling for enterprise customers in Microsoft's MSI toolchain. Not the least of which - they can allow enterprise customers to verify the exact state changes on the end machine that will occur as a result of installation, and to do updates as patches rather than complete replacements, making them much faster and less network intensive (matters when you're deploying a patch to something like say Visual Studio, which is 40+GB on disk on the small end). Basically - Installation is a lot more complicated with a wide variety of business use-cases, much less hardware control, and a strong legacy of supporting old software.

WorldMaker 4y ago
> Windows uses a single shared registry for persistent application settings (instead of something like a plist/config file local to the application) The NT Registry was intended for Kernel settings only. Persisting application settings to it was a bug that didn't get squashed early enough, in part because Windows 95 copied the idea without understanding the design/architecture/reasoning behind it. It is a bug that will live on "forever" for backwards compatibility.
- hyperman1 4y ago
  That's not as I understood it. It appeared in windows 3.1 (or before?). There, it listed what COM components were available and how to start them. These components were meant to be available for all applications, so e.g. embedding 1 component like a spreadsheet in any other OLE application like avword processor could work, even for applications never meant to be connected together. So it was at first meant as some meeting center, where anyone could drop anything for anyone else. Meanwhile, the .ini files became a bit long in the tooth, so NT and 95 both adopted it as a config store. When you use a meeting center for personal config, it makes sense that other passerby's would notice and start to mess with your config. This was both a blessing and a curse: It allowed all kinds of deep integration, but also injects all kinds of other peoples bugs in your code.
  - WorldMaker 4y ago
    My understanding: OLE 1.0 in the Windows 3.x era (which was a predecessor to COM, but not yet COM, and an evolutionary baby step between DDE [passing data through Windows messages] and COM) did not use "the" Registry but more complex DLL VTABLEs and INI files. Meanwhile the NT Registry was built for the NT Kernel settings store, and primarily just the NT Kernel. But COM did think to use the Registry as a central store of COM component registration. In part because the Kernel may need to call COM components sometimes. Largely because COM relied on it, the NT Registry was then backported (sideported?) to Windows 95. So yes, I agree with you that my understanding is that COM is largely to blame for the inflation of the NT Registry from "just a Kernel data store" to something larger. But my understanding is that while COM still needed a central registry, the Registry was never intended to replace INI files. That was a combination of accidents/mistakes by general developers at the time: 1. The Windows 1.x to 3.x INI reading/writing functions developed for a single user operating system had an unfortunate default to reading/writing files out of the current working directory which in Windows 3.x was still often C:\WINDOWS (but sometimes the application's install directory) 2. Windows 95 (correctly) added permissions restrictions to C:\Windows and C:\Program Files and asked developers to start using User folders instead (such as %LocalAppData% and %Documents%) 3. The INI APIs stopped working by default because they still defaulted to C:\WINDOWS or application folders for backward compatibility with Win16 apps. 4. Developers misunderstood this to mean that INI files were dead (because of those bad defaults causing the APIs to "glitch"/not work as expected/not work at all in Win32 apps) 5. Developers saw COM registrations going to the Registry and thought that was the replacement for INI files (in part because OLE 1.0 had used INI files in that registration way) 6. Because the Windows 95 Registry was already a weird port/fork of the NT Registry there weren't enough eyeballs on it from the NT Kernel team to try to push the brakes hard enough against the accidents/mistakes above Certainly the cat is more than out of the bag this many decades later. But the moral of the story is that the Registry as used for application configuration (as opposed to mostly Kernel configuration) is an unhappy accident. Unhappy for the NT Kernel team that tried to optimize the Registry for Kernel operations only to see it flooded by application developers. Unhappy for application developers because it made install/uninstall more complex, baroque, and ugly than it ever needed to be in Windows 95+. Unhappy for users in how messy the Registry can get (when not sandboxed) and how easy to accidentally corrupt it can be when trying to "clean" it.

kazinator 4y ago

Why is ad hoc stuff like "Homebrew" still necessary on MacOS? Why hasn't MacOS adopted something official like .MSI files on Windows?

DANK_YACHT 4y ago
Homebrew is a package manager. Windows has its own package manager: https://docs.microsoft.com/en-us/windows/package-manager/ https://docs.microsoft.com/en-us/windows/package-manager/ I guess MSI isn't a panacea after all. Here is a not so savory story on how winget came to be: https://keivan.io/the-day-appget-died/ https://keivan.io/the-day-appget-died/

gwbas1c 4y ago

Even the .app system has issues: - The whole dmg file where you have to drag the app to your applications folder is quite confusing compared to the app store experience. - Ever try to uninstall a Mac app? Merely deleting the .app file still leaves behind everything else. The everything else can be very large files in your ~/Library folder. It's not always straightforward where those files are, and how to find them. (Think of a virtual disk drive product like Google Drive, Dropbox, Onedrive, ect, where the backing storage is usually hidden.) - Some products legitimately need to install things, like Finder extensions or drivers.

WorldMaker 4y ago

MSIX (formerly APPX) packages exist on Windows and have had a "double click to install" experience since Windows 10 Anniversary Edition. They've supported Win32 apps for as long as they've been called MSIX rather than APPX.