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!
hypercube33 · 20h ago
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.)
MortyWaves · 18h ago
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?
mike_hearn · 4h ago
Squirrel is abandoned for years and still used anyway, often by people who don't realize it's abandoned. It's the default if you use the Electron toolchain, so that's why. It has serious design problems too, like it breaks Windows networks by bloating people's roaming home directories with dozens of independent copies of Chrome which then get backed up, copied around on login etc. Admins loathe it as the whole point of this design is to bypass their ability to manage their own deployments, although they still get the blame when things break, of course.
There's a better way, which I am shamelessly self-promoting in this thread (as it's 100% on topic) - my company makes a tool that can ship self-updating Electron apps and beyond being not abandoned, it's got a lot of really useful features, like being able to do the build and upload of signed updating packages (using the tech MS is pushing here) from Linux CI workers, without needing a Windows license.
It can also do forced updates on launch, which can be helpful for apps where the protocol between client and server changes regularly. And it plays well with corporate Windows deployments. People can install apps locally without needing administrator access but it goes into c:\Program Files
mike_hearn · 19h ago
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.
tobias3 · 17h ago
And since the Chrome fork Edge is part of Windows now, this updater already runs on all Windows machines (e.g. the MicrosoftEdgeUpdateTaskMachineUA scheduled task).
They did not even use Windows update for that one.
twosdai · 21h ago
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.
eviks · 1h ago
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?
JackSlateur · 2h ago
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
ThunderSizzle · 53m ago
And now we also have flatpak, snap, etc. on top ofnthe "one package manager"
contextfree · 10h ago
Yes. UWP/MSIX+AppContainer addressed this, but inherently impose limitations on what the app and installer can do.
pjmlp · 17h ago
To be fair, many GNU/Linux packages also leave garbage behind.
worthless-trash · 11h ago
Do you expect things not in the package manifest to get cleaned up by thr package removal tools?
This surprises me, I would have thought usees would think package removal would only meant package removal.
pjmlp · 8h ago
Yes, if there is a script generating stuff at install time, there should be a script deleting the same stuff at removal time.
Most of the time there isn't one.
worthless-trash · 1h ago
This is not what is generally expected at package removal, at least from my understanding.
Where do you draw the line at removal, configuration files, user created documents, config files on networked home directories.
I dont think you are being unreasonable, maybe we need better clean up depending on what the user needs..
It would mean tracking the creator of filws and tagging them appropriately, using this list during uninstall.
naikrovek · 8h ago
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.
eviks · 1h ago
What about multi user sharing of an app? I thought that was the main benefit (at least that's what app installers keep saying the difference is)
guidedlight · 1d 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.
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.
chongli · 1d 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.
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.
soulofmischief · 21h 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.
curt15 · 17h 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`.
Spivak · 14h ago
> 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.
worthless-trash · 11h ago
What is core for you is add on for someone else.
dmonitor · 21h ago
AppImages are still fairly common, though, and those are practically begging for a drag/drop interface
flenserboy · 19h 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.
jazzyjackson · 7h ago
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
ebiester · 22h 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 · 19h ago
good question. that would not be an easy problem to work out.
RiverCrochet · 20h 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 · 19h 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...
gord288 · 16h ago
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.
pjmlp · 17h ago
Also it isn't as if everyone else besides Microsoft actually had installers.
barrkel · 1d 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.
ogig · 1d 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.
rimunroe · 1d 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 · 23h 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.
mike_hearn · 19h ago
It's had one for over a decade now called MSIX, see my other comment here:
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.
zabzonk · 1d 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?
madeofpalk · 1d 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 · 18h 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 · 17h 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 · 4h 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).
xvilka · 21h 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.
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.
dist-epoch · 1d ago
It already does, it's called the Microsoft Store. Apps from there are auto-updated by the system.
pjc50 · 23h 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 · 22h 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.
WorldMaker · 18h ago
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.)
mike_hearn · 19h ago
You've been able to use MSIX outside of the MS Store for years.
WorldMaker · 18h ago
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.
paulryanrogers · 1d ago
Doesn't this include limitations on what the software can do?
WorldMaker · 17h 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.
pacifika · 1d ago
Same as the Mac, limitations are different of course
causality0 · 22h 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 · 22h 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.
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)
oldpersonintx2 · 1d 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 · 11h 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.
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 · 21h ago
InstallShield predates Windows Installer by about a decade.
pjc50 · 21h ago
You're right, I've conflated MSI with .CAB which was used back in the floppy era.
WorldMaker · 17h 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.
cruffle_duffle · 21h ago
It’s funny though, because despite MSI coming into existence the problems InstallShield fix didn’t really change much.
archerx · 21h ago
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.
Sohcahtoa82 · 20h ago
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.
eGQjxkKF6fif · 19h ago
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.
Sohcahtoa82 · 17h ago
How is that a Windows problem? Seems to be a browser problem, unless I'm misunderstanding the source of those JavaScript payloads.
archerx · 19h ago
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.
npteljes · 1h ago
Unfortunately this is just anecdotal. I also did many things in my life that were risky, and I got away with them every single time. This doesn't prove that they were not risky, or that my results are reproducible.
That said, I also hate Windows updates, and especially the way Windows handles them. LTSC is also my way to avoid some of it, especially the ""feature"" updates. LTSC is something I also recommend, if people can manage an activation server, or I can point them to mine.
xvilka · 1d ago
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.
consumer451 · 1d ago
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.
pjerem · 1d ago
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.
WorldMaker · 17h ago
> It’s « just » a tool which will fetch installation manifests on a centralized Microsoft GitHub repository and execute it.
The winget repo has a ton of useful installation manifests, sure, but isn't "just" a tool to fetch manifests from that one repo. (Also, it doesn't fetch the data directly from GitHub, even though that is the source of truth, it has a light REST service in between which does a lot of caching and DDoS management and what have you.) Winget also by default installs Windows Store apps, too. It's also configurable so you can add your own installation manifest repos if you wish (such as on-premise private feeds).
0points · 1d ago
> 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.
Back in my day this would be seen as an exercise left for the user, and thus a new junior dev was born building a front end.
I've also been quickly impressed this week with the winget UI now provided inside Command Palette, the new PowerToy "Sherlock/Spotlight" search tool.
sprayk · 21h ago
scoop, Choco, and winget are all very different. winget is closest to Choco in that it prefers to just run regular installers. It keeps its own state of installed packages, though, while winget uses the same sources of truth as "Add/Remove programs" (msstore/appx and the "uninstall" group in the registry). Scoop is its own thing that installs everything under its own prefix and manages its own state.
tumsfestival · 19h ago
>winget uses the same sources of truth as "Add/Remove programs" (msstore/appx and the "uninstall" group in the registry).
I find that behavior incredibly annoying. I mainly use Chocolatey, so every once in a while when a package is heavily outdated or missing from the repo I end up using Winget instead for convenience's sake. That means Winget keeps trying to update or manage Chocolatey packages, and as far as I know, there's no easy way to stop that.
andix · 1d ago
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.
metaltyphoon · 23h ago
> doesn't properly track the installed applications and isn't always able to update them.
How so? I’ve been using it for years and haven’t had a problem yet updating all applications at once.
trallnag · 19h ago
It depends on the application.
Things can get tricky with applications that are installed with WinGet but come with mechanisms to update themselves. If this self-update skips adjusting the right knobs and values in the registry, WinGet will assume that the application is still on the initial version.
For example, this is the case with Obsidian.
nativeit · 1d ago
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.
miyuru · 1d ago
MS did not implement Winget. They stole code from another app called appget.
They 'stole' (brainraped?) the idea and some of the implementation ideas, but the code is entirely separate. winget is implemented in very windows-y C++, appget was C#.
aaomidi · 21h ago
brainrape is an awful word and you should stop using it.
amlib · 1d ago
And it seems pretty slow. I can't even begin to imagine it needing to update 10x more components and perhaps 10x the amount of data.
WorldMaker · 17h ago
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.)
rbanffy · 1d ago
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.
pentagrama · 19h ago
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.
This is really slick. I wasn't aware of this project so thanks for sharing!
consumer451 · 23h ago
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!
That's if it becomes the single point to update, which it won't be, it won't become the only way to update applications
falcor84 · 1d ago
Does this mean that now third-party apps will also be allowed to restart "my" computer?
devnullbrain · 1d ago
No, it isn't restarted! See, all your browser windows are open and in almost the same place. Context? What's that? It always looked like this. You're crazy.
mihaaly · 1d ago
Can't you wait for the next system crash? It is not that long.
antisol · 1d ago
lol lol! Nicely done.
Not sure why this was flagged, but shame on whoever did it.
mihaaly · 14h ago
Hard to be an MS emloyee nowadays. No purpose, no pride, frustation all around.
absurdo · 15h ago
Like other posters I feel this change is way behind the curve, but not because others did it already and long ago; rather, because as a dyed in the wool Win32 API/Petzold Acolyte, the age of desktop apps ended at least a decade ago in my mind. The rare app here or there that people have installed is eclipsed by phone apps and the browser. In my case I tend to by far have utilities installed moreso than any other kind of program, but that’s not a valid business case for MSFT. So who is their target audience?
b0dhimind · 8h ago
Found UniGetUI and it does a great job calling WinGet, Scoop, and a buncha others with an ignore list as well! Windows will never have that level of customizability.
blueflow · 1d ago
30 years late to the party?
eviks · 1d ago
> Microsoft has tried in the past to convince developers to list their apps in the Microsoft Store
> Microsoft’s Windows Package Manager has also tried to solve some of the problems with installing and updating apps on Windows
Nth time is the charm?
0points · 1d ago
> Microsoft’s Windows Package Manager has also tried to solve some of the problems with installing and updating apps on Windows
> but it’s not a widely used way to install and manage apps outside of power users and developers.
Nth time of ignoring what's there and instead building another system.
dinfinity · 23h ago
I mean, it is not that weird for MS to want to create a first party package manager. They definitely looked at existing stuff like Chocolatey etc. [0]
I think it is actually a good move for them to embrace supporting updates for all the non Windows Store stuff in a first party way. There is just way too much software that will never be a Windows Store application. Besides that, more trustworthy checks for malware etc. are included in such a first-party system than in what was already there, simply by having more available infrastructure. It also increases the chances that they can convince developers to move to using install/update libraries that play nice with this official package management tool.
At this point in time, I would definitely advise everybody to start out installing most Windows stuff via winget or if it isn't listed there via Chocolatey.
Bit of a strange announcement. This already happened a long time ago. The MSIX engine that they mention uses a lot of the same technology as Windows Update and thus has many of the same features. I suspect what they mean is adding some more APIs to try and help non-Chrome non-MSIX apps benefit from those.
MSIX is an interesting beast. My company sells a tool called Conveyor [1] that can create these packages from any platform including macOS and Linux given a simple config file for apps using runtimes like Electron, Flutter or the JVM (it's free for open source projects). We do a lot of work to make MSIX work better and be easier to use, because out of the box it's quite raw and in particular there are a lot of bugs in Windows 10 that Microsoft never fix because they view it as EOL. Conveyor creates a tiny 500kb installer EXE that drives the MSIX package manager API to do the install whilst working around these bugs.
Amongst other things, MSIX gives you:
• Chrome-style silent background updates on a regular schedule, even if the app isn't running.
• Incremental block-based delta updates.
• Incremental block-based downloads and installs, i.e. Windows can re-use parts of one app to install another, based on file block hashes. Makes installs very fast when they share a common runtime!
• And those installs/updates can pull blocks from other machines on the LAN too!
• Declarative installs and OS-controlled uninstalls. Writes to the user's AppData directory are virtualized, so uninstalls can be clean.
• Packages can be installed without admin rights, without dumping stuff in the user's home directory. Windows runs an elevated service that does the install for you.
• You can sandbox apps if they're shipped with MSIX.
• EXEs can be automatically added to the user's path, without needing any terminals or shells to be restarted. MacOS can't do that!
• Windows admins can easily deploy and manage them.
• They're cryptographically signed and their integrity is protected by the OS, so malware can't fiddle with the binaries (unless it manages to elevate to root).
• Although you can't create them with a regular zip tool, you can extract them with one.
Conveyor adds some other features on top like the ability to have web-style "update immediately on launch" updates, and a simple Electron/JVM control API so you can force updates on users.
It's a pretty nice feature set overall and has some big advantages over Squirrel, which is what Electron uses. However, I would definitely NOT recommend you try and work with MSIX directly. Microsoft's tooling is quite awkward, and their policy of only supporting fully up to date Win11 machines - and only from Windows - means you can't realistically distribute apps using MSIX unless you go via an intermediary like Conveyor that's committed to making it work. You'll just hit lots of weird bugs and installs that fail for no obvious reason with mysterious error codes. We ploughed through the pain so you don't have to.
As much as anything it seems like a potential rebrand from "Store Updates" to "Windows Updates" and a further merging of the UI of the two similar but related systems. That seems like a good idea to centralize all of that UX together.
aceazzameen · 15h ago
Please no. They'll eventually use some dark pattern to force an update on software that I don't want. MS can't be trusted.
GuestFAUniverse · 23h ago
Better late, than never I guess. I hope all the (crappy) update services disappear. Doesn't make sense to have a centrally managed update where one can pause as necessary, just to get interrupted by an anachronistic design.
jollyllama · 20h ago
Would this offer any mitigation against Crowdstrike type-scenarios? Like, would it make rolling back broken kernel badness easier?
NoPicklez · 6h ago
I don't think so, all this would do is push through the update through a central place. If the update is bad and causes a Kernel panic it will still to do regardless of where the update is coming from.
Microsoft isn't going to test any of the updates themselves before it sends them through the central update feature
zeroCalories · 1d ago
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.
reginald78 · 21h ago
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.
deafpolygon · 4h ago
Given that it's Microsoft, I'm betting the farm that this is only happening because they want more granular control and visibility over who has what installed.
lousken · 1d ago
i really hope they dont mess this up, i have been deploying scheduled winget tasks and it works, for the most part
mrweasel · 1d ago
Do customers want this? ... not that Microsoft really cares.
For home use, I can see this being good as a large segment of users don't stay up to date on security patches, but what about breaking workflows in businesses?
Some businesses deliberately do not upgrade some software packages, because it would break stuff. It makes sense to just push all updates in a subscription based economy, but this could also quickly become exactly that: A subscription hell-hole where companies push updates and now you're old licensed copy of Photoshop is converted to Creative Cloud.
The idea isn't bad, I just don't trust modern software companies to be able to manage this in a way which makes customers happy.
NoPicklez · 12h ago
This won't be much of an issue for businesses as its understood they do updates differently. If you use a Domain Controller you're likely deploying updates in a staged and controlled way throughout your company.
shireboy · 1d ago
I’ve wanted this for a while. I worked on a bank app where the home rolled solution was atrocious. Line of business apps don’t make sense in Microsoft store. But really where I land is to greatly prefer web apps deployed to IaaS because deployment is easier and compatibility is usually a known quantity. Debugging installer or desktop app issues on remote servers and desktops is a hassle I like to avoid if I can
znpy · 1d ago
I often wonder why Microsoft doesn’t go full-apple on its hardware and software.
You only get windows laptops and desktop from Microsoft, but they are highly secure (similar to what apple achieves).
Everything else needs a windows pro license (with tight checks).
I’m fairly sure that would improve windows’ security posture by a huge lot.
jorvi · 1d ago
Because Microsoft isn't a software company anymore, and never was a hardware company. They're services-first now.
They make the majority of their money from businesses with lucrative support contracts, Azure, Active Directory + Office Enterprise suite, etc.
They make the majority of their money from consumers via stuffing Windows with "promotions" (ads) and from Office 365. It is services. Windows barely earns them anything.
Hell, the fact that they're thinking about opening up the Xbox to Steam and have official tutorials on running Gamepass on iOS and Linux should tell you that they don't care what OS on which device you use, so long as you are subscribed to their services.
In an environment like that, a vertical integration play makes little sense. You want your services to be on as many platforms as possible, not attract ire and roadblocks from your partners.
On top of that, they don't have a phone platform onboarding people to the whole hardware ecosystem. Even for Apple, Mac + iPad + AirPod profits are dwarfed by iPhone profits.
stingraycharles · 1d ago
I think it’s a matter of competition / market segmentation. People choose Microsoft partially for the reason it doesn’t lock down things as much in their ecosystem as much as Apple does.
If they want to compete with Apple using Apple’s strategy, they may face a losing battle.
nativeit · 1d ago
I believed that too until I used a Mac for my daily driver. The experience of developing on a machine with native Bash, a relatively mature package handler, and air-tight device integration was MUCH better than Microsoft’s frequently annoying cruft, unexplained crashes, and horrible program management (we won’t call them “packages”, as they tend to leak all over the system with mixed success “uninstalling” them).
pjerem · 1d ago
> a relatively mature package handler
What package handler ? Installing things on macOS is still a mixed bag of disk images with the app to move yourself, or .pkg files or the App Store.
The thing is so broken that brew is the first thing I install on a new Mac.
znpy · 18h ago
> What package handler ?
they're probably referring to homebrew. which quite honestly, makes MacOS barely bearable. The terminology sucks and the ruby language doesn't help. MacOS without homebrew is unbearable.
stackskipton · 21h ago
With downside of company that will toss backwards compatibility out the second someone at Cupertino gets mad.
Microsoft backwards compatibility got them massive market share but also backed them into a corner. Package Managers only work if there is some constrants but I came across software that was dropping .ini files into C:\Windows\System32 in 2017.
potato-peeler · 1d ago
Developers are not the only ones using windows. Software installation UX is much better and controlled in a windows environment than a unix environment.
johncolanduoni · 1d ago
Windows S mode is sort of like this, it mostly only lets you install sandboxed apps from the store. But a lot of Windows security advisories (and from what I can recall most browser sandbox escapes) are actually from random half-assed features tacked on to privileged Windows services that ship with the install, so I’m not sure how much it would help. The Windows architecture has never done a good job of limiting attack surface.
pjc50 · 1d ago
It's not Microsoft's hardware; the OEMs are a real constraint. As is Intel. The market has been remarkably effective at resisting vertical consolidation, even if it's an uneasy truce.
Besides, the antitrust regulators would absolutely hate this.
WillAdams · 1d ago
They tried that a couple of times --- Windows RT, Windows S Mode... the latter is at least still in use.
diggan · 1d ago
> I often wonder why Microsoft doesn’t go full-apple on its hardware and software.
To be honest, I kind of understand they don't want to do that. I bought a Surface Pro 8 some years ago and is probably the worst computing hardware I've experienced in a long time. Even basic things like thermal management is horribly broken when using Windows on it. Running Linux on it gave a slightly better experience, but seems so backwards that they cannot even make their own hardware work well, I thought the combination of hardware+OS by same company would lead to a better experience but nope.
subjectsigma · 1d ago
See the sibling comment, but also wanted to add - they tried something similar with the Windows 11 TPM requirements and people lost their goddamn minds and refused to install it. (Which was justified IMO.) I don’t think a full conversion would go over well with Windows users
keyringlight · 22h ago
There's one where I think it could have made sense, the xbox. They're apparently confident enough about security on those systems as a large part of the point is that they act as locked down game players (related to AMD's work on securing servers IIRC), so adding a locked down 'desktop mode' would seem viable. They'd need to be certain it doesn't enable any new jailbreaks so either mode isn't more useful than they intend, if they wanted people to buy/subscribe to office direct from the store they don't want libreoffice working.
During covid and the supply/demand mismatch as everyone rushed to WFH I was wondering if they could repurpose the cheap S xboxes as cheap desktops. Essentially a reversal of the original 'xbox as a trojan horse' idea, instead of using consoles to get windows in the living room, it's to get windows in the home office.
Krasnol · 1d ago
> I often wonder why Microsoft doesn’t go full-apple on its hardware and software.
One of the reasons they're still much more prevalent than Apple is because they don't.
oldpersonintx2 · 1d ago
To a certain extent it looks like they tried with AI PCs...although not strictly produced only by Microsoft, the AI PCs had higher hardware baseline requirements.
No one seems to care, I expect the AI PCs to eventually sell for 75% discounts.
jmclnx · 1d ago
>I often wonder why Microsoft doesn’t go full-apple on its hardware and software.
I think they are tried with secure boot, but pushback from Linux people and maybe fear of anti-trust stopped them (for now).
And maybe if they do this, hardware vendors may fear a market split where they loose Linux people to other vendors.
Not that many people but it still is revenue loss. I know I will never ever bye a microsoft only device. Bad enough Smart phones are locked down, at least I can ignore the phone.
johncolanduoni · 1d ago
I’ve never understood the fascination with perceiving Secure Boot as ushering in an age of tech serfdom. From almost the beginning, they signed Red Hat’s boot shim which made it totally useless for locking people to Windows. I don’t think this was ever the plan, and the motivations aren’t there unless you buy all that stuff about every huge tech company hating “universal computers” on principle. Linux is not a measurable thorn in Microsoft’s side on the desktop market, and they don’t have nearly enough leverage to make OEMs stop selling Linux servers.
jmclnx · 14h ago
Because IBM/RHEL pays Microsoft for the key (shim). Plus with Linus/BSD, once boot starts their own microcode is loaded.
Secure boot as far as Linux is concerned is extortion from the users.
mrkramer · 20h ago
Gates is opening gates of hell.
_Algernon_ · 1d ago
Such a forward thinking concept. Wonder when every other OS will follow in their footsteps. Oh wait.
mihaaly · 1d ago
The Çulture of Unfinished Software gets more and more mainstream, with OS level infrastructure and inflated buzzwords' department.
Meanwhile, any chance finishing OneDrive file renaming to work without issues finally? Is there an 'update' pending about that? Just a random thing I come accross daily, among the dozens others slowing my work and distracts me on proudly presented OS level.
... or perhaps when I say 'Update and shut down', then actually shutting down in the end instead of restarting and spinning the fans the whole night (me believing the poor thing was shut down as prom... suggested)?
There's a better way, which I am shamelessly self-promoting in this thread (as it's 100% on topic) - my company makes a tool that can ship self-updating Electron apps and beyond being not abandoned, it's got a lot of really useful features, like being able to do the build and upload of signed updating packages (using the tech MS is pushing here) from Linux CI workers, without needing a Windows license.
https://hydraulic.dev/
It can also do forced updates on launch, which can be helpful for apps where the protocol between client and server changes regularly. And it plays well with corporate Windows deployments. People can install apps locally without needing administrator access but it goes into c:\Program Files
They did not even use Windows update for that one.
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.
Most of the time there isn't one.
Where do you draw the line at removal, configuration files, user created documents, config files on networked home directories.
I dont think you are being unreasonable, maybe we need better clean up depending on what the user needs..
It would mean tracking the creator of filws and tagging them appropriately, using this list during uninstall.
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.
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`.
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.
- 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...
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.
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.
But I agree that it could be so much better.
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.
I am surprised that something like sparkle hasn’t found footing on Windows.
[1] https://github.com/mas-cli/mas
Classic Macintosh systems did not have a user-facing command line at all.
WinUI3 (if anyone ever bothers to use it, including Microsoft) already distributes its library dependency this way, as a store package.
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.
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.)
[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.
It's really interesting to compare MSI to MSIX which is ZIP/XML instead of CAB/weird JET DB file.
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.
That said, I also hate Windows updates, and especially the way Windows handles them. LTSC is also my way to avoid some of it, especially the ""feature"" updates. LTSC is something I also recommend, if people can manage an activation server, or I can point them to mine.
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.
The winget repo has a ton of useful installation manifests, sure, but isn't "just" a tool to fetch manifests from that one repo. (Also, it doesn't fetch the data directly from GitHub, even though that is the source of truth, it has a light REST service in between which does a lot of caching and DDoS management and what have you.) Winget also by default installs Windows Store apps, too. It's also configurable so you can add your own installation manifest repos if you wish (such as on-premise private feeds).
Back in my day this would be seen as an exercise left for the user, and thus a new junior dev was born building a front end.
UniGetUI looks really cool.
https://github.com/marticliment/UniGetUI - 16.2k stars
I find that behavior incredibly annoying. I mainly use Chocolatey, so every once in a while when a package is heavily outdated or missing from the repo I end up using Winget instead for convenience's sake. That means Winget keeps trying to update or manage Chocolatey packages, and as far as I know, there's no easy way to stop that.
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.
How so? I’ve been using it for years and haven’t had a problem yet updating all applications at once.
Things can get tricky with applications that are installed with WinGet but come with mechanisms to update themselves. If this self-update skips adjusting the right knobs and values in the registry, WinGet will assume that the application is still on the initial version.
For example, this is the case with Obsidian.
https://news.ycombinator.com/item?id=23331287
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.
[1] https://github.com/marticliment/UniGetUI
> 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
Not sure why this was flagged, but shame on whoever did it.
> Microsoft’s Windows Package Manager has also tried to solve some of the problems with installing and updating apps on Windows
Nth time is the charm?
> but it’s not a widely used way to install and manage apps outside of power users and developers.
Nth time of ignoring what's there and instead building another system.
I think it is actually a good move for them to embrace supporting updates for all the non Windows Store stuff in a first party way. There is just way too much software that will never be a Windows Store application. Besides that, more trustworthy checks for malware etc. are included in such a first-party system than in what was already there, simply by having more available infrastructure. It also increases the chances that they can convince developers to move to using install/update libraries that play nice with this official package management tool.
At this point in time, I would definitely advise everybody to start out installing most Windows stuff via winget or if it isn't listed there via Chocolatey.
[0] https://en.wikipedia.org/wiki/Windows_Package_Manager#Histor...
MSIX is an interesting beast. My company sells a tool called Conveyor [1] that can create these packages from any platform including macOS and Linux given a simple config file for apps using runtimes like Electron, Flutter or the JVM (it's free for open source projects). We do a lot of work to make MSIX work better and be easier to use, because out of the box it's quite raw and in particular there are a lot of bugs in Windows 10 that Microsoft never fix because they view it as EOL. Conveyor creates a tiny 500kb installer EXE that drives the MSIX package manager API to do the install whilst working around these bugs.
Amongst other things, MSIX gives you:
• Chrome-style silent background updates on a regular schedule, even if the app isn't running.
• Incremental block-based delta updates.
• Incremental block-based downloads and installs, i.e. Windows can re-use parts of one app to install another, based on file block hashes. Makes installs very fast when they share a common runtime!
• And those installs/updates can pull blocks from other machines on the LAN too!
• Declarative installs and OS-controlled uninstalls. Writes to the user's AppData directory are virtualized, so uninstalls can be clean.
• Packages can be installed without admin rights, without dumping stuff in the user's home directory. Windows runs an elevated service that does the install for you.
• You can sandbox apps if they're shipped with MSIX.
• EXEs can be automatically added to the user's path, without needing any terminals or shells to be restarted. MacOS can't do that!
• Windows admins can easily deploy and manage them.
• They're cryptographically signed and their integrity is protected by the OS, so malware can't fiddle with the binaries (unless it manages to elevate to root).
• Although you can't create them with a regular zip tool, you can extract them with one.
Conveyor adds some other features on top like the ability to have web-style "update immediately on launch" updates, and a simple Electron/JVM control API so you can force updates on users.
It's a pretty nice feature set overall and has some big advantages over Squirrel, which is what Electron uses. However, I would definitely NOT recommend you try and work with MSIX directly. Microsoft's tooling is quite awkward, and their policy of only supporting fully up to date Win11 machines - and only from Windows - means you can't realistically distribute apps using MSIX unless you go via an intermediary like Conveyor that's committed to making it work. You'll just hit lots of weird bugs and installs that fail for no obvious reason with mysterious error codes. We ploughed through the pain so you don't have to.
[1] https://hydraulic.dev/
Microsoft isn't going to test any of the updates themselves before it sends them through the central update feature
For home use, I can see this being good as a large segment of users don't stay up to date on security patches, but what about breaking workflows in businesses?
Some businesses deliberately do not upgrade some software packages, because it would break stuff. It makes sense to just push all updates in a subscription based economy, but this could also quickly become exactly that: A subscription hell-hole where companies push updates and now you're old licensed copy of Photoshop is converted to Creative Cloud.
The idea isn't bad, I just don't trust modern software companies to be able to manage this in a way which makes customers happy.
You only get windows laptops and desktop from Microsoft, but they are highly secure (similar to what apple achieves).
Everything else needs a windows pro license (with tight checks).
I’m fairly sure that would improve windows’ security posture by a huge lot.
They make the majority of their money from businesses with lucrative support contracts, Azure, Active Directory + Office Enterprise suite, etc.
They make the majority of their money from consumers via stuffing Windows with "promotions" (ads) and from Office 365. It is services. Windows barely earns them anything.
Hell, the fact that they're thinking about opening up the Xbox to Steam and have official tutorials on running Gamepass on iOS and Linux should tell you that they don't care what OS on which device you use, so long as you are subscribed to their services.
In an environment like that, a vertical integration play makes little sense. You want your services to be on as many platforms as possible, not attract ire and roadblocks from your partners.
On top of that, they don't have a phone platform onboarding people to the whole hardware ecosystem. Even for Apple, Mac + iPad + AirPod profits are dwarfed by iPhone profits.
If they want to compete with Apple using Apple’s strategy, they may face a losing battle.
What package handler ? Installing things on macOS is still a mixed bag of disk images with the app to move yourself, or .pkg files or the App Store.
The thing is so broken that brew is the first thing I install on a new Mac.
they're probably referring to homebrew. which quite honestly, makes MacOS barely bearable. The terminology sucks and the ruby language doesn't help. MacOS without homebrew is unbearable.
Microsoft backwards compatibility got them massive market share but also backed them into a corner. Package Managers only work if there is some constrants but I came across software that was dropping .ini files into C:\Windows\System32 in 2017.
Besides, the antitrust regulators would absolutely hate this.
To be honest, I kind of understand they don't want to do that. I bought a Surface Pro 8 some years ago and is probably the worst computing hardware I've experienced in a long time. Even basic things like thermal management is horribly broken when using Windows on it. Running Linux on it gave a slightly better experience, but seems so backwards that they cannot even make their own hardware work well, I thought the combination of hardware+OS by same company would lead to a better experience but nope.
During covid and the supply/demand mismatch as everyone rushed to WFH I was wondering if they could repurpose the cheap S xboxes as cheap desktops. Essentially a reversal of the original 'xbox as a trojan horse' idea, instead of using consoles to get windows in the living room, it's to get windows in the home office.
One of the reasons they're still much more prevalent than Apple is because they don't.
No one seems to care, I expect the AI PCs to eventually sell for 75% discounts.
I think they are tried with secure boot, but pushback from Linux people and maybe fear of anti-trust stopped them (for now).
And maybe if they do this, hardware vendors may fear a market split where they loose Linux people to other vendors. Not that many people but it still is revenue loss. I know I will never ever bye a microsoft only device. Bad enough Smart phones are locked down, at least I can ignore the phone.
Secure boot as far as Linux is concerned is extortion from the users.
Meanwhile, any chance finishing OneDrive file renaming to work without issues finally? Is there an 'update' pending about that? Just a random thing I come accross daily, among the dozens others slowing my work and distracts me on proudly presented OS level.
... or perhaps when I say 'Update and shut down', then actually shutting down in the end instead of restarting and spinning the fans the whole night (me believing the poor thing was shut down as prom... suggested)?