Imagine knowing where each file in the system comes from. Imagine having a package system, instead of that crap.
Any sufficiently advanced uninstaller is indistinguishable from malware
71–80 of 556 posts
Re: Any sufficiently advanced uninstaller is indistinguishable from malware
#72I 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 re…
Re: Any sufficiently advanced uninstaller is indistinguishable from malware
#73I 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 re…
Re: Any sufficiently advanced uninstaller is indistinguishable from malware
#74interesting investigation and js. Though I'm wondering why does windows rely on the software to uninstall itself?
It doesn’t rely on it. It’s just something that’s possible.
Re: Any sufficiently advanced uninstaller is indistinguishable from malware
#75I 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 re…
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.
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!
Re: Any sufficiently advanced uninstaller is indistinguishable from malware
#76You can't rely on JScript being present unfortunately. It can be disabled.
Re: Any sufficiently advanced uninstaller is indistinguishable from malware
#77I 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 re…
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.
Re: Any sufficiently advanced uninstaller is indistinguishable from malware
#78And today I learned that Windows supports running Javascript as shell script. huh
like, really? can't you write that in C? I don't think most Win32 apps use JavaScript for their installers.
Re: Any sufficiently advanced uninstaller is indistinguishable from malware
#79Earlier quoted context omitted.
Been using this for years. Mostly really useful. Sometimes tricky to get right since the available APIs are semi-well documented and it's JScript, which is some sort of old Internet Explorer-ish version of JavaScript. By the way, there are also HTAs, which are Microsoft HTML Applications. You can create a simple double-clickable GUI with these using only HTML and JScript.
Pretty crazy how Microsoft basically invented the Electron app as HTAs all the way back in 1999. Of course we browsers weren't as capable as they are today, but "I just want a HTML+CSS GUI" had been a solved problem for over ten years when Electron first came out.
Re: Any sufficiently advanced uninstaller is indistinguishable from malware
#80Earlier quoted context omitted.
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 you…