Your Wish Is My Command Prompt

You’ve reached an archived blog post that may be out of date. Please visit the blog homepage for the most current posts.

One of the things that everyone who writes installers hears about writing installers is that a user’s first impression of your product comes from the installer. Anything in the installer that startles the user or causes the user to regret clicking that fifth Next button is an opportunity for improving the user’s first impression of your product.

As a user of installations, one thing that makes me jump when I run an installer is seeing a command prompt window pop up.


Whenever it happens, I picture the publisher’s QA department creating a batch file for testing the product, and the install developer wanting to leverage what’s already in place. (Back when Windows Installer was introduced, the Windows® logo guidelines required a product’s installation to use Windows Installer. A common first reaction was, “I can just take my existing installer, and run it as an MSI custom action. Problem solved!” This is the same idea.) Being able to connect disparate processes to achieve a goal is an admirable skill. But in this case, don’t do it.

An opportunity exists for someone to write a Windows Installer ICE rule that fails if a custom action launches cmd.exe.

Instead of launching the command processor or a batch file to do something in your installation, you should see if built-in installer functionality can replace what the batch file does. Both Windows Installer and InstallScript have functionality for performing actions it can be tempting to use batch files for:

  • Instead of running regsvr32 to register a COM server, you can extract COM information or use component properties and functionality.
  • Instead of running net start to start a service, you can use MSI component advanced settings or InstallScript functions.
  • Instead of deleting extra files on uninstall using a batch file, you can use MSI tables such as RemoveFile or use InstallScript functions.
  • Instead of manipulating text files from a batch file, InstallShield has functionality for working with text files and XML files as well as InstallScript functions for manipulating files.

System changes made by built-in installer functionality are usually easier to uninstall or roll back than changes made by a batch file or other type of custom action. And if you must launch a system executable, you can often launch it directly rather than going through a batch file.

Smoothing out your installation’s user interface is work that’s repaid by an improved overall user experience for your product.

One comment on “Your Wish Is My Command Prompt

  1. Cary Roys on

    To expound on the statement, “And if you must launch a system executable, you can often launch it directly rather than going through a batch file.”…

    Some system executables display an empty shell window, even when their output is redirected, and they are invoked directly in an Executable custom action.

    If you are stuck with this type of situation, you can resolve it by just completely hiding any windows created by the process via bootstrapping in custom action code.

    Most frequently, you’ll be using the SW_HIDE flag for LaunchApplication() in InstallScript or ShellExecute() in C++, or the CreateNoWindow property of Process.StartInfo when using C#. Whatever method you’re using, it’s generally just a matter of passing the right flag to the API that launches your process.

    This is also useful if you are using an executable that may return a non-zero return value in a non-error scenario. Windows Installer treats a non-zero return code as a fatal error, which you may want to handle more intelligently in your code that calls and hides the process.


Leave a Reply

Your email address will not be published. Required fields are marked *