Calling CreateProcess() directly is never a good idea. Using it properly is complicated and to make matters worse the function is buggy because some parameters do not behave as described in the help. CreateProcessW has an extra bug that CreateProcessA version doesn't which crashes your program when you do a particular thing that the help says is acceptable.
For your blue pill enjoyment there's WinExec() which claims to be depreciated but it seems to work quite well. There's ShellExec() that I use for URL launching that works pretty good too. There's also the C library exec and spawn functions which don't seem too well suited for Windows programmers.
Then there's the messy process of splitting and joining command lines for which I could find no API to help.
Stop now and take the blue pill while you still can.
WinExec Function
Note This function is provided only for compatibility with 16-bit Windows. Applications should use the CreateProcess function.
Riiiight! I fell for that trick too and ended up coding the whole thing for WINDRES posted here on the Pelles-C forums. The upside is that I have a complete set of functions for command line management. Let's see how deep this rabbit hole goes.
Ok, so you want to use CreateProcess because the help told you to. 3 rules:
1. Assume that the writer of the CreateProcess Help is more incompetent than the writer of CreateProcess.
2. If it does nothing it's your fault for not surrounding CreateProcess with something else that is required.
3. If it crashes it's your fault because you believed something in the help that is not true.
You'll need to create a spawn function so you have something to show for your work once you get all the features working and bugs covered. You won't be writing this function from scratch because even without consideration for the bugs there are just too many things that need to be done to get basic functionality working. Start by finding the source for any spawn or exec function. The one I worked from is the one in the
OpenWatcom C library: //depot/openwatcom/bld/clib/process/c/dospnwnt.c. I also looked at the implementation of
ShellExec(),
WinExec(), and
msvcrt-spawn in the Wine code. Adapt the Watcom code to have more Windows friendly calling parameters then start working on the bugs.
To get you started here are a few lines from WINDRES.C.
// http://source.winehq.org/source/dlls/msvcrt/process.c
// if cszExeOrig==NULL then the executable is extracted from cszCmdLine
// if cszExeOrig contains no path info then the path is searched. Here is the search order
// WINDOWS/SYSTEM32 (or SYSTEM for Win9x)
// WINDOWS
// %PATH%
// The current directory is searched LAST.
// if you want to be assured that you are running a program from the current directory you must precede it with a path
// such as ".\\PROGRAM.EXE"
// These flags are selected to be cooperative with <process.h> _P_WAIT and friends, spawn, _searchenvWin, strtokcmdline, and _tcsdupRequote so they can be passed back and forth in a single variable
#define SEARCHENVWIN_NODUP (0x80) // The strings have already been strdup'd and can be written to, crashes will result if the caller has not provided writable strings
#define SEARCHENVWIN_NOEXECLEAN (0x100) // The quotes have already been cleaned from the Exe so don't do it again (this only applies when cszExeOrig is specified separately)
// Warning: if cszExeOrig is specified, the first parameter of cszCmdLine will be replaced with it.
INT_PTR __stdcall spawn(unsigned fPFlags, const TCHAR *cszExeOrig, const TCHAR * cszCmdLine, TCHAR * env);
When you think you have the last bug smothered you need to write a program that does nothing except for display argv[0] to argv[argp-1].
C:>TESTPROG.EXE 1 TEST XYZ Pelles
TESTPROG.EXE 1 TEST XYZ Pelles
Run it from CMD and you'll see the right values. Run it from your CreateProcess variant and if you made the right mistake which the help says is not a mistake, you'll see something missing:
1 TEST XYZ Pelles
Some programs are partially functional with that mistake and some won't work at all. Knowing that your callers want to launch programs without dealing with such problems you'll spend a few more hours coding around that Windows bug.
CreateProcess might be fine for compiler and debugger authors but for the rest of us that want to launch programs without the hassle it's a
train wreck!