[Mono-list] Starting processes with parameters from Mono 0.31and mono-0.31.99.20040331

[Jonathan Gilbert]

At 10:12 AM 05/04/2004 +0200, Gonzalo wrote:
[snip]
>MS seems to run 'cmd /c  yourprogram yourparameters'. The diference is
>that cmd on windows also handles something like 'cmd /c file.pdf' by
>opening acrobat reader and stuff like that.

Actually I'm pretty sure the MS implementation use the Win32 API function
"ShellExecute". Windows treats files in a very slightly object-oriented
manner; file "classes" are defined in the registry (this is what
HKEY_CLASSES_ROOT is all about), and associations are made between
extensions and classes (if you look up '.txt' under HKCR, you'll see that
it maps to the class 'txtfile'). Each class has a set of "verbs", each one
of which defines a certain action that can be performed with the file. Each
verb has a name and a command-line which is expanded using the environment,
as well as %1 => the full path and filename of the file being executed. If
you look up HKCR\txtfile\shell\open, you should find that its value is
something along the lines of 'notepad.exe "%1"'. The default verb can be
specified, but if it's not, the default of the default is the "open" verb.
Once the class and default verb have been obtained from the registry,
ShellExecute then spawns the specified application with the parameters that
result from expanding the command-line string from the registry.

Note that several worms have played with this to alter the association of
.exe files; Windows is flexible enough to allow this, but it is of course a
very bad idea :-) As for actually running programs, Windows' CreateProcess
API can take a file with any extension (or with no extension); this is
independent of the registry file class associations.

Obviously, this concept is very alien to vanilla unix, but some of the X
environments have added similar systems. I'm not sure exactly how
binfmt-misc works, but it seems to also operate along a similar line: a
file can be shunted to an "interpreter" (Acrobat Reader being an example of
an interpreter for a .PDF file), based on some criteria. I haven't done
much research on this, so I don't know the details :-)

If anyone is interested in approximating ShellExecute for unix systems, it
is important to note the method in which ShellExecute searches for the binary:

- If the first "word" on the command-line is enclosed in double-quotes, it
is the only thing that is checked:

ShellExecute("\"c:\\Program Files\\Fubar Corp\\Example 1.exe\" params"); //
for demonstration purposes only; some parameters are missing

This can only execute the file "c:\Program Files\Fubar Corp\Example 1.exe".

- If the first word is not enclosed in double-quotes, then things get
interesting :-) ShellExecute searches for a binary file by treating the
first 'n' words, where 'n' is looped up starting from 1.

ShellExecute("c:\\Program Files\\Fubar Corp\\Example 1.exe params"); //
dangerous!

For this command-line, ShellExecute searches for files whose name (w/o
extension) are each of the following, in this order:

"c:\\Program" (.exe, .com, .bat, .cmd, ..)
"c:\\Program Files\\Fubar" (.exe, .com, .bat, .cmd, ..)
"c:\\Program Files\\Fubar Corp\\Example" (.exe, .com, .bat, .cmd, ..)
"c:\\Program Files\\Fubar Corp\\Example 1.exe" (.exe, .com, .bat, .cmd, ..)
"c:\\Program Files\\Fubar Corp\\Example 1.exe params" (.exe, .com, .bat,
.cmd, ..)

Any one of those first 3 can be used to "hijack" the program, such that
badly-written code using ShellExecute will run the wrong binary! I believe
the MSDN documentation for ShellExecute warns about this issue.

Jonathan