dmurdoch@watstat.waterloo.edu (Duncan Murdoch) (11/01/90)
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
jamiller@hpcupt1.cup.hp.com (Jim Miller) (11/02/90)
>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 >---------- That statement obviously is the opinion of the author and has nothing to do with reality -- unlike my statements :-) So you think every programmer should do their own expansions? And everyone can be different except those who don't do it at all? If one wants it literally, "make it literal". I've got better things to do than fight inconsistent interfaces and waste time coding something that should be done for me. jim miller jamiller@hpmpeb7.cup.hp.com (a.k.a James A. Miller; Jim the JAM; stupid; @!?$$!; ... ) Anything I say will be used against me ... But my company doesn't know or approve or condone anything of mine here.
toma@tekgvs.LABS.TEK.COM (Tom Almy) (11/06/90)
In article <1990Nov1.142426.19559@maytag.waterloo.edu> dmurdoch@watstat.waterloo.edu (Duncan Murdoch) writes: >> From article <22926@grebyn.com>, by jmbj@grebyn.com (Jim Bittman): >> > 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?" >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. Horray! I wrote a reply to jmbj@grebyn.com stating this, and then noticed many followups *not* noticing this. The reasoning actually dates back to the format of CP/M executable files, and that MS/DOS was really a CP/M clone, not a *NIX clone like many people wish. >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. If you use 4DOS, an environment variable contains the (up to 255 character) command line. >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. Although *NIX freaks will flame this, it is true, IMHO. How I hate to have to quote things to keep the shell from parsing the line. As far as the saving coding time and consistant user interface arguments go, you can always call an OS function to constantly parse the command line if appropriate (the DEC RT-11 system had such a call) -- even MKS toolkit does this with the GLOB program. Tom Almy toma@tekgvs.labs.tek.com Standard Disclaimers Apply
pipkinsj@cpqhou.uucp (Jeff Pipkins @Adv Dev@SE hou ) (11/09/90)
If you want stdin to be a binary file, use this in your program: setmode(fileno(stdin), O_BINARY); Same goes for stdout. -- Jeff D. Pipkins (uunet!cpqhou!pipkinsj) My disclaimer: My opinions do not necessarily reflect those of my employer. Papaw's disclaimer: I've already told you more than I know.