An application compatibility report came in for a program that crashed during installation. The primary installer created a temporary directory and then ran a secondary installer from that temporary directory. So far, that’s standard behavior to avoid operating from a disease-ridden hot tub. What made it more frustrating to debug is that the secondary installer in turn runs a tertiary installer, and it was the tertiary installer that was crashing. (At least it stopped at the tertiary installer. Otherwise it’s installers all the way down.)
Some debugging of the tertiary installer revealed that it was trying to pin itself to the taskbar automatically on install. This is one of those things that installers love to do, probably second only to silently taking over popular file extensions. This particularly program’s approach was to find the vtable for the internal interface that Explorer uses to pin items to the taskbar, and then call the fifth function in the vtable.
The application compatibility issue was that we changed the signature of the fifth function in the vtable, so they were calling the function with the old signature, and the implementation was therefore misinterpreting the parameters, and as a bonus insult, it also corrupted the stack because the number of parameters also changed.
The solution was to restore the function to its original signature and have it just return without doing anything, decorated with comments to ensure that the method stays at the same slot in the vtable for eternity. Meanwhile, the new functionality was moved to a different location. (I’m not telling where.)
I bet someone got a really nice bonus for that “feature”.
This is my favourite kind of oldnewthing story. What i always wonder though is why Microsoft don’t open up these “forbidden” APIs, but embeds user confirmation dialogs in them? Sure, it’s bad sport to mix UI and functions but still.
It was probably moved to 6th vtable entry.
Because developers abuse them, no matter how user hostile that is. Want the user to say Yes to pinning your app?
While (app_is_not_pinned) { call request_app_to_be_pinned(); }And then just spam the user with acceptance dialogue until they just click Yes. There are already enough out there that guide users through a process to change global settings and keep pestering if you don’t.
You wouldn’t even need to pester the user like that – unless the dialog is isolated like the UAC dialog, the application can just click the Yes button itself via a window message or UI Automation. Or the application could just patch the internal function so that it doesn’t open a dialog in the first place, or hook CreateDialog or whatever API call gets used to create the dialog.
Yeah, but for such hostile apps it’s better if they patch out known APIs than to patch some random vtables by scanning memory
I thought pinning stuff to the Win7+ taskbar (“Superbar”) was never meant to be controlled programmatically? Like that’s up to the user to decide what is pinned, as with pinned apps in the old Win7+ start menu? Are some applications so important that Microsoft ignores their purposefully set limitations and fixes compatibility if these apps work around them – or do I just badly remember the set limitations…?
I know of at least one program that at least only offers to programmatically pin itself to the taskbar for you, so still leaving it up to the user (I declined the pin). Its approach to pinning itself is at least somewhat less hacky than the installer in the article.
Notice that the “fix” changes the function to a nop. The limitation is still in force.
Oh, I missed that detail in my rage over that app. That kinda makes more sense. Yet I’d personally be unsatisfied without such programs crashing from doing this bogus and code getting yucky because of them. But yeah, we know who’d get the blame for the crash eventually…