Some time ago, I advised, "Don't just grab the foreground window and host UI on it."
Today I learned of another application that failed to heed this advice.
When the application's installer is launched,¹
uses that window as the owner for its dialogs.
In particular, if you install the app by typing
setup into the Run dialog,
it would end up hosting all of its dialogs on the Run dialog.
This is kind of a problem because the Run dialog is ephemeral. After the app is successfully run, the Run dialog destroys itself. This in turn causes the installer to crash.
Windows works around this by having the Run dialog
play complicated foreground games,
"parking" foreground on another window before launching the
installer, and leaving foreground on the parked window
long enough for the
setup app to call
On the other hand, if the attempt to run the thing you typed
fails, the Run dialog takes foreground back from the
window so it can display the error message.
Fast-forward twenty years. All these foreground games are very fragile, and finally something breaks. The code that tries to steal back foreground in order to display the error message stops working.
The solution: Remove the crazy code to work around this setup program.
The installer in question probably doesn't work any more for a ton of other reasons, since it played funny games with Program Manager (yes, Program Manager) in order to get itself hooked into your shell. Program Manager hasn't been the shell for over twenty years.
The risk here is not that somebody is using that twenty-year-old program. The risk is that some program written yesterday is relying on this old compatibility hack.
¹ Why is it always setup apps who make this mistake? My guess is that companies give the job of writing the installer to the junior developer.