Hi @ll, here's another (well-known, but undocumented) idiosyncrasy of Windows' CreateProcess*() functions with a "nice" side-effect:-P >From <http://msdn.microsoft.com/library/ms682425.aspx>: | BOOL WINAPI CreateProcess( | _In_opt_ LPCTSTR lpApplicationName, | _Inout_opt_ LPTSTR lpCommandLine, ... | To run a batch file, you must start the command interpreter; set | lpApplicationName to cmd.exe and set lpCommandLine to the following | arguments: /c plus the name of the batch file. This is but wrong (and of course dangerous too: you should NEVER set lpApplicationName to an unqualified filename, but ALWAYS use the fully qualified pathname; see <http://support.microsoft.com/kb/2269637> and <http://support.microsoft.com/kb/2389418>)! Now the REAL behaviour (of Windows NT4, Windows NT5.x, Windows NT6.x): CreateProcess("<pathname>.cmd", ...) CreateProcess("<pathname>.bat", ...) CreateProcess(NULL, "<pathname>.cmd[ ...]", ...) CreateProcess(NULL, "<pathname>.bat[ ...]", ...) (and of course CreateProcessAsUser(), CreateProcessWithLogonW() and CreateProcessWithTokenW() too) execute a rogue program CMD.EXE from the 'application directory' (i.e. the directory where the program that calls CreateProcess*() is located) instead of the expected %COMSPEC% alias %SystemRoot%\System32\cmd.exe, with the command line set to "cmd /c \"<pathname>.cmd\"" resp. "cmd /c <pathname>.cmd[ ...]". >From <http://msdn.microsoft.com/library/ms682425.aspx>: | lpCommandLine [in, out, optional] ... | If the file name does not contain an extension, .exe is appended. ... | If the file name does not contain a directory path, the system | searches for the executable file in the following sequence: | 1. The directory from which the application loaded. | 2. The current directory for the parent process. | 3. The 32-bit Windows system directory. ... JFTR: ShellExecute*() calls CreateProcess*() to start <pathname>.bat and <pathname>.cmd, so Windows Explorer (and of course any other program calling ShellExecute*() too) start CMD.EXE from their 'application directory' or the 'current working directory' too.-( The 'application directory' of Windows Explorer is %SystemRoot%, and Windows Explorer sets the 'current working directory' to the path of the file to be opened. %SystemRoot%\System32\CMD.EXE is found via the documented search path ... until someone creates a CMD.EXE in %SystemRoot% or the 'current working directory' (i.e. the directory where <filename>.bat or <filename>.cmd is located). FIX (for ShellExecute*() and Windows Explorer): change the value of the default registry entries of [HKEY_CLASSES_ROOT\batfile] and [HKEY_CLASSES_ROOT\cmdfile] from @="%1 %*" to @=expand:"%SystemRoot%\\System32\\cmd.exe /C Call \"%L\" %*" or @=expand:"\"%COMSPEC%\" /C Call \"%L\" %*" Additionally, see <http://support.microsoft.com/kb/905890> as well as <http://msdn.microsoft.com/library/aa365527.aspx> and set [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager] "SafeProcessSearchMode"=dword:00000001 stay tuned Stefan Kanthak PS: when <filename>.bat or <filename>.cmd are started from Windows Explorer the console window of the new process shows the icon of the CMD.EXE found in the 'current working directory' (i.e. the directory where <filename>.bat or <filename>.cmd is located), not the icon of the command processor %SystemRoot%\System32\cmd.exe ... independent of the above mentioned fixes! But that's just another of Windows' many idiosyncrasies! Timeline: ~~~~~~~~~ 2013-10-23 informed vendor 2013-10-24 vendor replies: see <http://msdn.microsoft.com/library/ff919712.aspx> OUCH! 2013-10-24 NO, this does NOT describe the behaviour of CreateProcess() or ShellExecute() for *.CMD and *.BAT 2013-10-24 vendor replies: MSRC case 15734 opened ... 2013-11-18 requested status from vendor 2013-11-24 no answer, report published
