Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?

share|improve this question
up vote 2 down vote accepted

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.

share|improve this answer
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 or the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths

share|improve this answer
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

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.

share|improve this answer
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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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