4 ms·

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

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!)

bux93 3y ago
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.
eddythompson80 3y ago
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.
- PreInternet01 3y ago
  > 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!
  - yrro 3y ago
    Resolution: this is just how Windows works, deal with it
  - jiofj 3y ago
    >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?
    - 0x0000000 3y ago
      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.
    - dolmen 3y ago
      > 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
water9 3y ago
Schedule a cronjob / win equiv
Racing0461 3y ago
This is from the almighty raymond chen tho.
anticristi 3y ago
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.
- tinus_hn 3y ago
  Oh, they have, many times! That’s why we have msi, app-v, appx etc.
- modeless 3y ago
  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.
- yrro 3y ago
  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!)
- pjmlp 3y ago
  Since Windows 2000, however Microsoft isn't Apple, in being a dictator regarding OS API adoption.
ack_complete 3y ago
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/modernize/apply-windows-themes 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.
deleted 3y ago
[deleted]
phire 3y ago
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.

bux93 3y ago

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.

eddythompson80 3y ago

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.

PreInternet01 3y ago
> 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!
- yrro 3y ago
  Resolution: this is just how Windows works, deal with it
- jiofj 3y ago
  >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?
  - 0x0000000 3y ago
    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.
  - dolmen 3y ago
    > 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

water9 3y ago

Schedule a cronjob / win equiv

Racing0461 3y ago

This is from the almighty raymond chen tho.

anticristi 3y ago

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.

tinus_hn 3y ago
Oh, they have, many times! That’s why we have msi, app-v, appx etc.
modeless 3y ago
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.
yrro 3y ago
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!)
pjmlp 3y ago
Since Windows 2000, however Microsoft isn't Apple, in being a dictator regarding OS API adoption.

ack_complete 3y ago

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/modernize/apply-windows-themes 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.

deleted 3y ago

[deleted]

phire 3y ago

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.