From: Kerem Gümrükcü on
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
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
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
First  |  Prev  | 
Pages: 1 2
Prev: Icons in Menus
Next: Off to MVP Summit!