INFO: Understanding CreateProcess and Command-line Arguments

ID: Q175986

The information in this article applies to:

Microsoft Win32 Application Programming Interface (API), used with:
- Microsoft Windows NT versions 3.51, 4.0
- Microsoft Windows 95
- Microsoft Windows 2000

SUMMARY

This article explains the relationship between the ApplicationName and CommandLine parameters of the CreateProcess() API, specifically to clarify any issues that arise when you use both parameters.

MORE INFORMATION

The first two parameters of the CreateProcess API are ApplicationName and CommandLine. The behavior of these parameters differs depending upon whether you are creating a 32-bit process or a 16-bit executable.

Behavior of CreateProcess() When Creating a 32-bit Process

Case 1:

If the ApplicationName parameter is passed and the CommandLine parameter is NULL, then the ApplicationName parameter is also used as the CommandLine. This does not mean that you can pass additional command-line parameters in ApplicationName string. For example, the following call will fail with a "File Not Found" error:


   CreateProcess( "c:\\MyApp.exe Param1 Param2", NULL, ... )

Case 2:

On the other hand, if the CommandLine parameter is non-NULL and the ApplicationName parameter is NULL, then the API attempts to extract the application name from the CommandLine parameter.

Case 3:

The flexibility of the CreateProcess() function (and a possible point of confusion) arises when you pass a valid string pointer to both the ApplicationName and CommandLine parameters. This allows you to specify the application to be executed as well as the complete command line that is passed to the application. One might assume that the command line passed to the created application is a composite of the ApplicationName and CommandLine parameters, but this is not the case. As a result, a process created by CreateProcess can receive a value other than its .exe name as its "argv[0]" parameter. The following is an example of a call to CreateProcess that produces this "abnormal" behavior:


   CreateProcess( "c:\\MyApp.exe", "Param1 Param2 Param3", ...)

MyApp's arguments will be as follow:


  argv[0] == "Param1"
  argv[1] == "Param2"
  argv[2] == "Param3"

NOTE: ANSI specifications require that argv[0] should be equal to the application name, but CreateProcess gives the calling application the flexibility to override this rule for 32-bit processes.

Behavior of CreateProcess When Executing a 16-bit .exe

CreateProcess() does enforce the ANSI specification for parameters passed to 16-bit applications. This raises a potentially confusing inconsistency between the way CreateProcess works from one application to the next and requires you to know whether the application that you are spawning is a 16- bit or 32-bit executable file. To further complicate the issue, CreateProcess is implemented slightly differently in Windows 95 and Windows NT.

Windows NT Behavior:

If the first "parameter" in the CommandLine is not exactly the same as the ApplicationName string, then it replaces it before executing the application. For example if the ApplicationName and CommandLine parameters are as follows:


  CreateProcess( "c:\\MyApp16.exe", "Param1 Param2 Param3", ...)

Then, the command line arguments that the application sees are as follows:


  argv[0] == "c:\MyApp16.exe"
  argv[1] == "Param2"
  argv[2] == "Param3"

Windows 95 Behavior:

If the first "parameter" in the CommandLine is not exactly the same as the ApplicationName string, then CreateProcess fails with a file not found error. As a result, there is no reason to pass anything but NULL as the ApplicationName argument to CreateProcess in Windows 95 if you are executing a 16-bit application.

Additional query words:

Keywords : kbAPI kbConsole kbKernBase kbNTOS351 kbNTOS400 kbWinOS2000 kbThread kbWinOS95 kbDSupport kbGrpKernBase
Version : winnt:3.51,4.0
Platform : winnt
Issue type : kbinfo