22 ms·

Why do Windows programs need special installers/uninstallers? Why isn't this handled by Windows itself?

highwaylights 3y ago
I don't think any major desktop OS handles this well. I suspect the final form for software installation is probably where iOS and Android are going in the EU, where there's a single means of installing software to the device so that everything can be sandboxed properly, but the acquisition/update process can be pointed to a URL/Store that the user has pre-approved. macOS comes pretty close to what I'd ideally want in an OS with regards to installation - independent packages that are certified/notarised, but I'd like to see the OS allow for user-specified authorities beyond just Apple. That being said, I'm not sure I'd ever use them as it's part of what I'm paying Apple for, I'm really thinking more of Linux there. A kind of flatpak/snap approach, but that has signing of the package and centralised management of the permissions for the sandbox at an OS level would be ideal in my view. That way it's still free-as-in-speech as the user can specify which notarisation authority to use (or none at all). I really don't understand why seperate programs are handling removing their mother program in 2023, that's registry spaghetti messy.
- tobias3 3y ago
  You are basically describing what Windows has as appx/msix. The decentrialized notarization authorities are the code signing certificate providers.
  - highwaylights 3y ago
    I had not seen this, but it absolutely does (on the surface) seem like a solution to this problem. Thanks! I’d need to educate myself a bit more in terms of whether there are third-party authorities beyond Microsoft for the packages. Found this introductory video for anyone else interested: https://www.youtube.com/watch?v=phrD081sMWc https://www.youtube.com/watch?v=phrD081sMWc Note: I didn’t intend the Surface pun above, but it happened and we can all be glad that it did.
    - mike_hearn 3y ago
      Yes there are a few certificate authorities. For example DigiCert, SSL.com and others. You can also create your own e.g. for enterprise deployments. Or you could even set up a public CA if you wanted to, the process is standardized. So whilst Microsoft will sign for you if you distribute via their store, otherwise you pay per year for certificates and can distribute outside the store. There are problems with the system (cost, bugs, usability problems) but it is decentralized.
- mschuster91 3y ago
  > macOS comes pretty close to what I'd ideally want in an OS with regards to installation - independent packages that are certified/notarised, but I'd like to see the OS allow for user-specified authorities beyond just Apple. It's easy to run unsigned binaries/app packages on macOS: right click on the .app, hold down Option, then click Open and confirm the warning.
  - tmpX7dMeXU 3y ago
    That is not a user-specified authority.
    - TheNewsIsHere 3y ago
      I would also like this option. I see why Apple finds it undesirable though. Software installation safeguards are a game of whack-a-mole with (e.g.) support scammers who ask grandma/Lee-in-accounting/Cindy-next-door to naively click through all the warnings. The closest Apple comes to this capability is achieved via device Supervision and MDM, which might be comfortable for some of us here in this forum but obviously isn’t practical beyond more technical circles. Baddies keep ruining all the fun for the rest of us.
      - cm2187 3y ago
        And being the only authority also happens to be conveniently aligned to their financial incentives.
      - mschuster91 3y ago
        > Baddies keep ruining all the fun for the rest of us. IMHO the blame rather lies with our politicians who are unwilling to take the steps necessary to cut the baddies off from the Internet. Let's see just how fast India, Pakistan, Turkey and other scammer hotspots clean up their act when the US+EU threaten to cut them off from the Internet and SS7 unless the scam callcenters are closed down for good... the amount of corruption regularly exposed by scambaiters on Youtube is insane. Billions of dollars of damages each year [1] from that bullshit and our politicians don't. fucking. care. [1] https://www.vibesofindia.com/fraudsters-in-india-cost-americans-almost-10-billion-in-2022/ https://www.vibesofindia.com/fraudsters-in-india-cost-americ...
