Prev: Icons in Menus
Next: Off to MVP Summit!
From: Kerem Gümrükcü on 14 Feb 2010 16:32 Hi Pavel, i am doing GetSystemDiretory() and thats perfectly ok. At first i wanted to do SHGetFolderPath(...) but first one is ok. That PATH is not a shell feature is also clear, since many other non-shell applications use the PATH and environment. I am pretty sure that it does not fail because of the missing MUI resources, it has another reason but i did not investigate any further since this works absolutely fine and i dont have the time now to do deeper debugging to find that out,... Regards Kerem -- ----------------------- Beste Gr�sse / Best regards / Votre bien devoue Kerem G�mr�kc� Latest Project: http://www.pro-it-education.de/software/deviceremover Latest Open-Source Projects: http://entwicklung.junetz.de ----------------------- "Pavel A." <pavel_a(a)12fastmail34.fm> schrieb im Newsbeitrag news:90573514-7CEC-41CA-B350-EC77F872756B(a)microsoft.com... > No, of course PATH is not a "shell feature". > On Vista your CreateProcess() fails probably because the app fails to find > its MUI resources. > The easiest and safest is just to use the full path (expand > %SYSTEMROOT%....) > > Regards, > --pa > > > "Kerem G�mr�kc�" <kareem114(a)hotmail.com> wrote in message > news:uq7dLMVrKHA.1796(a)TK2MSFTNGP02.phx.gbl... >> Hi David, >> >> thanks for the response. Yes, i also finally >> found out, that i have to provide a full >> image path and i did it, there is really >> no other way. But the MSDN documentation >> is a little missleading here, since it seems >> that there will be a search for the executable >> on certain parameter inputs. I think they >> should make this a little more clear,... >> >> Regards >> >> K. >> >> -- >> ----------------------- >> Beste Gr�sse / Best regards / Votre bien devoue >> Kerem G�mr�kc� >> Latest Project: http://www.pro-it-education.de/software/deviceremover >> Latest Open-Source Projects: http://entwicklung.junetz.de >> ----------------------- >> >> "David Craig" <drivers(a)noemail.noemail> schrieb im Newsbeitrag >> news:eGM4v6UrKHA.4752(a)TK2MSFTNGP04.phx.gbl... >>> The PATH is a feature of the shell and not CreateProcess(). You must >>> provide the full pathname to the executable you wish to execute. Since >>> it is running elevated, this is critical for security to keep a viral >>> program of the same name, but not in a protected directory from being >>> executed. >>> >>> "Kerem G�mr�kc�" <kareem114(a)hotmail.com> wrote in message >>> news:esZoUbUrKHA.3908(a)TK2MSFTNGP05.phx.gbl... >>>> Hi, >>>> >>>> since i am not a big CreateProcess(...) user, this >>>> problem bothers me a little: I wanted to start >>>> "taskmgr.exe" from another application (running >>>> elevated, means the creator runs elevated and >>>> starts taskmgr.exe elevated too) but it fails with >>>> 2 (File not Found). >>>> >>>> Thats what the call looks like: >>>> >>>> BOOL _ret = CreateProcess( >>>> NULL, >>>> szExe, >>>> NULL, >>>> NULL, >>>> FALSE, >>>> 0, >>>> NULL, >>>> NULL, >>>> &si, >>>> &pi); >>>> >>>> ...and it fails! >>>> >>>> I checked my environment on the process >>>> and it holds the PATH variables pointing to >>>> the system directories where the taskmgr.exe >>>> is in, but it fails to find them! >>>> >>>> But when you read the MSDN doc for the >>>> function on the "lpApplicationName" description, >>>> then this is pretty unclear for me WHY this fails >>>> with that parameters i pass to the function: >>>> >>>> http://msdn.microsoft.com/en-us/library/ms682425%28VS.85%29.aspx >>>> >>>> si and pi have been zero filled before called. >>>> szExe holds "taskmgr.exe". What am i doing >>>> wrong here? It perfectly work with a full path >>>> but i dont want to compose a full path from >>>> environment variables or API functions before >>>> calling the function, because it should work >>>> the way i called it,...at least i think it should. >>>> I also dont want to use ShellExecute or WinExec, >>>> because i need the hProcess of the STARTUPINFO. >>>> The taskmgr.exe isnt really the Windows Taskmanager >>>> its a replacement i want to comminicate with. It >>>> uses the "Image File Execution Options" key in >>>> the registry to route the call to my application. >>>> I can perfectly start it with full path, or by using >>>> command line shell, etc. there is no problem. I also >>>> checked to run any application in the Windows >>>> System32 directory,...with no success. It is the call >>>> to CP(...) that fails and i think i am doing something >>>> wrong here,... >>>> >>>> The system is Windows Vista 32 bit, just for the >>>> case you want to know where i want to execute >>>> that,... >>>> >>>> TIA,... >>>> >>>> K. >>>> >>>> -- >>>> ----------------------- >>>> Beste Gr�sse / Best regards / Votre bien devoue >>>> Kerem G�mr�kc� >>>> Latest Project: http://www.pro-it-education.de/software/deviceremover >>>> Latest Open-Source Projects: http://entwicklung.junetz.de >>>> ----------------------- >>>
From: David Craig on 14 Feb 2010 16:45 I see where there are some interesting uses of PATH in CreateProcess() under some special circumstances. The full usage of the PATH environment variable is a shell extension or feature. I am referring to using a command line prompt such as DOS or either command or cmd shells in Windows where you type a filename to execute and then specific rules are followed to determine what to execute or process. The priority of .exe, .com, .bat, & .cmd and the directory order from current directory to those in the PATH are more of what I was thinking about, though I did not remember the trick of not using the first parameter to CreateProcess() and having it do some of the same PATH searching, though it does not handle multiple filename extension as do the command line shells. I wonder if PreFast for applications warns about using that capability. It seems to not be a secure coding practice and I note that the current Visual Studio 2008 SP1 MSDN Library says to NOT omit the first parameter to CreateProcess(). I think that applies even more to an elevated application. "Pavel A." <pavel_a(a)12fastmail34.fm> wrote in message news:90573514-7CEC-41CA-B350-EC77F872756B(a)microsoft.com... > No, of course PATH is not a "shell feature". > On Vista your CreateProcess() fails probably because the app fails to find > its MUI resources. > The easiest and safest is just to use the full path (expand > %SYSTEMROOT%....) > > Regards, > --pa > > > "Kerem G�mr�kc�" <kareem114(a)hotmail.com> wrote in message > news:uq7dLMVrKHA.1796(a)TK2MSFTNGP02.phx.gbl... >> Hi David, >> >> thanks for the response. Yes, i also finally >> found out, that i have to provide a full >> image path and i did it, there is really >> no other way. But the MSDN documentation >> is a little missleading here, since it seems >> that there will be a search for the executable >> on certain parameter inputs. I think they >> should make this a little more clear,... >> >> Regards >> >> K. >> >> -- >> ----------------------- >> Beste Gr�sse / Best regards / Votre bien devoue >> Kerem G�mr�kc� >> Latest Project: http://www.pro-it-education.de/software/deviceremover >> Latest Open-Source Projects: http://entwicklung.junetz.de >> ----------------------- >> >> "David Craig" <drivers(a)noemail.noemail> schrieb im Newsbeitrag >> news:eGM4v6UrKHA.4752(a)TK2MSFTNGP04.phx.gbl... >>> The PATH is a feature of the shell and not CreateProcess(). You must >>> provide the full pathname to the executable you wish to execute. Since >>> it is running elevated, this is critical for security to keep a viral >>> program of the same name, but not in a protected directory from being >>> executed. >>> >>> "Kerem G�mr�kc�" <kareem114(a)hotmail.com> wrote in message >>> news:esZoUbUrKHA.3908(a)TK2MSFTNGP05.phx.gbl... >>>> Hi, >>>> >>>> since i am not a big CreateProcess(...) user, this >>>> problem bothers me a little: I wanted to start >>>> "taskmgr.exe" from another application (running >>>> elevated, means the creator runs elevated and >>>> starts taskmgr.exe elevated too) but it fails with >>>> 2 (File not Found). >>>> >>>> Thats what the call looks like: >>>> >>>> BOOL _ret = CreateProcess( >>>> NULL, >>>> szExe, >>>> NULL, >>>> NULL, >>>> FALSE, >>>> 0, >>>> NULL, >>>> NULL, >>>> &si, >>>> &pi); >>>> >>>> ...and it fails! >>>> >>>> I checked my environment on the process >>>> and it holds the PATH variables pointing to >>>> the system directories where the taskmgr.exe >>>> is in, but it fails to find them! >>>> >>>> But when you read the MSDN doc for the >>>> function on the "lpApplicationName" description, >>>> then this is pretty unclear for me WHY this fails >>>> with that parameters i pass to the function: >>>> >>>> http://msdn.microsoft.com/en-us/library/ms682425%28VS.85%29.aspx >>>> >>>> si and pi have been zero filled before called. >>>> szExe holds "taskmgr.exe". What am i doing >>>> wrong here? It perfectly work with a full path >>>> but i dont want to compose a full path from >>>> environment variables or API functions before >>>> calling the function, because it should work >>>> the way i called it,...at least i think it should. >>>> I also dont want to use ShellExecute or WinExec, >>>> because i need the hProcess of the STARTUPINFO. >>>> The taskmgr.exe isnt really the Windows Taskmanager >>>> its a replacement i want to comminicate with. It >>>> uses the "Image File Execution Options" key in >>>> the registry to route the call to my application. >>>> I can perfectly start it with full path, or by using >>>> command line shell, etc. there is no problem. I also >>>> checked to run any application in the Windows >>>> System32 directory,...with no success. It is the call >>>> to CP(...) that fails and i think i am doing something >>>> wrong here,... >>>> >>>> The system is Windows Vista 32 bit, just for the >>>> case you want to know where i want to execute >>>> that,... >>>> >>>> TIA,... >>>> >>>> K. >>>> >>>> -- >>>> ----------------------- >>>> Beste Gr�sse / Best regards / Votre bien devoue >>>> Kerem G�mr�kc� >>>> Latest Project: http://www.pro-it-education.de/software/deviceremover >>>> Latest Open-Source Projects: http://entwicklung.junetz.de >>>> ----------------------- >>>
From: Hector Santos on 14 Feb 2010 18:22
David Craig wrote: > I see where there are some interesting uses of PATH in CreateProcess() > under some special circumstances. The full usage of the PATH > environment variable is a shell extension or feature. I am referring to > using a command line prompt such as DOS or either command or cmd shells > in Windows where you type a filename to execute and then specific rules > are followed to determine what to execute or process. The priority of > .exe, .com, .bat, & .cmd and the directory order from current directory > to those in the PATH are more of what I was thinking about, though I did > not remember the trick of not using the first parameter to > CreateProcess() and having it do some of the same PATH searching, though > it does not handle multiple filename extension as do the command line > shells. One of the reason using the COMSPEC was important was that once upon a time, there were popular command line shell replacements. Using the comspec was a requirement for proper operation, especially for running batch file with 3rd party batch file extensions. It also resolved problems in early windows where batch files did not properly exit. You probably remember some of the Microsoft suggested "rules" to properly end a batch file? Like issuing a CLS at the end? That was a Win95 thing if I recall. > I wonder if PreFast for applications warns about using that capability. > It seems to not be a secure coding practice and I note that the current > Visual Studio 2008 SP1 MSDN Library says to NOT omit the first parameter > to CreateProcess(). I think that applies even more to an elevated > application. Interesting point. -- HLS |