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