Avoiding the Path environment variable


Jump to: navigation, search



Windows as well as operating systems from which it is derived provide a way to tell the command processors where executable files can be found. On Windows it is the environment variable Path.

Application developers are often tempted to make heavy use of this environment variable or rely on the installation program to ensure that 'Path' points to the proper executables.

Although sometimes not avoidable there are some vital drawbacks to consider.

Older Windows versions only support a maximum length of the 'Path' environment variable. More recent versions don't have this restriction anymore, but whenever a command is executed Windows needs to keep reading the folders stored in this variable until it can find the executable or script file name. This can have a significant influence on the overall system performance and delay the command execution. Sometimes the 'Path' variable is broken which prevents other commands from beeing executed (Why don't my commands work?).

In most cases it is possible to avoid using 'Path' and leave the target system in a faster state. Actually, on a modern Windows operating system there is no requirement for an application to use or rely on the 'Path' variable at all unless it consists of a whole bunch of programs and scripts (see Unavoidable cases).

Why 'Path'?

There are many reasons why application developers believe that an entry in the 'Path' list is required, but at the end of the day they come all down to a single one: the application and its direct link libraries (DLLs) are to be found automatically, no matter of the current directory.

Ways to avoid a 'Path' entry

There's not really one single multi-purpose way of avoiding 'Path' entries, but it's still a good idea to consider one of the following alternatives.

Providing the executable's path

The application's setup can write its executable path into a registry value. Other programs that rely on the base application can then use this value. This is not always helpful for programs invoked from the command line. A script, however, can easily retrieve this information and make use of it. Obtaining Inno Setup's installation path shows an example for Inno Setup's compiler.

A running application can always retrieve its executable path to find DLLs in the same directory with native Windows APIs. Application working directory in the article Application considerations shows some options. That means that there's actually never a reason to set PATH just so that an application can find its DLL(s).

A copy in the system directory

For small applications it may be convenient to have a copy of the executable in the operating system's system folder (very often C:\WinNT\System32 or C:\Windows\System32).

By using Inno Setup this copy will automatically be removed upon uninstallation, too. It might depend on the file size if it is better to only have a copy in the system folder or to have a copy in the system folder and additionally in the application's directory.

Although today's media sizes allow a bit of wasted space, two copies of an executable cannot always be the preferred way.

Invocation scripts

Create a batch file with the name of the executable's module but with the file name extension '.CMD'. For instance, if the application's executable module is called 'MyApp.exe' create a batch script with the name 'MyApp.cmd' and put it in the system directory.

'MyApp.cmd' can then look similar to this example:

CD "C:\Program files\MyApp"

Now 'MyApp.exe' can be started from any directory on the system by just typing its name without file name extension ('MyApp') or with the command line script's file name extension ('MyApp.cmd').

Unavoidable exceptions

There's no solution without a 'Path' entry for applications or tool boxes that consist of many different executables or scripts. This purpose is actually what the 'Path' environment variable was originally meant for. In this case you should not try to circumvent the purpose somehow.

Making use of the 'Path' environment variable cannot be avoided for:

  • Compilers or development environments with more than just one compiler executable if it's required to call them from arbitrary working directories (ie. from the command line, for example)
  • Tool kits with many executables that need to be called from arbitrary working directories
  • Database clients with many provided tools that need to be called from arbitrary working directories
  • etc.

Note however that this doesn't necessarily mean that your installer needs to modify the PATH variable on installation. If the utilities will only be used occasionally or in special circumstances, then it may be a better idea to create a batch script which temporarily adds your folder to the PATH and then opens a command prompt; this way, your utilities are available on demand but don't clutter up the "regular" environment. For an example, see the Visual Studio Command Prompt.

See also

External links

Personal tools