5 ms·

I have always wondered why Windows never had a unified installation, update, and uninstall framework like MacOS had from the start. It seems like an obvious omi

I have always wondered why Windows never had a unified installation, update, and uninstall framework like MacOS had from the start. It seems like an obvious omission that was never solved. Even now corporate customers need to individually package software themselves to manage applications in their fleet. My guess is that Microsoft encouraged applications to share DLLs from the start, and to provide backwards compatibility Microsoft never enforced MSI or a mature software management framework.

zabzonk 1y ago
The MS software environment is much larger and complex than that of the Mac? So creating tools to manage it is far more difficult?
deleted 1y ago
[deleted]
chongli 1y ago
Mac OS hasn't had that from the start. Sure, many apps are installed simply by drag-and-drop to the Applications folder. However, plenty of apps have installers you need to run which usually request administrator credentials to install support files system-wide. Some of these apps have their own updaters which are set to run at startup. In the past, many apps had extensions and control panels they installed into the System Folder which required a reboot. Finally, many of these same apps had no uninstaller. You had to hunt throughout the system to remove all the stuff they installed, including preference files and cache files just in case you wanted to reinstall without having problems down the road.
- flenserboy 1y ago
  it should have been drag-and-drop only from the start. I'd gladly hop on to a Linux/BSD distro which would be clean & consistent with this.
  - ebiester 1y ago
    What if there are setup questions that need to be answered that change the trajectory of an install? For example, some installs will have features you can opt out of to save space.
    - flenserboy 1y ago
      good question. that would not be an easy problem to work out.
  - soulofmischief 1y ago
    The fact that most Linux distros don't do this is a huge selling point for me. In the early Linux days, software distribution was a nightmare, but today the average popular distro's package management experience is unparalleled. I much prefer using my terminal to manage packages than some unwieldy GUI, and I don't have to leave my terminal to discover new packages or remove old ones.
    - dmonitor 1y ago
      AppImages are still fairly common, though, and those are practically begging for a drag/drop interface
    - flenserboy 1y ago
      fair. but something similar could be done via a terminal-friendly packaging system — one directory, one location for everything application-related. it's not so much the drag-and-drop I'm drawn to as it is the clear location for each application.
    - curt15 1y ago
      In my experience, the main weakness of Linux distros' package management experience is they don't distinguish core system functionality from add-on software. After all, a Linux distro is ultimately just a bag of packages. Every package installs into the global `/usr` directory, and the package manager treats third-party packages and system packages equally. The Windows analogue would be if all software installed themselves into the Windows folder, or if you could uninstall ntoskrnl from Add/Remove programs. This leads to several problems: 1. It's easy to inadvertently break one's system. How often have users accidentally uninstalled their desktop environment due a buggy dependency specification or dependency solver? Shouldn't there be a whitelist of core system packages and files that should never be touched during ordinary package transactions? There was also a Fedora bug maybe 1 year ago where a problem with the Google Chrome RPM's GPG signing key blocked system updates unless one manually overrode the package manager transaction to skip broken packages. Imagine if Chrome could cause Windows updates to fail or if a misconfigured Homebrew package could block MacOS updates. 2. It's easy to accumulate cruft over time because there's no out-of-box tracking of software I've added compared to be the base system. I could manually keep a list in a text file, but what about any dependencies of the packages on that list? What about any config files in `/etc` left behind by packages even after they are uninstalled? I'd like an easy way to revert my system to its out-of-box condition without carefully inspecting every line of `dpkg -l` (of which there could hundreds or thousands). With Homebrew on MacOS I can just blow away `/opt/homebrew`.
- endemic 1y ago
  necessitating such programs as https://freemacsoft.net/appcleaner/ https://freemacsoft.net/appcleaner/ (no affiliation)
ogig 1y ago
Serious software vendors do usually provide msi packages for corporate deployments via GPOs. I don't remember having to package myself anything in the last 10 year or so. Maybe had to read some documentation to tune install parameters. But I agree that it could be so much better.
- dabockster 1y ago
  That, and WinGet really wasn’t a thing until the height of COVID when people really found out that it even existed. There’s still a ton of stuff that doesn’t install quite right in it.
