Hacker News Reader

Comment by PreInternet01 | Hacker News Reader

I can only imagine the Win32 API team meeting prior to this...

A: So, people are resorting to injecting code in Explorer to delete in-use files in such numbers that it shows up in our top-100 crash report reasons

B: Well, maybe we should add a public API to Windows to support this incredibly common functionality that apparently has been missing so far?

A: Nah, let's just write a mildly condescending blog post that recommends using an unreliable workaround that is pretty much guaranteed to trigger any client-side intrusion detection software, that will set them straight

B: Right on!

(Meanwhile, somewhere, a third-party developer is gearing up to ship a kernel-mode driver to directly manipulate file system structures from their uninstaller, since their old solution kept crashing: can't wait to read the postmortem once the crash dumps from that one hit the Microsoft servers!)

View on HN

Raymond Chen writes great stuff but gives a very one-sided picture of compatibility -- he doesn't mention all of the times that it was the other way around, with Windows doing something lame and application authors having to work around it.

Like, for instance, the time that they decided that LaunchAdvancedAssociationUI(), the previous officially recommended way to show UI to allow the user to associate file types with a program, just wouldn't work anymore in Windows 10. Instead of opening up the Default Programs UI in Settings, it just displays a dialog telling the _user_ to go there -- which is even modal so they can't even refer to it while doing so. No compatibility shim or grandfathering for old programs, they just broke all applications that used this like they originally said good programs should do for Windows 8.

Or the case of Dark Mode in Windows, which for some reason they've dragged their heels on implementing barely any Win32 support at all for -- even just simply a call to query whether it is enabled. The current silly recommendation is to obtain the foreground color through WinRT and do a dot product on it to compute luma and determine if it is a dark or light color: https://learn.microsoft.com/en-us/windows/apps/desktop/moder...

Or the fact that the official way of reporting bugs on the Windows APIs is the Feedback Hub, which is completely unsuitable for task.

I don't have sympathy for the Windows team anymore. Their lack of developer support is partially responsible for all of the hacks that applications have to do to ship.

This. The deep dive is fascinating, but really feels like a distraction from a product management failure. Microsoft has been 3 decades in the OS business. Surely someone must have noticed that package management should be a core OS feature.

Oh, they have, many times! That’s why we have msi, app-v, appx etc.

At this point the Windows package manager omnimisery has metastasized and now idiot developers are insisting on writing their own installers even for platforms where it's totally un-necessary (harmful in fact!)

Please don't inflict more Microsoft package managers on us. All that needs fixing is there should be a supported way to delete "in-use" files just like you always could on Linux. People may make theoretical arguments about the virtues of locking files but the Linux behavior is so clearly the right thing in practice. Over the years I've encountered approximately zero problems with that behavior on Linux and dozens of problems with the Windows behavior, both as a user and as a developer.

I'm sure it would be hard to add such a thing to Windows while minimizing compatibility problems but I'm equally sure that it's possible and that it's worth the effort.

Since Windows 2000, however Microsoft isn't Apple, in being a dictator regarding OS API adoption.

Well, they kinda had to rush that meeting because they spent too much time on the previous meeting listing all the reasons why the microsoft store is a functioning package system and not at all a din of inequity.

There are already many services and APIs for doing this. It’s more like:

A: There are a dozen ways to do this correctly. Which right way should we pick?

B: I don’t know, I found this code on the internet. Should I just use it?

A: Sure, if it’s on the internet it must be the right way.

> There are already many services and APIs for doing this

I... don't think so? The particular problem here, is that an uninstaller executable needs to delete itself from disk after doing its main job.

Other than using MoveFileEx with a NULL destination file and the MOVEFILE_DELAY_UNTIL_REBOOT flag, then suggesting/forcing a reboot, I can't think of a straightforward solution.

And that solution instantly lights up your JIRA with 2 tickets:

#1: We MUST not suggest/force a reboot! Users hate it!

#2: CRITICAL BUG: uninstaller.exe still present after uninstalling product

So, then you try things like 'create a Task Scheduler job to delete the file', which then adds:

#3: PRIO 1: uninstaller.exe crashes if Windows Task Scheduler disabled

#4: SHOWSTOPPER: uninstaller.exe still not always deleted after uninstall. Why is this so hard?

Et cetera, ad absurdum. This then escalates to code injection (as described in the linked article), and (you heard it here first) kernel-mode drivers. So, if you're aware of a reliable solution, feel free to share in a comment here, for the betterment of the world!

Resolution: this is just how Windows works, deal with it

>Other than using MoveFileEx with a NULL destination file and the MOVEFILE_DELAY_UNTIL_REBOOT flag, then suggesting/forcing a reboot, I can't think of a straightforward solution.

And what's the problem with this?

One of the comments on the article gives one example:

> When our product’s uninstaller sees an undeletable file (possibly a DLL loaded in another process), it uses the MOVEFILE_DELAY_UNTIL_REBOOT flag to mark it for deletion, and warns the user “Please reboot as soon as possible to remove the remaining files.”

> However, some user uninstall our product, just to be able to reinstall it later, to the same location. And of course they ignored the warning. Once they reinstalled it, everything works, until a reboot.

> And what's the problem with this?

That solution instantly lights up your JIRA with 2 tickets: #1: We MUST not suggest/force a reboot! Users hate it! #2: CRITICAL BUG: uninstaller.exe still present after uninstalling product

A new API would only work in fully updated versions of windows that include the API.

Programmers would hesitate to use it, because they can't be sure the user of the uninstaller will be on a fully updated windows install.

The JScript workaround might seem like a bit of a hack, but it has an advantage of working on every version of windows all the way back to Windows 98.

Schedule a cronjob / win equiv

This is from the almighty raymond chen tho.

Reply on news.ycombinator.com