Many applications (specially developer tools) require that you add the path to the PATH enviroment variable in Windows. I know what is does, but for me this feels low-level

Aren't there any alternatives for this and other environment variables, causing the same effect in Windows? E.g. could the software be developed in a different way and manage this with another technique?


No, not really.

Of course software could be developed to use another var, but windows would have to use it to search for binaries for as well.

You can create yourself a script to only extend the PATH variable with your dev-tools paths when you need them, otherwise remove them again.

In Linux there’s the source command which the firefox jetpack sdk uses for example, which uses a sub-bash. Dunno if windows has something like that as well. That would be another / best option.

  • Any variables you set in a Windows .bat file will remain after it quits. You can modify this behavior if you don't want it to occur with setlocal and endlocal, though. – Ben Richards May 23 '13 at 19:12
  • It will persist within the cmd.exe session, but not the windows session or windows user session. If you open a new command prompt it will not have the variable set that you set in a first command prompt. – Kissaki May 27 '13 at 16:12

App Paths registry settings can be used to register application executable system-wide or for individual users just like adding the application directory to the PATH. So the application can be started by writing only it's executable name in command line.
For more details about App Paths check this article http://msdn.microsoft.com/en-us/library/windows/desktop/ee872121.aspx or the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths

  • 5
    Note that App Paths is used by the ShellExecute() function, but not by the CreateProcess() function, therefore some applications that start other programs might not be able to find executables which are registered only in App Paths. – Sergey Vlasov May 23 '13 at 19:03
  • And because App Paths do not work for CreateProcess(), it means that they won't work from a command prompt, or powershell prompt. But it does mean you can use the start command, which does use ShellExecute. >start notepad++ readme.txt – Ian Boyd Feb 12 '18 at 20:08

Every application can be made portable when being developed. There is no need of using the PATH variable.

The technique is to get the application launch path and using it to launch other app modules relatively to this launch path. dll search path includes application path already so this holds for other executables or modules/data making up the application.

  • I can't see how this will help if running the program.exe from the Command Prompt. If program.exe is part of a protable app installed in some random folder, and not included in the Path, it will not be found. – Kevin Fegan Apr 25 '13 at 22:27
  • On command prompt you use ".\program.exe". The "." stands for current folder. There is ".." for parent folder. These "shortcuts" work on Windows, Unix/Linux and I think on all OS's. – snayob Feb 14 '14 at 22:01

The only other solution is to put all files in the same directory as the executable, so that the path is not required for accessing the files. Or define a shortcut for the executable with a default path name.

This solution is used by many applications, for exactly this reason : avoid adding themselves to the PATH.


could the software be developed in a different way and manage this with another technique?

Yes. What I would do in this case, (if you have a program to install or whatnot, but you can't access the Path variable) is just make it so that the binary (program executable) is installed into the C:\Windows or C:\Windows\System32 folder. Then you'd be able to call it from command-line or programmatically, by just program, program /option, or program -o, or whatever it may be.

It really would be optimal to add it to the %Path% system variable, and if targeting Windows Vista, 7, or 8, you can have it prompt the user to elevate privileges and allow it to access it. But if that's somehow not an option, then you should at least be able to do what I said above.


It would be "Low-level", if you implement LD_PRELOAD by hooking some FileOpen() call, not by placing .dll to a program's folder. Some aufs/unionfs implementation may be another solution.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.