- irusensei 3y ago
  Everyone is pointing at Windows but there are still installer software on MacOS. Normally crusty old corpoware like Citrix that needs to extend its tentacles to the whole system. On Unix/Linux land the prevalence of pipe curl to bash type installers is not much different. I normally keep both types away from my computers.
  - jjgreen 3y ago
    On Unix/Linux land the prevalence of pipe curl to bash type installers is not much different. True, but saying so will likely to earn you downvotes from those committed to this unhygenic practice ...
  - bombolo 3y ago
    [dead]
  - madeofpalk 3y ago
    Only installers I’ve seen are the .installer bundles, which leave behind a manifest for automated uninstalling.
  - Matl 3y ago
    > On Unix/Linux land the prevalence of pipe curl to bash type installers is not much different. This is a problem but only if you install software on Linux by manually going to the project page and copy-pasting whatever curl they have there, I think the difference is that mostly you're encouraged to go the package manager route, whereas on windows downloading .exes directly (ala the curl example) is the norm.
    - jjgreen 3y ago
      Actually no, the problem with curl | bash is that it can be detected on the server, so if the server is compromised, it can serve you malware and you will never know about it. It is safe(r) to curl > file, inspect the file, then execute it under bash.
      - 3y ago
- alerighi 3y ago
  > I suspect the final form for software installation is probably where iOS and Android are going in the EU, where there's a single means of installing software to the device so that everything can be sandboxed properly, but the acquisition/update process can be pointed to a URL/Store that the user has pre-approved. Basically how Linux distributions works since the beginning. Tough at the start the installation source was not remote but a CD-ROM things didn't change. You have a repository of packages (that can be on a local source as a CD or remote source such as an HTTP/FTP server), that have some sort of signature (on Linux usually the pagkage is signed with GPG) with some keys that the user trusts (and the default are installed on the system), and a software that allows to install, uninstall and update the packages. Android/iOS arrived later, but they didn't invent anything.
  - efreak 3y ago
    Android/iOS didn't invent this, no, however you're missing the sandbox part. Most Linux package managers don't sandbox anything.
- brap 3y ago
  iOS is the gold standard IMO. Apps are sandboxed, can only interact with the outside world via APIs (that the user needs to approve), one click uninstall and it’s all gone without a trace (at least in theory). Love it.
  - fomine3 3y ago
    I think Android does it better with third party store and sideload support. It seems that iOS depends some security to their own the AppStore. (example: disallow dynamic code generation like JIT)
tetris11 3y ago
One thing I like about Linux package managers is that you can query any file to see which package owns it. How does Windows not track this?
- blackpill0w 3y ago
  Ok, I see what you're saying here, still, Linux's way is better, I'd rather have my system cluttered with useless files of deleted programs than be exploited because of something that was solved decades ago.
- yankput 3y ago
  Except they all leave files everywhere in ~, ~/.cache, ~/.config, ~/.whatevertheyfeellike
  - parchley 3y ago
    Those files are user data, not part of the software package.
    - daemin 3y ago
      I would disagree, files that the user cannot edit or should not edit should not be going into their home directory. Things like cache files should go into a system wide cache directory instead.
      - amenghra 3y ago
        Cache files might contain user's sensitive data. Makes sense to keep in them in the user's home directory in those cases.
        Hikikomori 3y ago
        File permissions?
