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.
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.
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.
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.
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`.
> It's easy to inadvertently break one's system
rpm/yum/dnf actually have a system for this called protected packages which can't be uninstalled without some ceremony on the part of the caller. Distros use this feature quite sparingly and reserve it for cases where you will truly break your system. Sometimes you want to uninstall your DE.
AppImages are still fairly common, though, and those are practically begging for a drag/drop interface
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.
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.
Fedora-Gnome has a pretty nice software catalog with one click install and centrally managed updates. I'm sure there's a couple things I've done without because I didn't want to bother installing via dnf but it's my daily driver, no issues
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.
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...
I remember on my old DOS/Win3.11 machine, I imposed some order on things by only installing “minor” applications to C:\BIN, and larger programs to C:\APPS. Wanted as few top-level folders as possible. Took a bit of effort sometimes, but otherwise there’s total chaos.
I would always cringe whenever I noticed how other folks would have everything installed in the top-level folder, or sometimes in C:\WINDOWS or other random places.
If I were to do it over again today, I would do it differently: I’d install programs that are strictly for doing stuff TO the computer itself in C:\UTILS, and everything else in C:\APPS.
If I ever build a windows installer, I’m manually adding in that full screen blue background for nostalgia’s sake.
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.
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.
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.
> 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.
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.
It's had one for over a decade now called MSIX, see my other comment here:
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.
The MS software environment is much larger and complex than that of the Mac? So creating tools to manage it is far more difficult?
It already does, it's called the Microsoft Store. Apps from there are auto-updated by the system.
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.
>(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.
Office has long been the special case inside Windows Update (or Microsoft Update in the years where the brand changed whether you had Office installed or not), since the earliest days of Windows Update. Windows Update started as Office Update in the Office 97 era before becoming an out-of-the-box Windows thing in Windows 98, as I recall it. (The internet doesn't seem to have images of the Office 97 "Office Update" tool, so either my memory is foggy or it truly was short-lived enough that the general internet and Wikipedia have forgotten it.) In Windows 8 and 10 Microsoft tried to move Office updates into the Store and were mostly successful just about the time that the Office team decided they were bored with the Store and moved back "home" to Windows Update (or Microsoft Update, I suppose, if you insist).
If Office is no longer the special case in Windows Update and more applications can use it, that would be interesting. A lot of third party drivers have already been using it more, and that also seemed a special case before. Opening it up as a platform for any third party seems like a long time coming.
(Visual Studio is an interesting case, too, because some of it has always had security updates in Windows Update, but yet more of it is not updated that way than is. Originally the border lines were "owned by Windows components" versus "Visual Studio owned components" but those lines have become so blurry, especially in the .NET 5+ era where Windows no longer owns anything about .NET, but Windows Update still serves critical security patches.)
You've been able to use MSIX outside of the MS Store for years.
Also, the App Store "policies" have been hugely relaxed for years and allow general Win32 apps with no more sandboxing than usual from any other way of installing the app.
Doesn't this include limitations on what the software can do?
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.
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.
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 (!!).
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.
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).
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.
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/aut...
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)
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.
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.
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.
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.
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.
Uh??? It’s had one for 25 years already: https://en.m.wikipedia.org/wiki/Windows_Installer
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.
InstallShield predates Windows Installer by about a decade.
It’s funny though, because despite MSI coming into existence the problems InstallShield fix didn’t really change much.
You're right, I've conflated MSI with .CAB which was used back in the floppy era.
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.