I'm not sure what you mean by having a "separate" PATH variable. PATH is the name of an environmental variable. (Actually, there is a User variable and a System variable, both called Path. The user's Path variable is appended onto the System's Path variable. Those are your options.)
You can have other environmental variables that aren't called Path.
For example, say your compiler exe is located in C:\some\directory\path.
What you can do is add another environmental variable, say "DEV", and give it the value C:\some\directory\path.
Then, you can simply add %DEV%; to your Path variable. But still, you need to edit the Path variable, I don't think you can get around that.
If you only add another variable without editing the Path variable, you can do something almost as good, you can do: %DEV%\myprogram.exe
you need that DEV entry to exist, but yes, you do not need to change PATH specifically.
let me take a crack at explaining what they said again, since you had to ask, you didn't get it.
the 'environment' is cluster of global variables that windows and the windows console (cmd, etc) can use.
the path is ONE variable in that cluster. It is not the only one, and you can make more, up to some limit (this stuff came in from dos and has some screwy limits, like path can only be like 1024 or 4096 or something like that characters long, which is a problem on some systems but there are workarounds).
you can add DEV as a variable that is NOT in the path, but still usable.
lets try it! open a console window (type cmd at the run in start menu).
and see a list of all the variables, including the path.
now lets make a variable:
type> set DEV="c:\" !!!!IMPORTANT!!!! NO WHITESPACE OR IT WILL MESS UP
type> echo %DEV%
type> cd %DEV%
The difference here is that if you do not edit path... lets say your path to your folder contains foo.exe.
if you modify the PATH, then from anywhere, any folder, in the console, if you type 'foo' it will run the program.
if you set it in another variable, you have to say %DEV%foo, which is the same as typing the path manually in front of the program name, and its clunky. you can also have the new variable do it all, set it to "c:\folder\foo.exe" and then type %DEV% and it will run the program. But those %s make this weird for actual usage, IMHO.
Another way that works is to make a small batch file in a known location that is in all paths, like c:\windows\system32 , that can run the program, foo.bat can invoke foo.exe (if you keep the same name, you need extra syntax to avoid recursive calling itself to death but its doable) and then you can type foo from anywhere, it will leech the path for foo.bat, and run foo.exe for you using the executable that isn't in the real path -- a bit of smoke and mirrors from days gone by :)
bld, I would go with mbozzi's approach. It does not modify the real Path variable, it just makes a temporary one for the duration of the console run, which let's you type, for example, g++ instead of D:\mingw\bin\g++
^^^ that is doubly the best way. If you were, for example, running foo.exe and foo.exe needed bar.dll, it would NOT see bar.dll if you did not extend the true windows path and instead had used the DEV variable or batch file or other 'trick' to invoke foo.exe. Without the path having bar.dll pointed to, the program will not run properly, if at all.
I was trying to explain how things work, more than recommend. Extending the path, forever or for the duration of your console as you see fit, is the correct way to do it.
Every process has an environment, which includes a PATH. That PATH is initially set to the system's PATH and then combined with the current user's PATH. While the PATH of each individual process can be modified, child processes inherit the parent process's environment.
You won't usually need to modify the system PATH. The system PATH lists all the directories required to boot your computer and fix any issues. The risk is fairly minimal if you modify the user's PATH instead. But, if you use the method discussed above, you won't even do that.
You know, like if you delete the default value or something
Yeah, don't do that. If you approach the task with the correct degree of care, it's not going to happen.
To cause a serious issue, you'd need to
1.) delete the value;
2.) fail to check your work;
3.) turn off your computer before you noticed the mistake; and
4.) not have any backups.
Of course this assumes you actually made some permanent changes.