17 Dec
2011
17 Dec
'11
3:03 p.m.
On Sat, 17 Dec 2011, Mouse wrote:
True. It's entirely driven off file contents. I
don't know of any OS
where execve() pays any attention to what's in the pathname beyond
handing it to the filesystem layer to locate the relevant file.
In MS-DOS,
COMMAND.COM compares what was input to the list of internal commands, if
it matches, it executes that;
if no match to internal commands, then it checks current DIRectory for
.COM;
if no .COM, then it checks for .EXE;
if either .COM or .EXE was found, then it IGNORES the extension and looks
for "MZ" as the first two bytes of the file. If there IS "MZ", then
it
processes it as a .EXE file even if the extension is .COM If there is no
"MZ", then it sets up a PSP etc. copies the content of the file to
location 100h and jumps there. Thus, the 'M' 'Z' code
sequence can not be used in .COM files. Stories of the origin of the
choice for "MZ"? "Mark Zbikowski"?
if neither .COM nor .EXE were found, then it looks for .BAT. If found,
that is processed as a batch file
if no .COM, .EXE, nor .BAT are found, then it repeats the process in the
next DIRectory of the PATH.
If it exhasusts the PATH with no .COM .EXE .BAT, then it says, "Bad
Command or Filename".
Thus, an internal command can not be replaced by a user program (without
stepping on the COMMAND.COM file), and files named .COM are processed
before files named .EXE. indisunirregardless of whether the .COM V .EXE
structure matches the extension.
Where do _you_ draw the "this is part of
Unix" line?
THAT may be part of the ongoing arguments.