Live data from Hacker News

Any sufficiently advanced uninstaller is indistinguishable from malware

devblogs.microsoft.com

311–320 of 556 posts

Re: Any sufficiently advanced uninstaller is indistinguishable from malware

#311

Earlier quoted context omitted.

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. P…

> 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.

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.

Re: Any sufficiently advanced uninstaller is indistinguishable from malware

#312
post #237

Earlier quoted context omitted.

PowerShell has weird restrictions where it'll refuse to run scripts unless they're signed and stuff.

If the sysadmin chooses to, otherwise PowerShell can be run arbitrarily

The key is that unsigned scripts are opt-in, not opt-out. Chen is not going to suggest a solution that requires all users of the software to configure their computer to be less secure.

Re: Any sufficiently advanced uninstaller is indistinguishable from malware

#313

The guys at MS are smart enough to decompile assembly but still not enough to have a proper inode-based filesystem where you can delete files that are in use.

NTFS was doing B-trees in the 90's far before btrfs was a twinkle in someone's eye; unless some other UNIX was doing it.

Re: Any sufficiently advanced uninstaller is indistinguishable from malware

#316

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

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. P…

I had a friend who worked for a company that specialized in Web browser bars and MSIs. In other words, they were a shop to put all kinds of malware into these things. It was a viable business model for a company of something like 50 people.

The whole story and ideas put into Windows installing programs are a stupid joke. It's designed by project managers who have no idea what they are doing and no imagination and is executed by the cheapest least motivated programmers from South Asia Microsoft can possibly find.

A lot of people who do useful stuff for Windows try to stay away from as much of Microsoft's stuff as possible, and integrate it as little as possible with anything else coming from the system because it's just maddening how horrible everything there is.

Re: Any sufficiently advanced uninstaller is indistinguishable from malware

#317

Earlier quoted context omitted.

It has little to do with the filesystem. Windows has OS level locks. In the case of a running executable, the mapped memory holds a lock on the exe file to prevent deleting it. This is intentional. If it didn't hold the lock then it would be possible to delete the exe file on modern versions of Windows. Edit: since there still seems to be confusion I'll try to be clearer. On NTFS you can delete an open file. This is…

[flagged]

There are some brilliant people at Microsoft. Maybe not in the product end of things, but there are very few brilliant product people anywhere ;)

Re: Any sufficiently advanced uninstaller is indistinguishable from malware

#318

Earlier quoted context omitted.

It has little to do with the filesystem. Windows has OS level locks. In the case of a running executable, the mapped memory holds a lock on the exe file to prevent deleting it. This is intentional. If it didn't hold the lock then it would be possible to delete the exe file on modern versions of Windows. Edit: since there still seems to be confusion I'll try to be clearer. On NTFS you can delete an open file. This is…

[flagged]

I see no reason not to allow this.

That's why people at Microsoft made those decision and not you. The most obvious reason would be to use the executable itself to back the memory which the comment you replied to already hinted at. Instead of loading the entire executable into memory on application start, you just create some memory mapping entry. As the code executes and accesses different parts of the executable, the page fault handler will load the required pages on demand. If you only access a small part of the executable, only a small part of the executable will ever be loaded into memory. If you run low on memory, you can just use the page frames holding the executable for other things, you can always load pages from the executable again if needed.

Re: Any sufficiently advanced uninstaller is indistinguishable from malware

#320

The guys at MS are smart enough to decompile assembly but still not enough to have a proper inode-based filesystem where you can delete files that are in use.

NTFS was doing B-trees in the 90's far before btrfs was a twinkle in someone's eye; unless some other UNIX was doing it.

NTFS was not an innovative file system. It has just used several innovations introduced earlier by HPFS.

The High-Performance File System, a.k.a. HPFS, has been included in OS/2 1.2, which was launched in November 1989.

HPFS was a very innovative file system (its chief architect was Gordon Letwin). It has introduced the Extended File Attributes. It had directories implemented with B+ trees, like IBM VSAM (introduced at some time between 1973 and 1978). It had long file names and Access-Control Lists, like the Multics FS (1965). It used cylinder groups like the Berkeley FFS (1983). It used file extents, like the SGI EFS (1988).

Among the UNIX file systems, the SGI XFS (1993, almost simultaneous with NTFS) has been the first which has added all the innovations introduced by HPFS.

Post reply on HN