dist-epoch 1y ago
It already does, it's called the Microsoft Store. Apps from there are auto-updated by the system.
- paulryanrogers 1y ago
  Doesn't this include limitations on what the software can do?
  - pacifika 1y ago
    Same as the Mac, limitations are different of course
  - WorldMaker 1y ago
    Not in several years, no. MSIX, since it was renamed that, supports nearly the full gamut of MSI (just specified in XML directly instead of an ancient, deprecated Microsoft JET database file format and modern ZIP instead of the ancient Windows CAB archive format), and classic-style Win32 apps can be installed with no more of a sandbox than is usual from a raw MSI install rather than an MSIX install.
- pjc50 1y ago
  Reading between the lines on this announcment, it sounds like a plan to uncouple the mechanism of msix/appx and Windows packages from the policy of the App Store. WinUI3 (if anyone ever bothers to use it, including Microsoft) already distributes its library dependency this way, as a store package.
  - keyringlight 1y ago
    >(if anyone ever bothers to use it, including Microsoft) I think this is a large part of the problem, within the range of applications MS offers there's range of ways they get distributed, installed and managed. Will office use it? How about visual studio, teams, various windows components? It'd be more 'sit up and listen' interesting if MS committed to using it themselves, showed it works for a range of use cases and was great at doing it.
oldpersonintx2 1y ago
the real innovator here was FreeBSD, even before Linux. In the mid 90s, a FreeBSD user could build their entire operating system and apps with code and tools managed by FreeBSD. Eventually systems like Debian improved on this, but FreeBSD was first.
- worthless-trash 1y ago
  I feel like pretty much every distro I used n thr 90s allowed for ef hosting and building. Even early redhat had the ability to build every package from arc rpm. Unless i am misunderstanding what you mean by build.
