Windows still has a situation where Chrome's updates use a special service to dodge around escalation issues, and Spotify and many others install in AppData for the same reason, and lots of uninstallers just don't work, leaving files and other things behind. MSI has required "chained signing" using an old key to sign the new one forever, but when you're maintaining updates over a decade that isn't very easy to do. I hope they can clean it all up!
They install in AppData to get around IT admin blocks. Unless a sysadmin has the tech available to operate on a whitelist only basis (which not everyone does - it’s super expensive), you can be certain that at least some users have things like Spotify installed illicitly.
And this is why having a solid working relationship between all levels of IT and your users are so important. It really is customer service first, tech second. If your users trust you as the IT admin, they’ll know to ask first before downloading AppData installers like this before they become a job ending issue for them.
For reference chrome uses open source Omaha installer and update and the others noted use Squirrel. Both can exist in users app data (squirrel only can however as its philosophy is to be user installable without admin.)
Are you sure the others use Squirrel? After it’s maintainer decided to crash out and abandon multiple libraries including Squirrel, I was under the impression it was abandoned?
It used to use Omaha. They recently rewrote it and Chrome now uses an installer framework fully maintained in their own tree. It's conceptually similar but cleaned up.
For the leaving files around case, isn't that an impossible thing to really deal with from the installer stand point for non containerized applications that have root/admin access?
Because they can just create and write to random directories whenever they want. And any Uninstaller, either provided by the app or Microsoft could just miss these files, because they aren't recreating the full program control flow.
This is why we invented distributions (Linux and friends): one package manager, common practices and shared code, to avoid everybody doing its own (sometime broken) thing
Why is it impossible if you can track where they write during the installation process? There are even apps that do that. For apps that run as admin that's harder indeed, but at least for the installation process the good-but-not-perfect design could still be added?
They don’t install into appdata to dodge escalation. They’re not hiding. Microsoft has recommended installing into appdata for nearly a decade. Maybe over a decade at this point. It’s how you’re supposed to install applications today, if those applications don’t need elevation to run.
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.
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...
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.
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.
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.
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.
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 (!!).
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.
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)
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.
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.
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.
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.
I have windows 10 updates disabled on all of my machines. Haven’t updated in at least a year and it has been smooth sailing. Microsoft has ruined the word “update” and turned it into a dirty word.
I don’t understand why Nadella hates windows so much.
I imagine there are some people clutching their pearls over not installing updates to Windows due to security concerns.
But for most home users, it's not a big deal. I imagine 99% of home users are behind a NAT, and being behind NAT means external attackers aren't going to be able to connect to your machine and run remote exploits (ie, EternalBlue). The only way to get compromised is to get trojaned, in which case a Windows update wasn't going to save you anyways. At best, it means a trojan might have a slightly harder time escalating to Admin/SYSTEM without getting caught, but a trojan doesn't need Administrator permissions to ransomware your Documents folder or add your machine to a botnet.
As long as your browser is up to date, you'll be fine.
That wasn't the case a few months ago (maybe a year) where javascript payloads could be loaded hitting IPs on the LAN, so hitting millions of http(s) requests to IOT devices which would then get raw socket support.
Hitting default gateways for web admin panels etc.
I found the solution for Windows update though.Just don't use Windows. Microsoft can't be trusted.
Most of the “don’t update windows” talk, in my experience, comes from monolithic kernels like Windows 98/ME and Linux, where a single update can change or break a ton of seemingly random stuff. Hasn’t been relevant for 99% of desktop computers for 25 years (not counting Mac stuff).
Exactly. I don’t even have an anti virus and completely disabled windows defender because it was so annoying and everything just runs great. Also I’m using LTSC.
It makes sense, since exactly the same method is employed by all Linux package managers. The problem with Windows Update though it's too basic compared to other alternatives like Chocolatey, Scoop, or WinGet.
I am embarrassed about how late I was to learn that WinGet existed. It was only after I came back from years of Ubuntu as a daily driver that I googled "windows package manager" and discovered it.
Don’t be too embarrassed, WinGet is only 5 years old and is nothing more than an alternative to Scoop and Choco.
It’s « just » a tool which will fetch installation manifests on a centralized Microsoft GitHub repository and execute it. Exactly like brew or chocolatey. It’s fine for a third party « package manager » but it feels pretty weak for an official system tool.
Also, if I’m not wrong, it’s only available as a CLI tool which makes it pretty useless for 95 percent of Windows users and for developers to distribute software with it.
The thing is useful for sure but it’s far from a Linux package manager.
I really prefer Scoop over WinGet. Scoop installs most packages into exactly one folder and sets up shims/links. And it has an unified install/update methodology.
WinGet is more or less just downloading the installers and running them, and doesn't properly track the installed applications and isn't always able to update them.
I am embarrassed for Microsoft with how long it took them to implement WinGet. It still leaves much to be desired, but I guess if you’re used to PowerShell, then weird period-delimited CamelCase package names are probably something that fits your current routine experience anyway. Coming from apt/yum/brew, it feels almost hostile to the user that even the most basic packages must be searched for just to confirm the syntax of their name.
Windows Update's slowness is a feature more than a bug. The underlying Background Intelligent Transfer Service (BITS) is still such a cool piece of tech even if it has been ages since any web browser let you send low priority downloads to it or an RSS reader was built on top of it. (Both things that existed and were cool, especially in the dialup era where bandwidth was scarce and irregularly connected.) It's designed to prioritize active user needs over pending downloads, throttling itself based on CPU activity and bandwidth usage and download quotas and battery state and expected runtime and now things like estimated energy mixtures (why not download big things when energy is greener?). (It really does download faster when you are not looking, that's what it was designed to do.)
A key aspect of many Linux package managers such as DNF or APT is that the repository is just a static website. The server doesn't need to compute the delta between where the machine is and where it should be - that's done in the client.
That, of course, imposes some limits WRT package visibility and other policies you might want to enforce - you can't easily limit a certain set of users to a subset of your repo.
Thanks to thoughts provoked by this thread, I just discovered UniGetUI, which is really freakin' cool. This going on any Win box that I control going forward.
> The main goal of this project is to create an intuitive GUI for the most common CLI package managers for Windows 10 and 11, such as WinGet, Scoop, Chocolatey, Pip, Npm, .NET Tool, PowerShell Gallery and more (Check out the package manager compatibility table)!. With this app, you can easily download, install, update, and uninstall any software published on the supported package managers — and much more!
For non developers/advanced users that can use Winget/CL to update apps, I recommend the open source app UniGetUI [1], is actively maintained, it has a nice UI and works like a charm.
I'm more comfortable the less Microsoft wants to do. Security updates? API changes? Sure. But I was most happy when windows just ran applications and let me drag them around the screen.
Its bad enough hostile software updates from Microsoft are force bundled with Microsoft security updates. Not sure I want to bundle everyone's else's hostile updates with them as well.
Readit News
And this is why having a solid working relationship between all levels of IT and your users are so important. It really is customer service first, tech second. If your users trust you as the IT admin, they’ll know to ask first before downloading AppData installers like this before they become a job ending issue for them.
Because they can just create and write to random directories whenever they want. And any Uninstaller, either provided by the app or Microsoft could just miss these files, because they aren't recreating the full program control flow.
This surprises me, I would have thought usees would think package removal would only meant package removal.
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.
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.
- 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.
I do remember the full screen setup.exe programs with the blue background...
But I agree that it could be so much better.
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 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.
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.
WinUI3 (if anyone ever bothers to use it, including Microsoft) already distributes its library dependency this way, as a store package.
I am surprised that something like sparkle hasn’t found footing on Windows.
[1] https://learn.microsoft.com/en-us/sysinternals/downloads/aut...
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)
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.
Unless i am misunderstanding what you mean by build.
[1] https://github.com/mas-cli/mas
Classic Macintosh systems did not have a user-facing command line at all.
Deleted Comment
I don’t understand why Nadella hates windows so much.
But for most home users, it's not a big deal. I imagine 99% of home users are behind a NAT, and being behind NAT means external attackers aren't going to be able to connect to your machine and run remote exploits (ie, EternalBlue). The only way to get compromised is to get trojaned, in which case a Windows update wasn't going to save you anyways. At best, it means a trojan might have a slightly harder time escalating to Admin/SYSTEM without getting caught, but a trojan doesn't need Administrator permissions to ransomware your Documents folder or add your machine to a botnet.
As long as your browser is up to date, you'll be fine.
Hitting default gateways for web admin panels etc.
I found the solution for Windows update though.Just don't use Windows. Microsoft can't be trusted.
It’s « just » a tool which will fetch installation manifests on a centralized Microsoft GitHub repository and execute it. Exactly like brew or chocolatey. It’s fine for a third party « package manager » but it feels pretty weak for an official system tool.
Also, if I’m not wrong, it’s only available as a CLI tool which makes it pretty useless for 95 percent of Windows users and for developers to distribute software with it.
The thing is useful for sure but it’s far from a Linux package manager.
WinGet is more or less just downloading the installers and running them, and doesn't properly track the installed applications and isn't always able to update them.
That, of course, imposes some limits WRT package visibility and other policies you might want to enforce - you can't easily limit a certain set of users to a subset of your repo.
> The main goal of this project is to create an intuitive GUI for the most common CLI package managers for Windows 10 and 11, such as WinGet, Scoop, Chocolatey, Pip, Npm, .NET Tool, PowerShell Gallery and more (Check out the package manager compatibility table)!. With this app, you can easily download, install, update, and uninstall any software published on the supported package managers — and much more!
https://github.com/marticliment/UniGetUI - 16.2k stars
[1] https://github.com/marticliment/UniGetUI
And if you can donate money to this person at all, do it.