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 Get­Foreground­Window 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 Get­Foreground­Window. 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.

Comments (40)
  1. dave says:

    >My guess is that companies give the job of writing the installer to the junior developer.

    This often seems to be the case. The net result is that the customer’s first (and probably lasting) impression of the quality of your software depends on the abilities of the most junior developer.

    1. Antonio Rodríguez says:

      That was my first impression of certain big-name browser whose icon is something like a Pokéball with four colors. As soon as the first version came out, I installed out of curiosity, and to my surprise I see that it installed itself inside my AppData folder, with full write permissions (maybe as a workaround to allow installation in corporation-managed computers?). This is a big security risk for a well known (and thus, commonly installed) program (executable replacement or patching, DLL spoofing, and perhaps more obscure attacks). What’s worse, its maker company touted the security of its products against those of Microsoft. Of course, I uninstalled it immediately. This issue was corrected later, but my trust was lost forever.

      1. Tim! says:

        Pretty sure they did this to enable automatic patching without requesting admin elevation every time. I wonder how they ended up fixing that; auto patching still works with this program in %programfiles% and it doesn’t request elevation.

        1. Tim! says:

          Probably they went this route: Man I wish I’d known about this 10 years ago.

        2. BobVul says:

          Both major non-Microsoft browser vendors have services installed. Said Pokéball-lookalike additionally has a scheduled task to trigger updates even if the browser is never launched.

        3. Domonkos says:

          They wrote a pretty sophisticated install/auto update system, and after some time even opensourced the client: architecture is a very interesting read: In short, they use a combination of windows services and scheduled tasks. If at first install UAC can elevate the process, than the installer will install a windows service and a scheduled task both under local system account. Those processes will install the actual application you wanted in the first place (mainly Chrome, but can be anything else) and do future updates. If you did not elevate the process, than it will install only in user’s land and will rely only on a scheduled task that has user permissions (starts when user creates a session {logs in}). They put a lot of work into it, accounting even for some corner cases in XP, which again isn’t a surprise, if you look at the age of the project: on Github the first commit dates back to 2009, and version 2 of the Omaha client-server protocol goes back to 2007, even before Chrome came out. Check your services, most likely you will have gupdatem and gupdate installed on your machine. If you have DropBox, than look for dbupdatem and dbupdate. Yep, same installer, same framework :) If you look at your scheduled tasks, you will see that it is fairly common practice by now to schedule tasks with elevated privileges to auto update software. I have five of them right now, and I can only hope that the authors did their homework by using integrity checks, certificate validations, and generally adopted security best practices, otherwise a man in the middle attack would be way too easy. At least Google’s is opensourced, although they build a custom version of it, so who knows :)

      2. exchange development blog team says:

        They have an awful lot of products that do this all-elbows install. Their recently-retired, very widely-used photo app would crash on startup if it wasn’t running under the Administrator account. Their reaction to repeated bug reports over this was “well, yeah, meh”.

    2. The MAZZTer says:

      The worst part is it’s likely the installer that gets tested. The uninstaller nobody cares about because you don’t want the user running it in the first place.


      Context for example:

  2. IanBoyd says:

    Speaking of installers. You still have installers offering (or worse: not offer) to add itself to the Quick Launch. The Quick Launch hasn’t existed since 2007. And then some installers also offer (or worse, not offer) to add itself to the Desktop – or worse: the Public (i.e. All Users) desktop – or worse: the Default desktop. And then some installers violate all the rules and pin themselves to my taskbar!

    The desktop folders need to go the way of the Quick Launch folder.

    I don’t know how to you can stop an application from pinning itself to the taskbar – once the installer runs as an administrator it can do anything: even pin itself to the taskbar!

    1. Antonio Rodríguez says:

      Pinning to the task bar is rude on install (one more point in disfavor of the Pokéball-icon browser!) because of its limited real state. But creating a desktop shortcut is a necessary evil. Many users (everybody has an uncle or a great mom) can’t launch a program if its icon isn’t in the desktop. Those are the kind of users that are patient (their computers tend to be old and slow anyways) and never use more than one program at a time, so having to close all windows (minimize? what’s that advanced technique?) isn’t a problem for them.

      1. Ray Koopa says:

        I really wonder how they pinned the pokeball to the taskbar. IIRC, Raymond once said something like “it’s not possible to access the pinned items programmatically because the user is in command to decide what he wants to pin to the taskbar. It would only be possible with some hacky mouse click simulation ‘solution'”. Meaning that Pokeball indeed does some hacky solutions just to cheat themselves into pinned state. Yikes.

    2. The MAZZTer says:

      AFAIK Microsoft UX guidelines should still say you should never install icons to the desktop or quick launch; the point is the user can add icons there themselves if they want.

      At least installers don’t seem to pin to taskbar. A few do but not many. I think it is more difficult now, possibly Explorer doesn’t scan that folder for updates like it did for Quick Launch (at least, when I drop shortcuts into the folder nothing happens), so you’d have to restart Explorer which would piss off anyone who used your installer if they had File Explorer windows open.

      You also have the Win+X menu which is even more fun since any shortcuts you add to that have to have a a very specific “DON’T ADD SHORTCUTS TO THIS LOCATION” or something like that hacked into the shortcut file (the Windows APIs won’t do it for you). Haven’t seen anyone add any here either.

      Lots of other UX stuff many installers break, such as adding more shortcuts than should be needed to the Start Menu (documentation should be accessible from within the app, uninstallers go in Programs and Features). I was really happy when I saw the Windows 8 start screen bring the Start Menu into line and give users the tools to stop most of that silliness (Visual Studio still insists on repinning a folder to the start screen… folders don’t work!… no matter how many times I unpin it, though).

      1. BobVul says:

        > * If your users are very likely to use your program frequently, provide an option during setup to put a program shortcut on the desktop. Most programs won’t be used frequently enough to warrant offering this option.
        > * Present the option unselected by default. Requiring users to select the option is important because once undesired icons are on the desktop, many users are reluctant to remove them. This can lead to unnecessary desktop clutter.

        Of course, IIRC some of Microsoft’s own programs don’t follow these guidelines and select the option by default.

        1. Scarlet Manuka says:

          That’s because Microsoft know that the users will definitely be wanting to run *their* programs frequently, of course!

          (Actually, as Raymond has said before, MS is a big place and sometimes some of the groups don’t do the right thing.)

    3. Medinoc says:

      ” The Quick Launch hasn’t existed since 2007.”

      I was about to say “I don’t think you should use Windows Vista’s release date for its end since it existed during the entire lifetime of Windows XP (which only officially died in 2009 or 2014)”, but then I remember the Quick Launch still existed in Vista! (and IIRC I still use it on my old Vista comp) Windows 7 was the first OS not to support it, due to the new taskbar.

      So what you should say is either that the Quick Launch hasn’t existed since 2012 (End of Vista’s mainstream support) or that it will cease to exist in 2017 (End of its extended support).

      1. George says:

        Quick Launch still exists. There are instructions for using it on Windows 7 that work fine for 8, 8.1 and 10 as well. You can use your favorite search engine to find out how. Now, putting things on it should be a choice of the user, which might or might not be facilitated by the installer. Many use a checkbox to indicate whether a desktop icon, quicklaunch icon, etc. should be created.

  3. Wyatt says:

    The most junior developer does not write the installer. Instead he writes the API, but since he’s only an intern working there over the summer, it only get’s partially implemented (at least that’s my theory having worked with a lot of half-baked API’s).

  4. DWalker says:

    “My guess is that companies give the job of writing the installer to the junior developer.”

    Which is terrible, because you absolutely need to get Setup done right. Not just for simple things like installing one program and ending up with one folder called “XYZTechnologies” and another one called “XYZ Technologies”, but for the really important things…

    … like knowing the difference between where to store app settings and where to store user settings. And, installers that insist on installing into the root of C, really drive me crazy. And installers that assume the C drive is where Program Files resides. And installers that assume there IS a C drive. After all these years there are still some of those apps.

    1. Antonio Rodríguez says:

      I have worked with developers and companies that insist on installing on the root of the C: drive, and it’s always because of one of two reasons (or both of them): their program won’t work from a path with spaces on it (Spanish Department of Treasury, I look at you), or, even worse, their program or one of its components contain hard-coded paths (or rely on them).

      Then you try to install it in a computer where the Windows installer has decided that the C: drive letter was to be assigned to an internal reader which contained a card at install time or to a removable magneto-optical drive (both have happened to me), and there is absolutely no way to make that program work (other that reinstalling Windows, that is).

  5. The MAZZTer says:

    I am guessing things like this are why there are application-specific shims… no risk of other apps relying on those hacks.

    On the top of setup apps… please don’t roll your own from scratch, use a framework like NSIS or something. A lot less work and testing needed and you’ll get better, professional-looking results.

    1. Stefan Kanthak says:

      Don’t use NSIS are other crapware which 1. creates executable installers and 2. can’t be “decompiled”.
      Create your installers for the package installer/manager provided by the OS: on Windows this is the Microsoft^WWindows installer.

      1. morlamweb says:

        @Stefan Kanthak: not being able to decompile installer packages is hardly a convincing enough reason to not use third-party installer frameworks, especially when said frameworks can integrate with Programs and Features.

        What you’d want to avoid is using an out-of-date framework; meaning, one that doesn’t know about 64-bit Windows, or that makes silly assumptions about the C: drive or drive paths, or that doesn’t use the latest OS look-and-feel. Or worse, a framework that doesn’t know about 32-bit Windows.

        1. Stefan Kanthak says:

          Opaque, intransparent installers (like those created by the crapware known as NSIS, InnoSetup and some more) which can’t be inspected beforehand are EVIL!
          Windows .msi/.msp/.msu/.cab/.inf, UNIX SVR .pkg, Linux .rpm/.deb, Androids .apk and many more can be inspected (this is what I meant with “decompiled”) beforehand: both their anticipated actions as well as their payload can be seen before the installation.

          1. skSdnW says:

            NSIS can be unpacked by 7-zip (a beta version also decompiles the instructions) and there is a unpacker for Inno as well…

  6. DWalker says:

    For those who like seeing a bunch of small icons somewhere on the taskbar, you can mimic the QuickLaunch bar in Windows 7 by making a new toolbar, turning off Show Text and Show title. Not sure about Windows 10.

    Installers will have no idea how to put icons into your custom Quick-Launch-Like toolbar, so they should quit asking, as has been mentioned.

  7. Tom says:

    When I install MSU patches for Windows or run EXE patches for Office I have to just wait till they are finished because they will steal UI focus and if I press enter key it will go to the installer instead of whatever program I was in a second ago

  8. Brian says:

    In my experience, they only give the setup app to the junior programmer long enough to realize that the setup app (which is the first thing customers see) is impacting customer satisfaction. Then that bowl of spaghetti gets handed off to a more senior dev who tries to fix things, but probably doesn’t catch this kind of issue. I’ve fixed busticated setup programs for two different employers over the years.

  9. Ramón Sola says:

    It could be even worse. It could be an installer which sets the WS_EX_TOPMOST flag on its main window: not a full-screen window, but a pretty big one.

    1. skSdnW says:

      This was even worse in the 90s when the blue gradient background window was popular and some installers made those full screen and always on top!

      1. Josh B says:

        The truly ugly part is how there are still drivers and little smatterings of other software still being released with those 16-bit installers that don’t even understand long file names. In 2016! I can’t imagine how much technical debt has piled up in the actual software if that’s the effort they put into the installer.

  10. Mark Sowul says:

    You’d be hard-pressed to find a worse install/uninstall bug than an infamous, ahem–broadly–used, network manufacturer, whose bluetooth uninstaller (which is triggered when upgrading) recursively deleted everything from the drive on which it was installed. Imagine my surprise when, while updating my bluetooth drivers, everything started disappearing from my desktop, programs stopped working, etc.

    1. Henri Hein says:

      Yikes! I think you get the “worst uninstaller encountered” badge.

  11. cheong00 says:

    I wonder what would happen if all those CreateWindowEx() related macro passes NULL to the hWndParent if it matches the hWnd of Desktop.

  12. The_Assimilator says:

    “My guess is that companies give the job of writing the installer to the junior developer.”

    I guess that explains Microsoft’s own SQL Server setup wizard.

  13. Henri Hein says:

    > My guess is that companies give the job of writing the installer to the junior developer.

    That is indeed a thing. It’s not so much companies that are doing this, it’s the developer teams themselves. Senior developers don’t want to work on the installer, and junior developers often don’t get the choice. Even if a senior developer is doing the installer, they will do the minimum necessary to get done with whatever the current requirement is and move on. Installers suffer from the additional challenge that they are slow and tedious to test manually, and don’t lend themselves well to unit-testing. So nobody wants to work on them and nobody wants to test them.

    Microsoft could help out here by providing an installer framework that is easy and pleasant to work with, or, at least, a little less psychosis-inducing than Cthulhu.

    1. DaveL says:

      >Microsoft could help out here by providing an installer framework that is easy and pleasant to work with

      I couldn’t agree more. All setup tools are horrible. It’s almost a punishment to get saddled with doing the installer. As problematic as it could be, the VS Installer was the easiest to work with – and MS have done themselves no favours by doing their best to ditch it rather than providing a well documented easy to use replacement.

  14. Stefan Kanthak says:

    > My guess is that companies give the job of writing the installer to the junior developer.

    0. That’s one of the biggest mistake any company can do: the installer is the first thing a customer/user sees, and they typically need to run with administrative privileges, so every (beginner’s) error can do REAL harm.
    1. Executable installers are broken as designed, almost all of them are vulnerable: they create unsafe TEMP directories, load DLLs from their application directory, …

  15. PhilW says:

    I’m with Henri Hein on this. It may well be junior developers that get the job of writing the install, but if anyone thinks they have the autonomy to do it independently (and potentially correctly) then in my experience they are incorrect. In reality the development teams don’t want to write the install and are generally clueless about best practices, and so give ridiculous requirements to that junior install developer (steal the foreground etc) with the results you see too often. I’ve heard more than one dev manager maintain that the install is “just copying files” and consequently gets fewer resources, including that junior developer in a situation that typically has the dev team saying “we’re finished – we can’t ship because we’re waiting for the install”.

  16. I bet the reason they did that is so they could try to force the UAC prompt into the foreground.

    1. UAC didn’t exist twenty years ago.

Comments are closed.

Skip to main content