barrkel 1y ago
It's an incredibly complex problem, when you take into account drivers, system extensions, shared library versoning and so on, and even harder to solve when you can't rely on the presence of an internet connection. Then, once you've built it out, you need to convince software vendors to use your gatekeeping installation mechanism, and hope they believe the executives won't see this as leverage to extract rents later.
madeofpalk 1y ago
macOS doesn’t really. There’s App Store, with varying degrees of success. And then most other apps use Sparkles framework, a third party library. I am surprised that something like sparkle hasn’t found footing on Windows.
- duskwuff 1y ago
  re. Sparkle - same. Sparkle is practically the platonic ideal of a self-update framework; there's good reason why it's been the uncontested standard on the platform for nearly twenty years (!!).
  - comex 1y ago
    As a user, I hate Sparkle. At least, I hate Sparkle's default mode where you have to click "Install Update", then wait for the update to download, then authenticate, then wait for the update to extract, then wait for the app to relaunch. Too slow. When I open an app, I want to use it, immediately. I'd rather have apps update in the background; barring that, at least give me a button to manually start a background update while I continue to use the older version of the app.
    - mike_hearn 1y ago
      Sparkle does have that for a long time now, but the default does still want you to agree to background updates the first time. Developers can turn that off and make apps update silently in the background (when they're running).
rimunroe 1y ago
> I have always wondered why Windows never had a unified installation, update, and uninstall framework like MacOS had from the start. It seems like an obvious omission that was never solved. I was shocked when I switched to macOS. I couldn’t believe how much better the typical install experience was compared to Windows. Just drag the downloaded file into a folder. No need to run some bespoke install wizard. Even when applications did need to run something to install, it was almost always just the same (presumably system-provided) install flow.
- pjc50 1y ago
  The first time I encountered something this wonderfully simple was on the Acorn Archimedes (RiscOS): an "application" was a folder whose name started with an exclamation mark. It could customize its icon. If you had the luxury of a hard disk, you could simply drag-and-drop a copy of an application from its floppy disk on which it was distributed.
jaoane 1y ago
Uh??? It’s had one for 25 years already: https://en.m.wikipedia.org/wiki/Windows_Installer https://en.m.wikipedia.org/wiki/Windows_Installer
- pjc50 1y ago
  MSI certainly works, but it's also a deeply insane file format and the tooling for building MSI installers was never great. Hence InstallShield etc existed.
  - Kwpolska 1y ago
    InstallShield predates Windows Installer by about a decade.
    - cruffle_duffle 1y ago
      It’s funny though, because despite MSI coming into existence the problems InstallShield fix didn’t really change much.
    - pjc50 1y ago
      You're right, I've conflated MSI with .CAB which was used back in the floppy era.
      - WorldMaker 1y ago
        CAB is a format like ZIP. MSIs are fun because they use CAB files under the hood. But also a database format from the Microsoft JET Engine that was an ancient predecessor to the Windows Registry and contemporary/counterpart of the Office Access format at the time. It's really interesting to compare MSI to MSIX which is ZIP/XML instead of CAB/weird JET DB file.
causality0 1y ago
There are a lot of mind-bogglingy obvious features Windows lacks. For example, there should be a simple menu that controls what entries show up on the right click menu and in what order.
- supriyo-biswas 1y ago
  When I was using Windows many years ago, there used to be Sysinternals Autoruns[1] which could control your context menu entries. I have no idea whether it continues to work under Windows 11 though. [1] https://learn.microsoft.com/en-us/sysinternals/downloads/autoruns https://learn.microsoft.com/en-us/sysinternals/downloads/aut...
- Bjartr 1y ago
  Based on reading a lot of The Old New Thing blog by MS veteran Rayond Chen, I think there's a pretty straightforward reason: A user could accidentally do it and end up with a 'broken' menu they don't know how to fix, and Windows being 'broken' in that way is Windows' fault from the perspective of such a user. This sort of thing can and does cause a support burden, which is an expensive tradeoff. So rather than it being a built in capability, a user would need to manipulate the registry or use a third-party program to do it for them. At least, that's the reasoning that would've come up at MS when adding such a feature was suggested internally (and it certainly has been)
  - causality0 1y ago
    Seems like you know a lot on the subject, so I'll ask you about another missing obvious feature: why's there never been an option to auto-expand the task bar with the number of open windows? It seems unquestionable that if you have three windows open you need a single-row task bar and if you have twelve windows open you need a two-row task bar yet if you want one you have to manually unlock it and then manually expand it.
xvilka 1y ago
macOS has a graphical AppStore but no easy way to run an update from command line. There's third-party project - mas[1] but it's limited by Apple constantly changing APIs. [1] https://github.com/mas-cli/mas https://github.com/mas-cli/mas
- dangus 1y ago
  The command line as a concept is not a prerequisite for having some kind of management tool to manage updates for users. Classic Macintosh systems did not have a user-facing command line at all.
RiverCrochet 1y ago
Microsoft's first popular operating system was MS-DOS, so your first versions of Windows kinda acted like DOS as far as third-party software was concerned: - No concept of installers apart from an INSTALL.COM or INSTALL.EXE provided by the vendor. - Installer often just copied stuff to a new root-level subdirectory, selectable in the installer, if one was there. Sometimes you just had to make your own subdirectory and copy everything yourself. - Often everything regarding the application was done in that subdirectory, including running executables, reading data, writing data, and often saving documents. This was very different from the UNIX tradition of putting executables in /bin, and read/write data in /etc or /var, with appropriate permissions set. Other interesting stuff: - Apart from a couple of files (IO.SYS, MS-DOS.SYS) needing to be the 1st and 2nd "inodes" on the disk (so the bootloader could find them), and CONFIG.SYS and AUTOEXEC.BAT having to reside somewhere in the root directory, the kernel of MS-DOS didn't really care at all about any other file. Even COMMAND.COM could be anywhere you want - you would tell MS-DOS where it was with the COMSPEC= setting in CONFIG.SYS. So all your DOS external commands could be anywhere (and reachable if a PATH command was in your AUTOEXEC.BAT), although I believe the MS-DOS installer put them at \DOS or \MSDOS, so that was probably pretty de-facto standard. So... DOS, the precursor to Windows - it was anything goes. When Windows became a thing (version 3.x was when it took off), the above is typically how users worked with programs under MS-DOS at the time. It's why programs tended to do everything in their "C:\Program Files" folder. And I don't know when Microsoft developed the arcane and overengineered .MSI system but it wasn't right when Windows NT came out in 1993 and I think it wasn't even there for Windows 95 when that came out. Even if Microsoft did have .MSI right with the first release of Windows NT/95, there were still many existing programs that didn't use it and wouldn't use it right away. So Microsoft had to support the existing mess and habits from DOS days.
- netsharc 1y ago
  C:\Program Files is a Windows 95 thing, Windows 3.x was pre-VFAT and didn't even support showing long file names. I don't remember where programs would be placed in Win 3.1... I do remember the full screen setup.exe programs with the blue background...
  - 1y ago
mike_hearn 1y ago
It's had one for over a decade now called MSIX, see my other comment here: https://news.ycombinator.com/item?id=44118703 https://news.ycombinator.com/item?id=44118703 Not much uses it because very little new development happens for Windows, even by Microsoft. Everyone either uses portable frameworks and inherits the defaults, which aren't MSIX, or has legacy systems they developed from before MSIX got good.
dabockster 1y ago
Windows didn’t even have a remotely solid first party package management system (WinGet) until like 2018 or something. And that didn’t have a controller GUI (UniGetGUI) until COVID when someone stuck at home finally coded one up.

zabzonk 1y ago

The MS software environment is much larger and complex than that of the Mac? So creating tools to manage it is far more difficult?

deleted 1y ago

[deleted]

chongli 1y ago

Mac OS hasn't had that from the start. Sure, many apps are installed simply by drag-and-drop to the Applications folder. However, plenty of apps have installers you need to run which usually request administrator credentials to install support files system-wide. Some of these apps have their own updaters which are set to run at startup. In the past, many apps had extensions and control panels they installed into the System Folder which required a reboot. Finally, many of these same apps had no uninstaller. You had to hunt throughout the system to remove all the stuff they installed, including preference files and cache files just in case you wanted to reinstall without having problems down the road.

flenserboy 1y ago
it should have been drag-and-drop only from the start. I'd gladly hop on to a Linux/BSD distro which would be clean & consistent with this.
- ebiester 1y ago
  What if there are setup questions that need to be answered that change the trajectory of an install? For example, some installs will have features you can opt out of to save space.
  - flenserboy 1y ago
    good question. that would not be an easy problem to work out.
- soulofmischief 1y ago
  The fact that most Linux distros don't do this is a huge selling point for me. In the early Linux days, software distribution was a nightmare, but today the average popular distro's package management experience is unparalleled. I much prefer using my terminal to manage packages than some unwieldy GUI, and I don't have to leave my terminal to discover new packages or remove old ones.
  - dmonitor 1y ago
    AppImages are still fairly common, though, and those are practically begging for a drag/drop interface
  - flenserboy 1y ago
    fair. but something similar could be done via a terminal-friendly packaging system — one directory, one location for everything application-related. it's not so much the drag-and-drop I'm drawn to as it is the clear location for each application.
  - curt15 1y ago
    In my experience, the main weakness of Linux distros' package management experience is they don't distinguish core system functionality from add-on software. After all, a Linux distro is ultimately just a bag of packages. Every package installs into the global `/usr` directory, and the package manager treats third-party packages and system packages equally. The Windows analogue would be if all software installed themselves into the Windows folder, or if you could uninstall ntoskrnl from Add/Remove programs. This leads to several problems: 1. It's easy to inadvertently break one's system. How often have users accidentally uninstalled their desktop environment due a buggy dependency specification or dependency solver? Shouldn't there be a whitelist of core system packages and files that should never be touched during ordinary package transactions? There was also a Fedora bug maybe 1 year ago where a problem with the Google Chrome RPM's GPG signing key blocked system updates unless one manually overrode the package manager transaction to skip broken packages. Imagine if Chrome could cause Windows updates to fail or if a misconfigured Homebrew package could block MacOS updates. 2. It's easy to accumulate cruft over time because there's no out-of-box tracking of software I've added compared to be the base system. I could manually keep a list in a text file, but what about any dependencies of the packages on that list? What about any config files in `/etc` left behind by packages even after they are uninstalled? I'd like an easy way to revert my system to its out-of-box condition without carefully inspecting every line of `dpkg -l` (of which there could hundreds or thousands). With Homebrew on MacOS I can just blow away `/opt/homebrew`.
endemic 1y ago
necessitating such programs as https://freemacsoft.net/appcleaner/ https://freemacsoft.net/appcleaner/ (no affiliation)

ogig 1y ago

Serious software vendors do usually provide msi packages for corporate deployments via GPOs. I don't remember having to package myself anything in the last 10 year or so. Maybe had to read some documentation to tune install parameters. But I agree that it could be so much better.

dabockster 1y ago
That, and WinGet really wasn’t a thing until the height of COVID when people really found out that it even existed. There’s still a ton of stuff that doesn’t install quite right in it.

dist-epoch 1y ago

It already does, it's called the Microsoft Store. Apps from there are auto-updated by the system.

paulryanrogers 1y ago
Doesn't this include limitations on what the software can do?
- pacifika 1y ago
  Same as the Mac, limitations are different of course
- WorldMaker 1y ago
  Not in several years, no. MSIX, since it was renamed that, supports nearly the full gamut of MSI (just specified in XML directly instead of an ancient, deprecated Microsoft JET database file format and modern ZIP instead of the ancient Windows CAB archive format), and classic-style Win32 apps can be installed with no more of a sandbox than is usual from a raw MSI install rather than an MSIX install.
pjc50 1y ago
Reading between the lines on this announcment, it sounds like a plan to uncouple the mechanism of msix/appx and Windows packages from the policy of the App Store. WinUI3 (if anyone ever bothers to use it, including Microsoft) already distributes its library dependency this way, as a store package.
- keyringlight 1y ago
  >(if anyone ever bothers to use it, including Microsoft) I think this is a large part of the problem, within the range of applications MS offers there's range of ways they get distributed, installed and managed. Will office use it? How about visual studio, teams, various windows components? It'd be more 'sit up and listen' interesting if MS committed to using it themselves, showed it works for a range of use cases and was great at doing it.

oldpersonintx2 1y ago

the real innovator here was FreeBSD, even before Linux. In the mid 90s, a FreeBSD user could build their entire operating system and apps with code and tools managed by FreeBSD. Eventually systems like Debian improved on this, but FreeBSD was first.

worthless-trash 1y ago
I feel like pretty much every distro I used n thr 90s allowed for ef hosting and building. Even early redhat had the ability to build every package from arc rpm. Unless i am misunderstanding what you mean by build.

barrkel 1y ago

It's an incredibly complex problem, when you take into account drivers, system extensions, shared library versoning and so on, and even harder to solve when you can't rely on the presence of an internet connection. Then, once you've built it out, you need to convince software vendors to use your gatekeeping installation mechanism, and hope they believe the executives won't see this as leverage to extract rents later.

madeofpalk 1y ago

macOS doesn’t really. There’s App Store, with varying degrees of success. And then most other apps use Sparkles framework, a third party library. I am surprised that something like sparkle hasn’t found footing on Windows.

duskwuff 1y ago
re. Sparkle - same. Sparkle is practically the platonic ideal of a self-update framework; there's good reason why it's been the uncontested standard on the platform for nearly twenty years (!!).
- comex 1y ago
  As a user, I hate Sparkle. At least, I hate Sparkle's default mode where you have to click "Install Update", then wait for the update to download, then authenticate, then wait for the update to extract, then wait for the app to relaunch. Too slow. When I open an app, I want to use it, immediately. I'd rather have apps update in the background; barring that, at least give me a button to manually start a background update while I continue to use the older version of the app.
  - mike_hearn 1y ago
    Sparkle does have that for a long time now, but the default does still want you to agree to background updates the first time. Developers can turn that off and make apps update silently in the background (when they're running).

rimunroe 1y ago

> I have always wondered why Windows never had a unified installation, update, and uninstall framework like MacOS had from the start. It seems like an obvious omission that was never solved. I was shocked when I switched to macOS. I couldn’t believe how much better the typical install experience was compared to Windows. Just drag the downloaded file into a folder. No need to run some bespoke install wizard. Even when applications did need to run something to install, it was almost always just the same (presumably system-provided) install flow.

pjc50 1y ago
The first time I encountered something this wonderfully simple was on the Acorn Archimedes (RiscOS): an "application" was a folder whose name started with an exclamation mark. It could customize its icon. If you had the luxury of a hard disk, you could simply drag-and-drop a copy of an application from its floppy disk on which it was distributed.

jaoane 1y ago

Uh??? It’s had one for 25 years already: https://en.m.wikipedia.org/wiki/Windows_Installer https://en.m.wikipedia.org/wiki/Windows_Installer

pjc50 1y ago
MSI certainly works, but it's also a deeply insane file format and the tooling for building MSI installers was never great. Hence InstallShield etc existed.
- Kwpolska 1y ago
  InstallShield predates Windows Installer by about a decade.
  - cruffle_duffle 1y ago
    It’s funny though, because despite MSI coming into existence the problems InstallShield fix didn’t really change much.
  - pjc50 1y ago
    You're right, I've conflated MSI with .CAB which was used back in the floppy era.
    - WorldMaker 1y ago
      CAB is a format like ZIP. MSIs are fun because they use CAB files under the hood. But also a database format from the Microsoft JET Engine that was an ancient predecessor to the Windows Registry and contemporary/counterpart of the Office Access format at the time. It's really interesting to compare MSI to MSIX which is ZIP/XML instead of CAB/weird JET DB file.

causality0 1y ago

There are a lot of mind-bogglingy obvious features Windows lacks. For example, there should be a simple menu that controls what entries show up on the right click menu and in what order.

supriyo-biswas 1y ago
When I was using Windows many years ago, there used to be Sysinternals Autoruns[1] which could control your context menu entries. I have no idea whether it continues to work under Windows 11 though. [1] https://learn.microsoft.com/en-us/sysinternals/downloads/autoruns https://learn.microsoft.com/en-us/sysinternals/downloads/aut...
Bjartr 1y ago
Based on reading a lot of The Old New Thing blog by MS veteran Rayond Chen, I think there's a pretty straightforward reason: A user could accidentally do it and end up with a 'broken' menu they don't know how to fix, and Windows being 'broken' in that way is Windows' fault from the perspective of such a user. This sort of thing can and does cause a support burden, which is an expensive tradeoff. So rather than it being a built in capability, a user would need to manipulate the registry or use a third-party program to do it for them. At least, that's the reasoning that would've come up at MS when adding such a feature was suggested internally (and it certainly has been)
- causality0 1y ago
  Seems like you know a lot on the subject, so I'll ask you about another missing obvious feature: why's there never been an option to auto-expand the task bar with the number of open windows? It seems unquestionable that if you have three windows open you need a single-row task bar and if you have twelve windows open you need a two-row task bar yet if you want one you have to manually unlock it and then manually expand it.

xvilka 1y ago

macOS has a graphical AppStore but no easy way to run an update from command line. There's third-party project - mas[1] but it's limited by Apple constantly changing APIs. [1] https://github.com/mas-cli/mas https://github.com/mas-cli/mas

dangus 1y ago
The command line as a concept is not a prerequisite for having some kind of management tool to manage updates for users. Classic Macintosh systems did not have a user-facing command line at all.

RiverCrochet 1y ago

Microsoft's first popular operating system was MS-DOS, so your first versions of Windows kinda acted like DOS as far as third-party software was concerned: - No concept of installers apart from an INSTALL.COM or INSTALL.EXE provided by the vendor. - Installer often just copied stuff to a new root-level subdirectory, selectable in the installer, if one was there. Sometimes you just had to make your own subdirectory and copy everything yourself. - Often everything regarding the application was done in that subdirectory, including running executables, reading data, writing data, and often saving documents. This was very different from the UNIX tradition of putting executables in /bin, and read/write data in /etc or /var, with appropriate permissions set. Other interesting stuff: - Apart from a couple of files (IO.SYS, MS-DOS.SYS) needing to be the 1st and 2nd "inodes" on the disk (so the bootloader could find them), and CONFIG.SYS and AUTOEXEC.BAT having to reside somewhere in the root directory, the kernel of MS-DOS didn't really care at all about any other file. Even COMMAND.COM could be anywhere you want - you would tell MS-DOS where it was with the COMSPEC= setting in CONFIG.SYS. So all your DOS external commands could be anywhere (and reachable if a PATH command was in your AUTOEXEC.BAT), although I believe the MS-DOS installer put them at \DOS or \MSDOS, so that was probably pretty de-facto standard. So... DOS, the precursor to Windows - it was anything goes. When Windows became a thing (version 3.x was when it took off), the above is typically how users worked with programs under MS-DOS at the time. It's why programs tended to do everything in their "C:\Program Files" folder. And I don't know when Microsoft developed the arcane and overengineered .MSI system but it wasn't right when Windows NT came out in 1993 and I think it wasn't even there for Windows 95 when that came out. Even if Microsoft did have .MSI right with the first release of Windows NT/95, there were still many existing programs that didn't use it and wouldn't use it right away. So Microsoft had to support the existing mess and habits from DOS days.

netsharc 1y ago
C:\Program Files is a Windows 95 thing, Windows 3.x was pre-VFAT and didn't even support showing long file names. I don't remember where programs would be placed in Win 3.1... I do remember the full screen setup.exe programs with the blue background...
- 1y ago

mike_hearn 1y ago

It's had one for over a decade now called MSIX, see my other comment here: https://news.ycombinator.com/item?id=44118703 https://news.ycombinator.com/item?id=44118703 Not much uses it because very little new development happens for Windows, even by Microsoft. Everyone either uses portable frameworks and inherits the defaults, which aren't MSIX, or has legacy systems they developed from before MSIX got good.

dabockster 1y ago

Windows didn’t even have a remotely solid first party package management system (WinGet) until like 2018 or something. And that didn’t have a controller GUI (UniGetGUI) until COVID when someone stuck at home finally coded one up.