deleted 3y ago
[deleted]
mike_hearn 3y ago
It is, these days. Windows 10 onwards has a native package format called MSIX that somewhat resembles packages on Linux. They're special zips containing an XML file that declares how the software should be integrated into the OS (start menu, commands on the PATH, file associations etc). Windows takes care of installation, update and uninstallation. The system is great, in theory. In practice adoption has been held back by the fact that it was originally only for UWP apps which almost nobody writes, and also only for the MS Store. These days you can use it for Win32 apps outside the store but then you will hit bugs in Windows. And packages must be signed. Still, the feature set is pretty great if you can make it work. For example you can get Chrome-style updates where Windows will keep the app fresh in the background even if it's not running. And it will share files on disk between apps if they're the same, avoid downloading them, do delta updates and more. It also tracks all the files your app writes to disk outside of the user's home directory so they can be cleanly uninstalled, without needing any custom uninstaller logic. One interesting aspect of the format is that because it's a "special" (read: weird) kind of zip, you can make them on non-Windows platforms. Not using any normal zip tool of course, oh no, that would be too easy. You can only extract them using normal zip tools. But if you write your own zip library you can create them. A couple of years ago I sat down to write a tool that would let anyone ship apps to Win/Mac/Linux in one command from whatever OS they liked, no harder than copying a website to a server. I learned about MSIX and decided to make this package format. It took us a while to work around all the weird bugs in Windows that only show up on some machines and not others for no explicable reason, but it's stable now and it works pretty well. For example you can take some HTML and JS files, write a 5 line config file pointing at those files, run one command and now you have a download page pointing to fully signed (or self signed) self-updating Windows, Mac and Linux Electron app. Or a JVM app. Or a Flutter app. Or any kind of app, really! Also IT departments love it because, well, it's a real package format and not an installer. Writing more about this tech has been on my todo list for a while, but I have now published something about the delta update scheme it uses which is based on block maps, it's somewhat unusual (a bit Flatpak like): https://hydraulic.dev/blog/20-deltas-diffed.html https://hydraulic.dev/blog/20-deltas-diffed.html The tool is free to download, and free for open source projects if anyone is wanting to ship stuff to Windows without installers: https://conveyor.hydraulic.dev/ https://conveyor.hydraulic.dev/
- 3y ago
daemin 3y ago
It allows you to install applications from any source, not only the official store. It allows for a variety of installers to exist with different features for different use cases. It allows you to install the application in any location you choose. It allows for portable installations and to run software just copied from other sources.
- damentz 3y ago
  What is "it"?
  - remram 3y ago
    I guess "special installers/uninstallers"
  - daemin 3y ago
    Special installers / uninstallers and also the ability to install and run things outside the official OS store.
    - j16sdiz 3y ago
      Many program can run as standalone .exe, or just unzip as a folder. All the points you list does not need _Special_ installers / uninstaller.
      - daemin 3y ago
        Yes, that is what I mean by my last point: "It allows for portable installations and to run software just copied from other sources." You can think of decompressing from an archive as running a very simple installation program. If the only installer available was one provided by the OS how long do you think it would take to make that the only way to install and run software. These things are being done right now on many platforms in the name of safety, security, and to a lesser extent convenience. The more phone-like a platform is the fewer ways you have to install and run software on it. So far general purpose computers still allow you to install software in other ways than the built-in method (i.e. just unzip and place in a directory), but it's getting increasingly common to require executables be signed, and things are always moving to be more and more locked down. Now the use of "Special" installers/uninstallers is from the original comment, I would just refer to them as "regular" installers/uninstallers. I do like the ability and freedom to have an ecosystem of these things, as I don't want the one OS method to be the only way to install applications.
BoppreH 3y ago
How could Windows handle it by itself? If it provides a framework for installers/uninstallers, it'll be fighting the inertia of decades of legacy software, programmer habits, and old tutorials. If it tracks file ownership by program, it might accidentally delete user files. How would it differentiate between a VSCode extension that should be uninstalled, and a binary compiled with VSCode for a user project? A false positive could be catastrophic. If it restricts what programs can do to accurately track file ownership, you end up with Android. Which is fantastic for security, but is a royal pain in the ass for all parties: - The app developers have to jump through hoops for the simplest actions, and rewrite most of their code in the new style. - The operating system has to implement a ton of scaffolding, like permissions-restricted file pickers and ways to hand off "intents" between applications. - The user is faced with confusing dialogs, and software with seemingly arbitrary limitations. In the age of shared runtimes, auto-updaters, extension marketplaces, and JIT compilers, managing installed applications is harder than ever. Edit: the answer above applies only to Windows, because of its baggage. Linux'es are in a much better position, for example, though their solution is still not perfect.
- Tuna-Fish 3y ago
  The same way any linux distro does? Define a separate directory for program installations, that user processes cannot write to. Only program that can do so is the package manager, which other programs can call to install packages. Uninstall removes everything related to a program from this directory. > In the age of shared runtimes, auto-updaters, extension marketplaces, and JIT compilers, managing installed applications is harder than ever. The only reason these make things hard is that windows lacks any facility to deal with them. Solutions going forward: Outright ban having your own auto-updater, to auto-update you register your program and where to update it from with the package manager. Shared runtimes are trivial for package managers to handle, it's just a package that many other ones depend on. Extensions can be handled as packages.
  - BoppreH 3y ago
    That was the first option, "provides a framework for installers/uninstallers". But what would you do with the millions of existing programs, most unmaintained? And what about programs with strong opinions on update schedules, or built-in extension marketplaces? It's easy to solve this problem if your first step is "replace every program".
