The Garbled PATH Variable

Some of you might have already been bitten by this one: After installing a new Delphi version you end up with a garbled PATH variable, simply because the installer tries to extend this variable over some limit. I was not able to find enough reliable information to name this limit, but it might be something about 2000 characters, but this might as well depend on the underlying operating system.

During the setup of a new system with lots of older Delphi versions I decided to write a simple program that uses environment variables to compress the PATH variable so that hopefully it fits when installing the next Delphi version.

The process is plain simple: Check each entry in the PATH variable whether it starts with a given string and replace this with a short environment variable. When finished add those new variables to the environment and write back the shortened PATH variable.

For simplicity I decided to use a single file for this command line utility:

In most cases it should be sufficient to just run the utility as Administrator – otherwise you might not have enough rights to change the registry key in HKEY_LOCAL_SYSTEM. The logic inside InitShortCuts does quite a good job to adapt for different Delphi installations and operating systems. Feel free to add more settings for the missing Delphi versions and leave a comment with your extensions.

The mechanism is not restricted to Delphi pathes and can easily be expanded for other programs. Method InitShortCuts has an example for SQL server and Program Files in general.

If your needs are a little bit more special you can prepare a specific shortcut file that can be loaded via the /F command line parameter. For an example of such a file simply specify the /X command line parameter together with a file name to get the default settings exported.

This program is written with Delphi XE7 and probably uses some language features that may not be available in previous Delphi versions. Nevertheless, it should be not that hard for you to backport those constructs.

Author: Uwe Raabe

Addicted to Pascal/Delphi since the late 70's

10 thoughts on “The Garbled PATH Variable”

  1. Some kind of LZ compression… but for path names!
    This was the idea here :

    But using external environment variables make it pretty obfuscated and difficult to guess.

    I wonder if using the “short name” of the paths won’t be enough?

    or for a simple .bat which does that.

    It should be still readable, easily modifiable, and probably efficient.

    One first compression is to remove all of the non-existent directories in my path that had accumulated over time. The .bat of the “short name” SO answer allows this, by the way.

  2. The AppPath registry key is not used by CreateProcess, only ShellExecute etc, so it isn’t 100% reliable.

    1. If you do use CreateProcess(), you can setup the desired environment yourself. Anyway when Delphi itself is run, it’s usually done via the shell APIs – unless you have your own launcher which uses directly CreateProcess()…

      Messing with system-wide settings is a very bad practice. Your application is not the only one installed on a system, and you don’t know what gets installed before and after, leading to potential unwanted behaviours and even security risks if I can make my applications and DLLs be run instead of yours, epsecially since most installer not only modify the system path, but also prepends their paths to the system ones.

      “Modernizing” your application means also to write well-behaved applications that respect the *actual* OS rules, and don’t keep using outdated practices used when everything was much simpler and less unsafe.

      It’s not only a Delphi fault, there’s a lot of application requiring you to clean the path every time you install them.

  3. Simply remove those useless paths (Unless you really need the command line compiler). If you need additional paths (in delphi for example the good old bpls’s you can extend the (internal) path via delphi itself (options – environment variables – select path – add override (extend it)) I add my own library path to it.

  4. If you do want command line tools then there’s no point having multiple versions mention on the path. Only one is relevant. Visual Studio gets this right. No mods to path there. Embarcadero are way behind the curve here.


    I run into Path-Problems since XE5 and i used this trick, exclude redundant stuff into others variables, but with XE7 I t seems I hit a second barrier, the length of my Path variable is down to 1052 Bytes, but I run constantly into trouble. If I try to open an Project under XE6, which is using Zeos-lib, I get an Runtime Error 236 and then XE6 shuts down (!), Under XE4 I still can open the project but, I can’t run it in the IDE, can’t load SQLite dlls. Making the sqilte entry, the first think in the path variable, let me run it me under XE4 again, but XE6 still crashes with an Runtime Error 236 – by trying to open this project.

    What option do I have now? Shot the computer?

Comments are closed.