Message-Id:	<9604110927.AA15423@vlsi3>
To:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
Cc:	djgpp-workers AT delorie DOT com, paik AT vlsi3 DOT 3dfx DOT com
Subject:	Re: Long command lines
In-Reply-To:	Your message of "Thu, 11 Apr 1996 11:57:38 +0200."
	<Pine DOT SUN DOT 3 DOT 91 DOT 960411115408 DOT 27524T-100000 AT is>
Date:	Thu, 11 Apr 1996 02:24:31 -0700
From:	Sam Paik <paik AT 3dfx DOT com>

Eli Zaretskii writes:
>> All the information I have on this was derived from the
>> Win32 SDK documentation that came with MSVC 4.0 followed
>> by experimentation.  I do not have the answers.
>
>I don't even have these two MS products, so any piece of info you *do*
>have (or can find out by exploring) will be of help.  Without knowing at
>least some of the answers, IMHO there is no way of adding such support in
>a safe way. 

Well, to read a long command line, (say gcc gets called from nmake),
if the psp command tail length byte is 127, get the real command
line from the environment variable.  That seems safe.  Under normal
DOS, this length byte should never be more than 126.

Writing a long command line seems to have two questions that need
to be answered:

  How do we ensure we don't overflow environment space when
  setting up the command line? (This may be trivial for you DOS folks)

  Does a normal dos application do something safe when it gets
  a command line with a length of 127?  I don't think Win95
  does anything special to detect that an app only understands
  normal DOS command lines.

To recap Win32 long command lines:

The PSP command tail, where the command line gets placed, is
128 bytes long including the initial length byte and the trailing
0x0D (return).  Thus in old dos, the maximum length of a command
line is 126 bytes.

Win95 allows spawned programs to get long command lines by placing
a length of 127 in the length byte, filling the psp tail with the
initial 126 characters of the command line, followed by the trailing
0x0D.  Then the environment variable CMDLINE gets the full command
line.

This differs from the Win32 documentation in that the Win32
documentation states that the CMDLINE variable gets the remainder
of the command line, not the entire line.  This proved not to be
the case when I tried it.

In any case, command.com does not seem to play a role at all.
It still has the *@%$! short input buffer.

Sam

- Raw text -