EvanAnderson 3y ago
Windows has had an installer as an OS component since the late 90s (called Windows Installer). As a sysadmin I'd prefer apps use it. Many application developers do not. It's maddening. (Doubly so when Microsoft themselves don't use it-- newer versions of Office, Teams, etc. Microsoft suffers from too much NIH.) I get unattended installs and uninstalls "for free" when well-behaved applications use Windows Installer. Patching is included, too. Customizing installations is fairly straightforward. On the developer side it has historically used a very quirky proprietary file format (MSI) with a fairly steep learning curve and a ton of "tribal knowledge" required to make it work for all but the most trivial cases. (Though, to be fair, most installs are the trivial case-- copy some files, throw some stuff into the registry, make some shortcuts.) Worse, it allows for arbitrary code execution ("Custom Actions"), at which point all bets are off re: unattended installs, removal, etc. Some Windows Installer packages are just "wrapped" EXEs (Google Chrome, for example). I've packaged a ton of 3rd party software as Windows Installer packages. It's an ugly system with lots of warts and legacy crap, but if you need to load an application on a large number of Windows PCs reliably unattended it's decently fit for purpose. There is reasonable free and libre tooling to generate MSI packages from plain text source (the WiX toolkit) and it can be used in a CI pipeline.
- mariusmg 3y ago
  > with a fairly steep learning curve and a ton of "tribal knowledge" Yes, people preffer to debug their own code rather than spend shitload of time to understand Wix/MSI. Microsoft deciding early on to not produce low cost tools for Windows Installer also didn't helped with the adoption.
  - delfinom 3y ago
    The joke is, Microsoft devs even now use NSIS for things like VSCode rather than deal with MSIs lol But there is the modern implementation of AppX Bundles which was later extended to create MSIX which allows app distribution without the windows store. There are still drawbacks to using MSIX usually because you want to touch Windows in ways you can't inside the sandbox.
NotYourLawyer 3y ago
When the subject is Windows, and the question includes a “why,” the answer is always “for historical reasons.”
gwbas1c 3y ago
> Why do Windows programs need special installers/uninstallers? This is supposed to happen using MSI-based installers. It's a windows component. > Why isn't this handled by Windows itself? Now, here's where things get tricky. In the article, the issue is an explorer plugin. MSI is notoriously buggy with installing and uninstalling explorer plugins. If you don't jump through hoops, your installer will have a bug where it prompts the user to close Explorer.exe. I know because I shipped a product with an explorer plugin. The installer was always a thorn in our side; and the workarounds, ect, that we had to do to install / uninstall / delete our plugin were more complicated than the plugin itself.
GuB-42 3y ago
Besides the "special uninstaller" thing. One of the things I hate the most with Windows filesystem management compared to Unix-like OSes. On Windows, opening a file locks it. So you can't delete a program that is running, you will get an error. It means of course that an executable can't delete itself without resorting to ugly tricks like the one mentioned in the article. That's also why you get all these annoying "in use" popups. On Unix, files (more precisely: directory entries) are just reference-counted pointers to the actual data (inode on Linux), removing a file is never a problem: remove the pointer, decrement the reference counter. If the file wasn't in use or referenced from elsewhere, the counter will go to zero and the actual data will be deleted. If the file is in use, for example because it is an executable that is running, the file will disappear from the directory, but the data will only be deleted when it stops being in use, in this case, when the executable process terminates. So you can write your uninstaller in the most straightforward way possible and it will do as expected.
- EustassKid 3y ago
  I feel like this is some stupid question but aren't exexutables and their libraries loaded to RAM? If yes then why can't it just delete itself (from disk)?
  - GuB-42 3y ago
    I don't know the details but I think executable files are mapped into memory, and needed sections are loaded on demand. In case the system is low on RAM, little used sections can be evicted, to be reloaded the next time they are needed. This requires the file to be present on disk.
tsukikage 3y ago
It's hardly specific to Windows. All the major Linux distros have excellent package management systems, and yet many, many packages and applications choose to ignore these in favour of party solutions, scripts, or even curl https://not-malware.trustme.lol https://not-malware.trustme.lol | sudo bash style hodgepodge.

I don't think any major desktop OS handles this well. I suspect the final form for software installation is probably where iOS and Android are going in the EU, where there's a single means of installing software to the device so that everything can be sandboxed properly, but the acquisition/update process can be pointed to a URL/Store that the user has pre-approved. macOS comes pretty close to what I'd ideally want in an OS with regards to installation - independent packages that are certified/notarised, but I'd like to see the OS allow for user-specified authorities beyond just Apple. That being said, I'm not sure I'd ever use them as it's part of what I'm paying Apple for, I'm really thinking more of Linux there. A kind of flatpak/snap approach, but that has signing of the package and centralised management of the permissions for the sandbox at an OS level would be ideal in my view. That way it's still free-as-in-speech as the user can specify which notarisation authority to use (or none at all). I really don't understand why seperate programs are handling removing their mother program in 2023, that's registry spaghetti messy.

tobias3 3y ago
You are basically describing what Windows has as appx/msix. The decentrialized notarization authorities are the code signing certificate providers.
- highwaylights 3y ago
  I had not seen this, but it absolutely does (on the surface) seem like a solution to this problem. Thanks! I’d need to educate myself a bit more in terms of whether there are third-party authorities beyond Microsoft for the packages. Found this introductory video for anyone else interested: https://www.youtube.com/watch?v=phrD081sMWc https://www.youtube.com/watch?v=phrD081sMWc Note: I didn’t intend the Surface pun above, but it happened and we can all be glad that it did.
  - mike_hearn 3y ago
    Yes there are a few certificate authorities. For example DigiCert, SSL.com and others. You can also create your own e.g. for enterprise deployments. Or you could even set up a public CA if you wanted to, the process is standardized. So whilst Microsoft will sign for you if you distribute via their store, otherwise you pay per year for certificates and can distribute outside the store. There are problems with the system (cost, bugs, usability problems) but it is decentralized.
mschuster91 3y ago
> macOS comes pretty close to what I'd ideally want in an OS with regards to installation - independent packages that are certified/notarised, but I'd like to see the OS allow for user-specified authorities beyond just Apple. It's easy to run unsigned binaries/app packages on macOS: right click on the .app, hold down Option, then click Open and confirm the warning.
- tmpX7dMeXU 3y ago
  That is not a user-specified authority.
  - TheNewsIsHere 3y ago
    I would also like this option. I see why Apple finds it undesirable though. Software installation safeguards are a game of whack-a-mole with (e.g.) support scammers who ask grandma/Lee-in-accounting/Cindy-next-door to naively click through all the warnings. The closest Apple comes to this capability is achieved via device Supervision and MDM, which might be comfortable for some of us here in this forum but obviously isn’t practical beyond more technical circles. Baddies keep ruining all the fun for the rest of us.
    - cm2187 3y ago
      And being the only authority also happens to be conveniently aligned to their financial incentives.
    - mschuster91 3y ago
      > Baddies keep ruining all the fun for the rest of us. IMHO the blame rather lies with our politicians who are unwilling to take the steps necessary to cut the baddies off from the Internet. Let's see just how fast India, Pakistan, Turkey and other scammer hotspots clean up their act when the US+EU threaten to cut them off from the Internet and SS7 unless the scam callcenters are closed down for good... the amount of corruption regularly exposed by scambaiters on Youtube is insane. Billions of dollars of damages each year [1] from that bullshit and our politicians don't. fucking. care. [1] https://www.vibesofindia.com/fraudsters-in-india-cost-americans-almost-10-billion-in-2022/ https://www.vibesofindia.com/fraudsters-in-india-cost-americ...
irusensei 3y ago
Everyone is pointing at Windows but there are still installer software on MacOS. Normally crusty old corpoware like Citrix that needs to extend its tentacles to the whole system. On Unix/Linux land the prevalence of pipe curl to bash type installers is not much different. I normally keep both types away from my computers.
- jjgreen 3y ago
  On Unix/Linux land the prevalence of pipe curl to bash type installers is not much different. True, but saying so will likely to earn you downvotes from those committed to this unhygenic practice ...
- bombolo 3y ago
  [dead]
- madeofpalk 3y ago
  Only installers I’ve seen are the .installer bundles, which leave behind a manifest for automated uninstalling.
- Matl 3y ago
  > On Unix/Linux land the prevalence of pipe curl to bash type installers is not much different. This is a problem but only if you install software on Linux by manually going to the project page and copy-pasting whatever curl they have there, I think the difference is that mostly you're encouraged to go the package manager route, whereas on windows downloading .exes directly (ala the curl example) is the norm.
  - jjgreen 3y ago
    Actually no, the problem with curl | bash is that it can be detected on the server, so if the server is compromised, it can serve you malware and you will never know about it. It is safe(r) to curl > file, inspect the file, then execute it under bash.
    - 3y ago
alerighi 3y ago
> I suspect the final form for software installation is probably where iOS and Android are going in the EU, where there's a single means of installing software to the device so that everything can be sandboxed properly, but the acquisition/update process can be pointed to a URL/Store that the user has pre-approved. Basically how Linux distributions works since the beginning. Tough at the start the installation source was not remote but a CD-ROM things didn't change. You have a repository of packages (that can be on a local source as a CD or remote source such as an HTTP/FTP server), that have some sort of signature (on Linux usually the pagkage is signed with GPG) with some keys that the user trusts (and the default are installed on the system), and a software that allows to install, uninstall and update the packages. Android/iOS arrived later, but they didn't invent anything.
- efreak 3y ago
  Android/iOS didn't invent this, no, however you're missing the sandbox part. Most Linux package managers don't sandbox anything.
brap 3y ago
iOS is the gold standard IMO. Apps are sandboxed, can only interact with the outside world via APIs (that the user needs to approve), one click uninstall and it’s all gone without a trace (at least in theory). Love it.
- fomine3 3y ago
  I think Android does it better with third party store and sideload support. It seems that iOS depends some security to their own the AppStore. (example: disallow dynamic code generation like JIT)

tetris11 3y ago

One thing I like about Linux package managers is that you can query any file to see which package owns it. How does Windows not track this?

blackpill0w 3y ago
Ok, I see what you're saying here, still, Linux's way is better, I'd rather have my system cluttered with useless files of deleted programs than be exploited because of something that was solved decades ago.
yankput 3y ago
Except they all leave files everywhere in ~, ~/.cache, ~/.config, ~/.whatevertheyfeellike
- parchley 3y ago
  Those files are user data, not part of the software package.
  - daemin 3y ago
    I would disagree, files that the user cannot edit or should not edit should not be going into their home directory. Things like cache files should go into a system wide cache directory instead.
    - amenghra 3y ago
      Cache files might contain user's sensitive data. Makes sense to keep in them in the user's home directory in those cases.
      - Hikikomori 3y ago
        File permissions?

deleted 3y ago

[deleted]

mike_hearn 3y ago

It is, these days. Windows 10 onwards has a native package format called MSIX that somewhat resembles packages on Linux. They're special zips containing an XML file that declares how the software should be integrated into the OS (start menu, commands on the PATH, file associations etc). Windows takes care of installation, update and uninstallation. The system is great, in theory. In practice adoption has been held back by the fact that it was originally only for UWP apps which almost nobody writes, and also only for the MS Store. These days you can use it for Win32 apps outside the store but then you will hit bugs in Windows. And packages must be signed. Still, the feature set is pretty great if you can make it work. For example you can get Chrome-style updates where Windows will keep the app fresh in the background even if it's not running. And it will share files on disk between apps if they're the same, avoid downloading them, do delta updates and more. It also tracks all the files your app writes to disk outside of the user's home directory so they can be cleanly uninstalled, without needing any custom uninstaller logic. One interesting aspect of the format is that because it's a "special" (read: weird) kind of zip, you can make them on non-Windows platforms. Not using any normal zip tool of course, oh no, that would be too easy. You can only extract them using normal zip tools. But if you write your own zip library you can create them. A couple of years ago I sat down to write a tool that would let anyone ship apps to Win/Mac/Linux in one command from whatever OS they liked, no harder than copying a website to a server. I learned about MSIX and decided to make this package format. It took us a while to work around all the weird bugs in Windows that only show up on some machines and not others for no explicable reason, but it's stable now and it works pretty well. For example you can take some HTML and JS files, write a 5 line config file pointing at those files, run one command and now you have a download page pointing to fully signed (or self signed) self-updating Windows, Mac and Linux Electron app. Or a JVM app. Or a Flutter app. Or any kind of app, really! Also IT departments love it because, well, it's a real package format and not an installer. Writing more about this tech has been on my todo list for a while, but I have now published something about the delta update scheme it uses which is based on block maps, it's somewhat unusual (a bit Flatpak like): https://hydraulic.dev/blog/20-deltas-diffed.html https://hydraulic.dev/blog/20-deltas-diffed.html The tool is free to download, and free for open source projects if anyone is wanting to ship stuff to Windows without installers: https://conveyor.hydraulic.dev/ https://conveyor.hydraulic.dev/

3y ago

daemin 3y ago

It allows you to install applications from any source, not only the official store. It allows for a variety of installers to exist with different features for different use cases. It allows you to install the application in any location you choose. It allows for portable installations and to run software just copied from other sources.

damentz 3y ago
What is "it"?
- remram 3y ago
  I guess "special installers/uninstallers"
- daemin 3y ago
  Special installers / uninstallers and also the ability to install and run things outside the official OS store.
  - j16sdiz 3y ago
    Many program can run as standalone .exe, or just unzip as a folder. All the points you list does not need _Special_ installers / uninstaller.
    - daemin 3y ago
      Yes, that is what I mean by my last point: "It allows for portable installations and to run software just copied from other sources." You can think of decompressing from an archive as running a very simple installation program. If the only installer available was one provided by the OS how long do you think it would take to make that the only way to install and run software. These things are being done right now on many platforms in the name of safety, security, and to a lesser extent convenience. The more phone-like a platform is the fewer ways you have to install and run software on it. So far general purpose computers still allow you to install software in other ways than the built-in method (i.e. just unzip and place in a directory), but it's getting increasingly common to require executables be signed, and things are always moving to be more and more locked down. Now the use of "Special" installers/uninstallers is from the original comment, I would just refer to them as "regular" installers/uninstallers. I do like the ability and freedom to have an ecosystem of these things, as I don't want the one OS method to be the only way to install applications.

BoppreH 3y ago

How could Windows handle it by itself? If it provides a framework for installers/uninstallers, it'll be fighting the inertia of decades of legacy software, programmer habits, and old tutorials. If it tracks file ownership by program, it might accidentally delete user files. How would it differentiate between a VSCode extension that should be uninstalled, and a binary compiled with VSCode for a user project? A false positive could be catastrophic. If it restricts what programs can do to accurately track file ownership, you end up with Android. Which is fantastic for security, but is a royal pain in the ass for all parties: - The app developers have to jump through hoops for the simplest actions, and rewrite most of their code in the new style. - The operating system has to implement a ton of scaffolding, like permissions-restricted file pickers and ways to hand off "intents" between applications. - The user is faced with confusing dialogs, and software with seemingly arbitrary limitations. In the age of shared runtimes, auto-updaters, extension marketplaces, and JIT compilers, managing installed applications is harder than ever. Edit: the answer above applies only to Windows, because of its baggage. Linux'es are in a much better position, for example, though their solution is still not perfect.

Tuna-Fish 3y ago
The same way any linux distro does? Define a separate directory for program installations, that user processes cannot write to. Only program that can do so is the package manager, which other programs can call to install packages. Uninstall removes everything related to a program from this directory. > In the age of shared runtimes, auto-updaters, extension marketplaces, and JIT compilers, managing installed applications is harder than ever. The only reason these make things hard is that windows lacks any facility to deal with them. Solutions going forward: Outright ban having your own auto-updater, to auto-update you register your program and where to update it from with the package manager. Shared runtimes are trivial for package managers to handle, it's just a package that many other ones depend on. Extensions can be handled as packages.
- BoppreH 3y ago
  That was the first option, "provides a framework for installers/uninstallers". But what would you do with the millions of existing programs, most unmaintained? And what about programs with strong opinions on update schedules, or built-in extension marketplaces? It's easy to solve this problem if your first step is "replace every program".

EvanAnderson 3y ago

Windows has had an installer as an OS component since the late 90s (called Windows Installer). As a sysadmin I'd prefer apps use it. Many application developers do not. It's maddening. (Doubly so when Microsoft themselves don't use it-- newer versions of Office, Teams, etc. Microsoft suffers from too much NIH.) I get unattended installs and uninstalls "for free" when well-behaved applications use Windows Installer. Patching is included, too. Customizing installations is fairly straightforward. On the developer side it has historically used a very quirky proprietary file format (MSI) with a fairly steep learning curve and a ton of "tribal knowledge" required to make it work for all but the most trivial cases. (Though, to be fair, most installs are the trivial case-- copy some files, throw some stuff into the registry, make some shortcuts.) Worse, it allows for arbitrary code execution ("Custom Actions"), at which point all bets are off re: unattended installs, removal, etc. Some Windows Installer packages are just "wrapped" EXEs (Google Chrome, for example). I've packaged a ton of 3rd party software as Windows Installer packages. It's an ugly system with lots of warts and legacy crap, but if you need to load an application on a large number of Windows PCs reliably unattended it's decently fit for purpose. There is reasonable free and libre tooling to generate MSI packages from plain text source (the WiX toolkit) and it can be used in a CI pipeline.

mariusmg 3y ago
> with a fairly steep learning curve and a ton of "tribal knowledge" Yes, people preffer to debug their own code rather than spend shitload of time to understand Wix/MSI. Microsoft deciding early on to not produce low cost tools for Windows Installer also didn't helped with the adoption.
- delfinom 3y ago
  The joke is, Microsoft devs even now use NSIS for things like VSCode rather than deal with MSIs lol But there is the modern implementation of AppX Bundles which was later extended to create MSIX which allows app distribution without the windows store. There are still drawbacks to using MSIX usually because you want to touch Windows in ways you can't inside the sandbox.

NotYourLawyer 3y ago

When the subject is Windows, and the question includes a “why,” the answer is always “for historical reasons.”

gwbas1c 3y ago

> Why do Windows programs need special installers/uninstallers? This is supposed to happen using MSI-based installers. It's a windows component. > Why isn't this handled by Windows itself? Now, here's where things get tricky. In the article, the issue is an explorer plugin. MSI is notoriously buggy with installing and uninstalling explorer plugins. If you don't jump through hoops, your installer will have a bug where it prompts the user to close Explorer.exe. I know because I shipped a product with an explorer plugin. The installer was always a thorn in our side; and the workarounds, ect, that we had to do to install / uninstall / delete our plugin were more complicated than the plugin itself.

GuB-42 3y ago

Besides the "special uninstaller" thing. One of the things I hate the most with Windows filesystem management compared to Unix-like OSes. On Windows, opening a file locks it. So you can't delete a program that is running, you will get an error. It means of course that an executable can't delete itself without resorting to ugly tricks like the one mentioned in the article. That's also why you get all these annoying "in use" popups. On Unix, files (more precisely: directory entries) are just reference-counted pointers to the actual data (inode on Linux), removing a file is never a problem: remove the pointer, decrement the reference counter. If the file wasn't in use or referenced from elsewhere, the counter will go to zero and the actual data will be deleted. If the file is in use, for example because it is an executable that is running, the file will disappear from the directory, but the data will only be deleted when it stops being in use, in this case, when the executable process terminates. So you can write your uninstaller in the most straightforward way possible and it will do as expected.

EustassKid 3y ago
I feel like this is some stupid question but aren't exexutables and their libraries loaded to RAM? If yes then why can't it just delete itself (from disk)?
- GuB-42 3y ago
  I don't know the details but I think executable files are mapped into memory, and needed sections are loaded on demand. In case the system is low on RAM, little used sections can be evicted, to be reloaded the next time they are needed. This requires the file to be present on disk.

tsukikage 3y ago

It's hardly specific to Windows. All the major Linux distros have excellent package management systems, and yet many, many packages and applications choose to ignore these in favour of party solutions, scripts, or even curl https://not-malware.trustme.lol https://not-malware.trustme.lol | sudo bash style hodgepodge.