Christopher Head wrote:

>|> I assume that the command-line handling is hidden in run-time libraries
>|> that come with the software development environments for Windows.
>|
>| That's probably correct, and is probably the same as it is in *ix
>| environments.
> 
> This is absolutely true in Windows. At the Win32 API level, a function
> called GetCommandLine() passes you a single string. It's up to you to
> break the string up into pieces. 

> In Unix, the splitting of command-line arguments is, indeed, done by a
> shell. The system call that allows a process to invoke a program file on
> disk is execve(). You pass execve() not a command-line string, but an
> ARRAY. That array becomes the argc/argv directly, with no translation at
> all. You also must pass execve() the name of the program to execute,
> separately. There is no searching of $PATH, you must pass a full
> pathname. There is no command-line substitution, if one of the elements
> of the array is "*.txt", then the invoked binary sees "*.txt" in argv.

Thanks for clearing this up. I think that in Windows, there is no
substitution in the arguments either when using CreateProcess(). It may
prepend a path to the executable name, though. 

It may be here where there is a chance of not handling quoting of paths
correctly when porting an application to Windows.

> There is a library function called system() which is specified by ISO C,
> which accepts a command-line as a string instead of as an array. This
> function is not a system call into the kernel, it's implemented in the C
> runtime library by executing the shell and having the shell parse the
> command line. 

FWIW, this is similar on Windows (not surprisingly, as this is how the
system() function is defined in the C language): a call to system() goes
through the shell defined with COMSPEC.

Gerhard

-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist