Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!columbia!rutgers!ames!husc6!bu-cs!bucsb.bu.edu!madd
From: madd@bucsb.bu.edu.UUCP (Jim "Jack" Frost)
Newsgroups: comp.lang.pascal,comp.sys.ibm.pc
Subject: "Documented" MS-DOS stuff (was Re: Environment variables in Turbo Pascal)
Message-ID: <1080@bucsb.bu.edu.UUCP>
Date: Sat, 1-Aug-87 21:29:34 EDT
Article-I.D.: bucsb.1080
Posted: Sat Aug  1 21:29:34 1987
Date-Received: Sun, 2-Aug-87 10:48:07 EDT
References: <151@ivory.SanDiego.NCR.COM> <1690@bellcore.bellcore.com> <1013@vi.ri.cmu.edu>
Reply-To: madd@bucsb.bu.edu.UUCP (Jim "Jack" Frost)
Distribution: world
Organization: ODO (Organization for the Disorganization of Organization)
Lines: 79
Xref: mnetor comp.lang.pascal:229 comp.sys.ibm.pc:6257

In article <1013@vi.ri.cmu.edu> jfb@vi.ri.cmu.edu (John Brennen) writes:
>In article <1690@bellcore.bellcore.com>, tr@wind.bellcore.com (tom reingold) writes:
>> 
>> I just discovered an undocumented feature of the more recent
>> versions of DOS: it is at last possible to obtain argv[0].
>> 
>
>The method described is documented, quite clearly, in the PC-DOS 3.0 (3.1?)
>manual.  Maybe your documentation is missing it...  I can't even guess.
>
>Supposedly, this was considered a problem in DOS 2.0.  Personally, I've never
>had a real desire to know what argv[0] is.  MS-DOS doesn't support links
>(hard or symbolic), so each file has a unique name.  But I can see where
>you might want to be really friendly or something, and parse argv[0].

This is true, it is documented in the section discussing the Program
Segment Prefix in the PC-DOS Technical Reference Guide, at least for
versions 3.10 and up.

Anyone want to discuss other "documented" things?  I have a new
favorite "documented" thing that I found recently.

I am creating a program called "psh" (a csh workalike, generally)
that, by its very nature, must use the DOS Exec function.  In the
documentation for the Exec function, it clearly tells you how to give
the Exec function its parameter block, which includes a pointer to an
argument line.

Now, it never tells you about the parameter line, except that it
should be a string with a byte telling the length of the string in the
first position.  It does, however, tell you about it in the section on
the Program Segment Prefix.  The most interesting thing about this is
that the command line MUST BE IN A PARTICULAR FORMAT.  This is not
documented even once in the text, but instead in an oblique reference
in the map of the PSP.

The format REQUIRED by almost every MS-DOS utility is to have a space
preceeding every parameter in the line.  Even the first one.  The map
of the PSP tells you this as follows:

"parameter string with spaces preceeding each parameter"

or something very similar to this.  If you forget that space,
*nothing* works.  EDLIN won't.  CHKDSK will, but improperly (it won't
pick up the drive specifier).  Regular programs run fine, though,
since I presume whoever wrote them didn't make their code dependent on
that space (since it really isn't well documented).  I found it by
tracing the passing of everything to programs by both my program and
COMMAND.COM until I found a difference.

In addition, there is at least one mistake that is clearly documented
in the section dealing with invoking a command processor from a
program.  My manuals say that when invoking the command processor, you
should pass it the argument string FOLLOWED BY A CARRIAGE RETURN.
This will work, but is not DOS-standard.  There is no mention of the
leading space in this section, either, or even in the example
assembler code that they give you.  Note that COMMAND.COM does not
require the leading space, but it is about the only supplied program I
found that does not.

Another interesting note:

FORMAT will not work even with the space problem fixed.  Does anyone know
what they did when they made FORMAT?  I'd be very, very interested in
knowing.  I pass each program a perfect match for the command line and
also a good FCB if possible.  My FCB building routines fail in some
circumstances, but so do DOS's (although in a different manner) so I
don't worry about it.  It gets a perfect environment, too.  Yet it
gives me an "invalid parameter" error whenever I try to run FORMAT.
Tracing the COMMAND.COM parameters showed absolutely *no* differences
between my parameters and those passed by COMMAND.COM, yet FORMAT
works with COMMAND.COM and not with my program.  I suspect more
Microsoft assumptions on who is calling the program.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
          Jim Frost * The Madd Hacker | UUCP: ..!harvard!bu-cs!bucsb!madd
  H H                                 | ARPA:           madd@bucsb.bu.edu
H-C-C-OH <- heehee          +---------+----------------------------------
  H H                       | "We are strangers in a world we never made"