30+ Reasons Why You Should Say MsDog and not MsDos.
Also known as MsDog -- a study in
autoincompatibility, inconsistence, poor design, and general lack of
thought.
Note: I have tried to be fair here by not mentioning design choices that
are simply different from what others have done. Therefore I don't have an
entry just for using a slash and not a dash as switch char. That is mostly
a matter of what you like.
The default shell as mentioned in a lot of the items below is
"Command.com". You will notice that a lot of the blame falls on it.
Ok, here we go -- start counting...
File System
- The file system's limit of 8+3 characters stinks.
- The execution time for a seek in a file is proportional to the offset
seeked to. Seeks in a directory are also proportional to the number
of files in the directory.
- Some file names like
huge.filename
are silently truncated
to the 8+3 limit while others like lots.of.dots
or
.emacs
simply are illegal. (Actually, .emacs
is only illegal in some versions of MsDog, I believe.)
- You can corrupt the file system with system calls with perfectly
valid (and reasonable) arguments.
- The read-only bits for directories are never used.
- You can rename files but not directories.
- The file system is limited to approximately 2^16 allocation units. This
means that as disks become larger, so do the allocation units and the
amount of disk space that cannot be used.
Kernel
- Command lines cannot be longer than 126 characters. This makes it more
fun to port utilities that execute other programs. As an example take
a look at Gnu Make.
- Pipes,
foo|bar
, are implemented by
>tempfile
and <tempfile
.
- MsDog is not reentrant, nor is it protected against
attempts of reentrance.
- You can open a file like
c:\foo\..\config.sys
even if you
don't have a foo
directory.
- Text file read routines recognize a special character
(
0x1A
) as a magic cookie that causes all further data to
be ignored. A corrupted byte can cause part of a file to be lost
without warning.
- When writing to files in text mode, bytes
0x1A
are simply
ignored.
- The end of a text line is represented by two characters (CR/LF).
This is actually ok (just a design choice from way back), but it would
be a lot better if the utilities did something useful on files
containing only LFs.
Shell
- Redirection doesn't work with batch files.
- Redirection doesn't work with the "For" command.
- You cannot redirect
stderr
with the default shell.
- The default shell doesn't pass a child process' return code
on to its caller. The internal commands don't return an error code.
- The default shell disregards case of environment variables
while the rest of MsDog doesn't. Also it doesn't
allow setting an empty environment variable.
- Executablility is based on file names, not on file attributes. Actually,
this is only really true for "Command" because any file is considered
executable by the MsDog kernel. It is, however, known
to be rather unsafe just to execute an arbitrary file as a series of
machine instructions.
- You can only expand environment variables from batch files, not from
the command line.
- Almost every version of MsDog has its own little
perculiarities with parsing of commands. When, e.g., was the @-prefix
convention introduced? Which versions allow you to echo a
greater-than-sign?
- You cannot escape the special characters of the shell. In newer versions
you can put them inside double quotes, but -- guess what -- the quotes
are passed as part of the argument.
- Batch programs can take more than nine parameters, but you cannot refer
to the tenth before you give up access to the first (et cetera).
- You cannot pass certain characters (like "=") as part of the command
line to batch programs.
- Not all versions of MsDog can echo an empty line with
the built-in "Echo" command.
- Running a batch file from a batch file means exec-ing it by default,
so the rest of the first batch file is never seen. This actually means
that you cannot use batch files as wrappers if you want to fix some
behaviour.
- The default shell doesn't even think of exiting when end-of-file is
encountered on standard input. That this hangs the system doesn't
seem to bother anyone.
- The "Copy" command in the default shell will not copy a zero-length
file -- but it will still delete a file of that name in the destination
directory.
- The remainder of a "Rem" statement is not completely ignored.
Rem > foo
will create a zero-length file.
- Unlike any other text file output routine, redirection of console
output with append (e.g.,
Dir >>foo
) will not
overwrite a 0x1A
character if it is at the end of the
original file; instead it will just append the new data behind it.
This will cause all appended data (from this or any subsequent
program) to be lost.
Utilities
- Most MsDog commands refuse to understand
-s
as an option specifier while others like "Move" always
accept it -- undocumentedly, of course.
- Silly limits are all over the place: "Sort" refuses to sort more than
64K; if "Fc" doesn't find differences early enough then it invents some;
the shell can only set
PATH
to strings less than 128
characters; file commands like "Del" can only work on one file
specification.
- At least five different programs for packing executables have been used
for the lastest version of MsDog. The packers make it
a little bit more difficult to patch binaries. Just a little.
- The "Debug" program has not been updated to understand the instructions
of the 186, 286, 386, 486, Pentium, 287, and 187/387 processors. For
some versions of debug add 8087 to this list.
- Utilities like "sed" are not provided with MsDog so
you cannot rely on users having them. You cannot rely on, say, "Edlin"
either because not all MsDog versions have that
either. The problem is that you simply cannot send you users a script
file because they lack a common interpreter.
- Many utilites from MsDog check that they run under the
version of MsDog that they were compiled for, even if
they use only documented features and would work perfectly well with
any version of MsDog since 2.0. I can understand this
for low-level software like "Format", but it is really stupid for
"Backup" and "Restore".
- Files created by "Backup" can usually only be read by the corresponding
version of "Restore", making backups useless when trying to go to
a different version of MsDog (or possibly even a
different machine).
Bonus reason regarding PcDog, IBM's own version of
MsDog
- Some versions of PcDog have been known to explicitly
check that the harddisks in the system are prepared with
PcDog and not MsDog. If
not, then the harddisks are simply ignored.
This list is copyright 1994, 1995 by Morten Welinder.