Why do Windows programs need special installers/uninstallers? Why isn't this handled by Windows itself?
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.
Any sufficiently advanced uninstaller is indistinguishable from malware
211–220 of 556 posts
Re: Any sufficiently advanced uninstaller is indistinguishable from malware
#212Earlier quoted context omitted.
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?
Except they all leave files everywhere in ~, ~/.cache, ~/.config, ~/.whatevertheyfeellike
Personally I appreciate knowing where the config/cache for each application is. (Though it does annoy me when programs don't follow this as in your third example)
[0] https://specifications.freedesktop.org/basedir-spec/basedir-...
Re: Any sufficiently advanced uninstaller is indistinguishable from malware
#213Re: Any sufficiently advanced uninstaller is indistinguishable from malware
#214Earlier quoted context omitted.
And it's even funnier that the solution the author gives is "hey execute this javascript code that uninstalls a program and deletes itself afterwards" like, really? can't you write that in C? I don't think most Win32 apps use JavaScript for their installers.
> can't you write [a self-deleting executable] in C? The point of the exercise is that, on Windows, you can’t, because Windows won’t let anyone delete executables that are currently in use (try it, you won’t be able to delete one either). Upgrading shared DLLs in the face of this fact is why installers for Windows programs often have to have you reboot the system (and in more civilized times asked you to close other…
Re: Any sufficiently advanced uninstaller is indistinguishable from malware
#215Earlier quoted context omitted.
I'm yet to want to defrag my computer and worrying about still open deleted files. I face builds failing because I have a terminal open in a build output directory or a textfile in an editor open is far more often, and annoys me more. (or being unable to replace a running service binary of a service being developed/tested, needing to stop the service, replace it, and start again. Or failing log rotations because a lo…
I wasn't just talking about defragging. I was also talking about live volume shrinking. > Also see my link for a solution on unix, where you can indeed fix this problem Looping through every FD of every process just to find ones that reside in your volume of interest is... a hack. From the user's perspective, sure, it might work when you don't have something better. From the vendor's perspective, it's not the kind of…
And for the live volume shrinking: the kernel can solve this problem, it there is a need for this, there is no need for this invariant for this feature, as it is not only possible to do it via the same APIs offered for ordinary basic file manipulation gruntwork. On unix basically a filename is disassociated from the inode, but afaik the inode holding the blocklist still exists, will be cleaned up later, thus it can be updated if its blocks are moved under the high level filesystem APIs.
You just made a strawman you are sticking to.
Re: Any sufficiently advanced uninstaller is indistinguishable from malware
#216I keep forgetting Windows-isms that won't allow you to delete the executable file of a running process. I guess that's also why the arcane .dll upgrade process / WoW is so necessary.
>won't allow you to delete the executable file Any open file
Re: Any sufficiently advanced uninstaller is indistinguishable from malware
#217I’m probably missing something but why is an uninstaller allowed to inject code into explorer.exe? That seems like a massive security flaw?
It's never a security flaw that a program running with administrator privileges is allowed to do something.
From microsoft's documentation [1] > Administrator-to-kernel is not a security boundary.
I recommend the talk https://www.youtube.com/watch?v=Y09nAxZFKzc
[1] https://www.microsoft.com/en-us/msrc/windows-security-servic...
Re: Any sufficiently advanced uninstaller is indistinguishable from malware
#218Earlier quoted context omitted.
>but that was a clear user error A user error that can happen to any user who isn't Linux savvy and just wants to paly games, and not learn how a package manager works, and that it can uninstall your desktop environment if you aren't proficient with Linux, is no user error but OS error. How many MacOS or Windows users expect that going through the installation steps of Steam, it can uninstall your desktop environment…
There was a Steam package error, the error warned it might be temporary, the installer said it wouldn't continue because that would remove "popos-desktop" amongst other things. So, he opened a console (like any user?), then used apt-get ... which had a WARNING ... "This should NOT be done unless you know exactly what you are doing!". He then had to type "Yes, do as I say!" in order to "do something potentially harmfu…
It's 100% an OS UX error you're trying to spin into an user error.
Re: Any sufficiently advanced uninstaller is indistinguishable from malware
#219"Any installer that is distinguishable from malware is insufficiently advanced."
Re: Any sufficiently advanced uninstaller is indistinguishable from malware
#220The idiomatic way write an uninstaller 1. Clean up whatever you can in the uninstaller. If you're a decent human being this includes the registry, appdata, temp, and a toggle to delete wherever your app spews its config. The only thing left should be the uninstaller .exe and the directories leading up to it, since Windows doesn't allow you to unlink a exe/dll that's loaded in memory. Your uninstaller should be static…