Someone has used the Win32 api function CreateProcess ?

[Legacy User]

Microsoft reccomends the replacement of WinExec API by CreateProcess (or ShellExecute). We are trying to implement a full version of CreateProcess (previously we used a version which limits passed parameters to the second one -command line parameter, which passes application name plus parameters in a unique string-). However, trying to implement a full version seems to be more complex than supposed. We are receiving unexpected results for command line parameter. Someone to discuss on it?

TIA

Jorge Ubeda

[George Jeffcock]

see Source code: StellaTL/StellaTools.AutoIt.Abstract.SourceCode.CreateProcess

[Legacy User]

ok, will do it...

[George Jeffcock]

#include <strsafe.h>

{

    STARTUPINFO si;

    PROCESS_INFORMATION pi;

  char * cbProcessName;

  cbProcessName = ( char * ) ( LPCSTR ) &(1:);

    ZeroMemory( &si, sizeof(si) );

    si.cb = sizeof(si);

    ZeroMemory( &pi, sizeof(pi) );

  &(3:) = "";

  &(4:) = "";

    // Start the child process.

 

 

    if( !CreateProcess( NULL, // No module name (use command line).

 

 

        cbProcessName, // Command line.

 

 

        NULL,             // Process handle not inheritable.

 

 

        NULL,             // Thread handle not inheritable.

 

 

        FALSE,            // Set handle inheritance to FALSE.

 

 

        0,                // No creation flags.

 

 

        NULL,             // Use parent's environment block.

 

 

        NULL,             // Use parent's starting directory.

 

 

        &si,              // Pointer to STARTUPINFO structure.

 

 

        &pi )             // Pointer to PROCESS_INFORMATION structure.

 

 

    )

  {

  //Create Process failed

  LPVOID lpMsgBuf;

    LPVOID lpDisplayBuf;

  DWORD dw = GetLastError();

    // Retrieve the system error message for the last-error code

    FormatMessage(

        FORMAT_MESSAGE_ALLOCATE_BUFFER |

        FORMAT_MESSAGE_FROM_SYSTEM |

        FORMAT_MESSAGE_IGNORE_INSERTS,

        NULL,

        dw,

        MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT),

        (LPTSTR) &lpMsgBuf,

        0, NULL );

      // Display the error message

      lpDisplayBuf = (LPVOID)LocalAlloc(LMEM_ZEROINIT,(lstrlen((LPCTSTR)lpMsgBuf) + 100) * sizeof(TCHAR));

      StringCchPrintf((LPTSTR)lpDisplayBuf,LocalSize(lpDisplayBuf) / sizeof(TCHAR),TEXT("CreateProcess Failed: ErrorCode %d: Msg: %s"),dw, lpMsgBuf);

  &(3:) = "ERR";

  &(4:) = (LPCTSTR)lpDisplayBuf;

    LocalFree(lpMsgBuf);

    LocalFree(lpDisplayBuf);

  }

  else

  {

    // Wait until child process exits.

    WaitForSingleObject( pi.hProcess, INFINITE );

    // Get Return Code.

  DWORD dwExitCode = -1;

  GetExitCodeProcess(pi.hProcess,&dwExitCode);

    &(2:) = dwExitCode;

  LPVOID lpMsgBuf;

    LPVOID lpDisplayBuf;

  DWORD dw = GetLastError();

    // Retrieve the system error message for the last-error code

    FormatMessage(

        FORMAT_MESSAGE_ALLOCATE_BUFFER |

        FORMAT_MESSAGE_FROM_SYSTEM |

        FORMAT_MESSAGE_IGNORE_INSERTS,

        NULL,

        dw,

        MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT),

        (LPTSTR) &lpMsgBuf,

        0, NULL );

      // Display the error message

      lpDisplayBuf = (LPVOID)LocalAlloc(LMEM_ZEROINIT,(lstrlen((LPCTSTR)lpMsgBuf) + 100) * sizeof(TCHAR));

      StringCchPrintf((LPTSTR)lpDisplayBuf,LocalSize(lpDisplayBuf) / sizeof(TCHAR),TEXT("Code %d: Msg: %s"),dw, lpMsgBuf);

  &(4:) = (LPCTSTR)lpDisplayBuf;

    LocalFree(lpMsgBuf);

    LocalFree(lpDisplayBuf);

    // Close process and thread handles.

    CloseHandle( pi.hProcess );

    CloseHandle( pi.hThread );

  }

}

[George Jeffcock]

works...dreadful C++ probably....

[Legacy User]

Seen in Stella 1.5 Beta...In my previous copy (1.1) used ShellExecute.

You used only command line parameter, as we did in our current version. But, as MSDN warns (I'm looking at CreateProcess function (Windows)), by using this parameter, you are constrained to the limit of MAX_PATH :

The command line to be executed. The maximum length of this string is 32,768 characters, including the Unicode terminating null character. If lpApplicationName is NULL, the module name portion of lpCommandLine is limited to MAX_PATH characters.

Some other discussion (I haven't now its text or URL. Need weekend to recover it) states that it happens because second parameter works following console rules, and IO file system management, but by using first parameter (app name) + second parameter (app parameters), Create process follows device management rules, and there is no MAX_PATH limits. This is the reason we are trying to use a full implementation of such API. Have you tried this way? We does not get it implemented completelly. Good in some cases, bad and extrange results in other. It seems we have problems with the correct charset implementation, or something like that.

[George Jeffcock]

Only use the second parameter.

 

But when learning how to use CreateProcess function (Windows)  the supplied error handling was a life safer as I can not have this fail in AutoTestBox - Stella Tools (CA Plex Developer Tools)

 

What does your error handling say

[Legacy User]

usually we get a very generic error 269. The worst case is when does not generate error at all, but interprets erroneously the parameter string:

Create executes ob600RC but misunderstand parameters:

background message tells that GetLastError() = 0 ("Ultimo error obtenido"), but GetExitCodeProcess() = 259 ?. It means that Create process ran OB600RC (the command we launched), but...

...it does not get properly parameters ("2015-01-01" correspond to the first parameter after returned status passed to a given Plex function).

Passed parameters were:

App, parm 1, CMDIIN, parm2, CURDIR, not used (passed as NUL). However, by omitting "2015-01-01" (function input parameter), it works well. Several other examples, by using Excel, IE, Chrome,...everyone different.

[George Jeffcock]

what if you made the date parameter into the Plex function a text field...lets identify where this is going wrong.

 

Lets remove the complication if it exists that the input date being the factor breaking the runtime

[Legacy User]

Almost done...Testing several different scenarios , by now moderatelly optimistic...We have received this answer at StackOverflow: http://stackoverflow.com/questions/32777485/c-winapi-createprocess-issue-with-command-line. In sum, we follow their reccomendations, and added at front of command line, a call to application name. Now second parameter looks like this:

"[full path of app/app name (in our case ob600)]" <blank> full list of parameters (including dll name). We repeated first parameter, putting it at command line,  ahead of remaining function parameters. Parameters are passed well and correctly understood.

With regards

Jorge Ubeda

[Legacy User]

Lenn Thompson marked George's solution as correct, but I want to state an exception: Indeed this solution works, and so did in our own case since a couple of years ago. The problem is with first parameter, and this solution circumvelts it  There is an important limit by using only first parameter: it is limited to the length declared by MAX_PATH. On the contrary, by using first (application name) and second parameters (string of parameters from application executed), this limit does not exists, and limit is 32768 characters. In our case, for a long time it was impossible to get this api working by using both parameters, and this was our problem, and the one experienced for many users of CreateProcess api, apparently. For that case it seems the commented discussion at StackOverflow gave us the probably full solution.