[net.micro.pc] msc 3.0

curl@wjvax.UUCP (Jim Curl) (03/18/86)

I recently implemented a patch to command.com in DOS 3.1 to enlarge the
environment space (the shell command method didn't work??).  I really needed
to do this because the paths in my environment variables had to be limited
and the drive specifications left out because the environment was full.

Upon implementing the change, I happily added paths to the INCLUDE environment
variable for MSC 3.00 only to discover that it caused the error

          Command line error: argument list for `p0.exe' too big

Apparently the INCLUDE variable is included in the total 128 characters allowed
as part of the command line.  I wasn't able to account for all 128, though.

Has anyone else encountered this problem?  Is there an easy way around it?

                                               -- Jim Curl
                                               -- San Jose

caf@omen.UUCP (Chuck Forsberg WA7KGX) (03/24/86)

In article <670@wjvax.wjvax.UUCP> curl@wjvax.UUCP (Jim Curl) writes:
>I recently implemented a patch to command.com in DOS 3.1 to enlarge the
>environment space (the shell command method didn't work??).  I really needed
>to do this because the paths in my environment variables had to be limited
>and the drive specifications left out because the environment was full.
>
>Upon implementing the change, I happily added paths to the INCLUDE environment
>variable for MSC 3.00 only to discover that it caused the error
>
>          Command line error: argument list for `p0.exe' too big
>
>Apparently the INCLUDE variable is included in the total 128 characters allowed
>as part of the command line.  I wasn't able to account for all 128, though.
>
>Has anyone else encountered this problem?  Is there an easy way around it?

MSC 3.0 copies the environment into the program's data space at startup to
allow getenv() to operate as it does on Unix.  A large environment will
reduce the space available for the stack and heap.  The solution is to use
an 80386 ("what the 286 SHOULD have been -Bill Gates) in 32 bit address mode,
but that requires hardware and software changes.

bmarsh@noscvax.UUCP (William C. Marsh) (03/25/86)

In article <314@omen.UUCP>, caf@omen.UUCP (Chuck Forsberg WA7KGX) writes:
> In article <670@wjvax.wjvax.UUCP> curl@wjvax.UUCP (Jim Curl) writes:
>>Upon implementing the change, I happily added paths to the INCLUDE environment
>>variable for MSC 3.00 only to discover that it caused the error
>>
>>          Command line error: argument list for `p0.exe' too big
>>
>>Apparently the INCLUDE variable is included in the total 128 characters
>>as part of the command line.  I wasn't able to account for all 128, though.
>>
>>Has anyone else encountered this problem?  Is there an easy way around it?
> 
> MSC 3.0 copies the environment into the program's data space at startup to
> allow getenv() to operate as it does on Unix.  A large environment will
> reduce the space available for the stack and heap.  The solution is to use
> an 80386 ("what the 286 SHOULD have been -Bill Gates) in 32 bit address mode,
> but that requires hardware and software changes.

Sorry, but Jim had it right.  P0 is the pre-processor for msc 3.0, and it
gets passed all kinds of junk on its command line.  If you have an INCLUDE
environment variable, it gets put into an -Idirectories list.  Plus, *all*
the pre-#defined stuff is also included as -Dsymbol.  Add any necessary
filenames, and you should see how big the command line is.  I found this
out while trying to write a 'cc' for it (I don't like all the garbage cl
prints out...).  If you want to see what is passed, write a simple echo
program, call it p0.exe in the current directory, then run cl or msc.

Since microsoft is on the net, maybe we could influence them to have
p0 look in the environment itself for INCLUDE's.  This would save some
valuable command line space for other things.

Then they could make lseek, ftell, and fseek work in text mode and end
up with a great compiler instead of just a good one.

-- 

Bill Marsh, Naval Ocean Systems Center, San Diego, CA
{arpa,mil}net: bmarsh@nosc
uucp: {ihnp4,akgua,decvax,dcdwest,ucbvax}!sdcsvax!noscvax!bmarsh

"If everything seems to be coming your way, you're probably in the wrong lane."

kneller@ucsfcgl.UUCP (Don Kneller%Langridge) (03/26/86)

In article <314@omen.UUCP> caf@omen.UUCP (Chuck Forsberg WA7KGX) writes:
>In article <670@wjvax.wjvax.UUCP> curl@wjvax.UUCP (Jim Curl) writes:
>>I recently implemented a patch to command.com in DOS 3.1 to enlarge the
>>environment space (the shell command method didn't work??).
>>
>>Upon implementing the change, I happily added paths to the INCLUDE environment
>>variable for MSC 3.00 only to discover that it caused the error
>>
>>          Command line error: argument list for `p0.exe' too big
>>
>>Apparently the INCLUDE variable is included in the total 128 characters allowed
>>as part of the command line.  I wasn't able to account for all 128, though.
>>
>>Has anyone else encountered this problem?  Is there an easy way around it?
>
>MSC 3.0 copies the environment into the program's data space at startup to
>allow getenv() to operate as it does on Unix.  A large environment will
>reduce the space available for the stack and heap.  The solution is to use
>an 80386 ("what the 286 SHOULD have been -Bill Gates) in 32 bit address mode,
>but that requires hardware and software changes.

?what?

I think what the original poster had in mind was that the include path is
passed in the argument list for p0.exe and if the path is too long cl.exe
can't exec p0.exe because the argument list is longer than DOS allows
(128 characters ?).  I have had the same problem when trying to use "many"
-Ddefines on the command line.  The argument list was short enough for
cl.exe to accept but the augmented list passed to p0.exe was too long.

As far as I know, there is no way around the 128 character argument list
limit.  It's intrinsic to DOS.  I wish they'd fix it.
-- 
	Don Kneller
UUCP:	...ucbvax!ucsfcgl!kneller
ARPA:	kneller@ucsf-cgl.ARPA
BITNET:	kneller@ucsfcgl.BITNET