CreateProcess - lpApplicationName vs lpCommandLine

I've been using the CreateProcess Win API, and I was wondering what the difference was between using the lpApplicationName and lpCommandLine for arguments v.s. just the lpCommandLine parameter.

For example:

CreateProcess(NULL, L"C:\Path\To\Notepad.exe", L"C:\Path\To\File\To\Load.txt"... etc
CreateProcess(NULL, NULL, L"C:\Path\To\Notepad.exe C:\Path\To\File\To\Load.txt"... etc

I assume that the second option, where only lpComm开发者_运维百科andLine is used would be like opening up cmd.exe and running that exact line. But what about the first line, is it loading up the application and specifying the command line arguments differently?

I've had a look at the MSDN documentation for the API but it doesn't seem to really detail whats happening, that what that parameters can contain, which is fine, but I'm just confused about what I should be doing when there are multiple ways to do it.

Please note, I know the two sample lines may not work as lpCommandLine requires a LPTSTR, not LPCTSTR. Its just for ease of understanding.

Thanks a lot for any help!

Andy

The recommended way is to to use both parameters. If you do not specify lpApplicationName you let Windows parse lpCommandLine to figure out the application name. Because space is a valid character in file names and directory names, this can (in rare cases) lead to wrong application being run. (e.g. if you have c:\program.exe and you start a program under c:\program files in Windows XP).

In both cases you should use the application name in lpCommandLine since this is used to calculate Argv[0].

I never use lpApplicationName and always quote the application part of lpCommandLine, in your example I would execute "C:\Path\To\Notepad.exe" "C:\Path\To\File\To\Load.txt" (Quoting all paths passed to CreateProcess is a good idea) Just using lpApplicationName can cause problems with child processes that access argv[0] which is why I stay away from it.

<rant> Using CreateProcess on anything other than yourself can be problematic since NT6+ can at any point decide that the thing you are executing requires admin rights because of application compatibility shims and/or installer detection and then CreateProcess just fails. Unless you need to use the debug or break away from job flags, I would suggest just calling ShellExecute[Ex] to be on the safe side...</rant>

According to MSDN, lpApplicationName is optional and can be NULL. In that case, the module name must be the first white space–delimited token in the lpCommandLine string.

If the executable module is a 16-bit application, lpApplicationName should be NULL, and the string pointed to by lpCommandLine should specify the executable module as well as its arguments.