Does the Windows Command Prompt search somewhere other than those locations specified by the PATH variable when launching application programs?
I tried the following experiment.
Before I start, I checked the PATH variable from cmd, which has the following value:
Path=C:\Program Files (x86)\Intel\iCLS Client\;C:\Program Files\Intel\iCLS Client\;%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem;%SYSTEMROOT%\System32\WindowsPowerShell\v1.0\;C:\ProgramData\Lenovo\ReadyApps;C:\Program Files\Microsoft SQL Server\110\Tools\Binn\;C:\Program Files\Microsoft SQL Server\120\Tools\Binn\;C:\Program Files (x86)\Windows Live\Shared;C:\Program Files (x86)\Skype\Phone\;C:\Program Files (x86)\Intel\Intel(R) Management Engine Components\DAL;C:\Program Files\Intel\Intel(R) Management Engine Components\DAL;C:\Program Files (x86)\Intel\Intel(R) Management Engine Components\IPT;C:\Program Files\Intel\Intel(R) Management Engine Components\IPT;C:\Program Files (x86)\Calibre2\;C:\Program Files\Intel\WiFi\bin\;C:\Program Files\Common Files\Intel\WirelessCommon\;At first, I thought that cmd only looks for executables in the directories contained in the PATH variable, so I randomly picked an application - winword.exe (Microsoft Word), and tried to launch it from the command line:
start winwordBut to my surprise, the program launches! The reason I'm surprised is because I've searched through all the directories in the PATH variable for the exe file called 'winword' but all my searches came up empty!
I've therefore concluded that the command prompt must have known to search in places other than those specified in the PATH variable to look for executables.
So obviously, the next thing I did was to look for the precise location where the 'winword' executable file is located. It turns out that winword.exe is located here:
C:\Program Files\Microsoft Office 15\root\office15Hence giving me the idea that maybe CMD automatically looks through ProgramFiles and ProgramFiles(x86) (and all their subdirectories) when executing the 'start' command? Which led to me trying to launch another application installed on my computer, Audacity, with the exe file located at:
C:\Program Files (x86)\AudacityAgain, to my surprise, Audacity failed to launch when I typed:
start audacityat the command line.
I've then added the directory containing audacity.exe to PATH:
set path=%path%;C:\Program Files (x86)\Audacityafter which i tried launching audacity again:
start audacityWell, not surprisingly, Audacity launched.
What I want to know is where exactly does the command prompt look for executables? Why is it that winword.exe launches even when the directory containing it not part of PATH, but the same thing isn't true for audacity.exe?
I tried other applications too. Chrome and Firefox works when I use the start command.
UPDATE: I am running Windows version 6.3.9600 (Windows 8.1)
15 Answers
At first, I thought that cmd only looks for executables in the directories contained in the PATH variable, so I randomly picked an application - winword.exe (Microsoft Word) and tried to launch it from the command line:
The reason winword.exe worked is that a registry key exists which defined the path to Microsoft Word (Winword.exe). A similar key exists for Firefox.exe and Chrome.exe if those applications are installed.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App PathsHKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths
What I want to know is where exactly does the command prompt look for executables?
System PATH Variable, User PATH Variable, and the various keys within ..\App Paths. I was able to confirm that Audacity does not create a key for itself when it's installed.
When the ShellExecuteEx function is called with the name of an executable file in its lpFile parameter, there are several places where the function looks for the file. We recommend registering your application in the App Paths registry subkey. Doing so avoids the need for applications to modify the system PATH environment variable.
- The current working directory.
- The Windows directory only (no subdirectories are searched).
- The Windows\System32 directory.
- Directories listed in the PATH environment variable.
- Recommended: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths
Source: Application Registration
0From the command prompt, if you just enter WinWord it fails to run.
If you enter START WinWord it runs.
The Start command is key here.
When you try to execute a file through the start command, Command Prompt does not perform any searching. Instead, it passes the file name (and arguments) over to Windows itself (via the ShellExecuteEx API call), which must then search for the file's location. There are several places it searches in the following order:
The current working directory.
The
Windowsdirectory only (no subdirectories are searched).The
Windows\System32directory.Directories listed in the
PATHenvironment variable.Recommended:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths
WinWord is in that registry key. The key is there to keep PATH from getting too long.
The program (when you specify its module name without drive/path in command prompt) in Windows command processor (CMD.EXE) can be started when found:
by PATH environment variable (both executable and its hardlink/softlink/shortcut with the same name)
by DOSKEY alias
by application path from
HKLM\Software\Microsoft\Windows\CurrentVersion\App PathsorHKCU\Software\Microsoft\Windows\CurrentVersion\App Paths(when usingstartcommand)
Using this knowledge (especially the last one) you can create your own aliases convenient for you. For example you can create HKCU\Software\Microsoft\Windows\CurrentVersion\App Paths\au.exe with default value of C:\Program Files (x86)\Audacity\Audacity.exe and start this application simply by typing start au in command prompt.
While the other answers are likely to be the specific reason in your case, there is also another answer to your question which could have been the case for some other applications: in the same place you were looking, but with different file extensions.
You specifically said that you were searching for files with extension exe. Windows will also attempt to execute files of other extensions.
Another environment variable that comes into play when executing a command is the variable PATHEXT. This is a ;-delimited list of file extensions to attempt to execute. If you echo PATHEXT you might see something like .COM;.EXE;.BAT;.CMD;.VBS;... (etc.). Some applications use these other file types as their end-user entry point. It is much less common, but it happens. I have used several major commercial products which start from .BAT scripts. To use one of them as an example, I can start it with the command standalone even though there is no standalone.exe... instead, it has a standalone.bat.
Some of the extensions I have on the PATHEXT I'm looking at right now I have never had an application use. Ones that I have run into much more commonly (but obviously not as much as exe) are: .com, .bat, .vbs, .js, .jar. The first two are windows batch script files, and the other three are file types for specific programming languages which are run from scripts or virtual machines instead of from exes (respectively: visual basic, javascript, and java).
start winword does not tell the command prompt to launch winword. It tells the command prompt to launch start with argument winword. Start uses its own methods to find winword.
Just winword tells the command prompt to launch winword. And if you try that, since winword is not on the PATH, it doesn't launch.