bug#21323: start-process rejects .com executables

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sun, 23 Aug 2015 15:06:55 +0200
> From: Björn Lindqvist <bjourne@gmail.com>
> Cc: 21323-done@debbugs.gnu.org
> 
> 2015-08-22 21:21 GMT+02:00 Eli Zaretskii <eliz@gnu.org>:
> >> I found this bug on windows ver 24.5.1. If you try to run a .com file:
> >>
> >> (start-process "X" "Y" "c:/Windows/System32/tree.com")
> >>
> >> You get: "Spawning child process: exec format error"
> >
> > Indeed.
> >
> >> The cryptic error appears to be a result of the .com extension.
> >
> > No, it's because .com programs are run via cmdproxy.exe, and there's a
> > bug in computing the directory where we look for it.
> 
> What is the reason for that?

We don't know how to distinguish between DOS .com programs and the
other kind.  DOS .com programs must be run via cmdproxy to work around
some subtle problems in running DOS programs from a Windows program
(including, but not limited to, standard I/O redirection and killing
subprocesses).

> As you know, on modern windowses there is
> no difference except for the name between .com and .exe files.

But the user could bring a .com program from DOS, and we have no means
of telling one from the other.

> If there was an option for it, I'd set it so my binary is not run
> through cmdproxy.exe.

Why do you care?  Barring bugs, cmdproxy is transparent to the
programs in invokes.