Don’t just grab the foreground window and host UI on it, redux
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,¹ it calls
GetForegroundWindow and 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
GetForegroundWindow. 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.