🚀 go-pugleaf

In article <OTTO.90Nov1132529@tukki.jyu.fi> otto@tukki.jyu.fi (Otto J. Makela) writes:
>In article <11280@hubcap.clemson.edu> lsalomo@hubcap.clemson.edu (lsalomo)
>writes:
>   From article <22926@grebyn.com>, by jmbj@grebyn.com (Jim Bittman):
>   > A (unix) friend of mine is attempting to port an application, and is 
>   > getting frustrated, not that I can blame him.  Most his complaints are 
>   > quite valid.  One question (to which I had no answer) was:  
>   >    "Why wasn't the 128 byte command line limit fixed between DOS 
>   >     versions 1.0 and 1.1?"
>
>   Because real people use DOS 3.x+  *grin*  ;)
>
>All right, so now the question is: why wasn't it fixed between DOS versions
>3.01 and 3.10 ?  Or between versions 3.30 and 4.01 ?  I hate MicroS*t for
>the fact that no significant improvements have gone into the command processor
>since version 2.11 !

The answer is really quite simple:  it would break existing programs.  The 
design for the command line is really inflexible:  it's supposed to be 
located at offset 128 in the PSP segment, and .COM programs are guaranteed to 
load at offset 256 in the same segment.  The command line could be lengthened
for .EXE files, but not for .COM files.

Now, my opinion:  there's not much wrong with a 128 byte limit.  People rarely
want to type lines that long (and rarely get them right when they do); it's only
programs and shells that like to create such long command lines.  Let them
figure out their own way to pass arguments to programs that can accept lots. 
Response files work well, for example.

As to the idea of the shell performing filename expansion:  what a bad design
that is.  Programs should see what the user types, not what the
shell transforms it into.

Duncan Murdoch