exec.basic - comments please

["Mal Lansell" <mal@xxxxxxxxxxx>]

Following up the talk of an xPLExec application for launching
arbitrary executables, I propose the following schema:

xpl-cmnd
exec.basic
{
pid=num       //integer identifier (<2^32)
program=""    //executable filename (without path)
path=""       //path to exe (optional)
path=""       //as many as needed
args=""       //program command line argument (optional)
args=""       //as many as needed
}

xpl-stat
exec.basic
{
pid=num       //same integer as sent in the xpl-cmnd
status=[Failed][Started][Finished]
return=""     //extended info if status is failed or finished
}

The pid is a program ID - it is not the same as the Windows Process
ID, but is a user specified number to enable status messages to be
associated with commands from xPLHal without having to match the
entire message body.  If only one program is spawned at a time, then
feel free to just set it to the same value every time if you like.

Program is the name of the executable file to run, without any path.

As many or as few (none is ok) Path and Arg elements can be included
as needed.

Each Path item must contain only one piece of the path with no / or
\.  These will be inserted by the receiving application.

Each Arg item must contain only one command line argument.

The xPLExec application will attempt to spawn the executable, and
will respond with a status messages containing either status=failed
or status=started.  If status=failed, then the return item will be
set to one of the following values:

"argument list too long"
"invalid argument"
"program not found"
"program not executable"
"out of memory"

If the program runs fine, the an xpl-stat message with
status=started will be sent.  When the spawned program terminates,
another xpl-stat message will be sent, this time with
status=finished, and the return item set to the return value from
the spawned program.

Windows spawn functions also support specifying a set of environment
variables, but I couldn't see a good way of including those in the
schema, with all their potential oddball characters.  Hopefully that
will not be too much of a restriction.

Comments would be appreciated.

Mal