Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!mailrus!cornell!calvin.spp.cornell.edu!richard
From: richard@calvin.spp.cornell.edu (Richard Brittain)
Newsgroups: comp.sys.ibm.pc
Subject: Re: Need input for future DOS release
Message-ID: <1990Mar29.035525.5149@calvin.spp.cornell.edu>
Date: 29 Mar 90 03:55:25 GMT
References: <26909@ut-emx.UUCP> <261106AB.2583@maccs.dcss.mcmaster.ca>
Reply-To: richard@calvin.spp.cornell.edu (Richard Brittain)
Organization: Cornell Space Plasma Physics Group
Lines: 42

In article <261106AB.2583@maccs.dcss.mcmaster.ca> cs4g6ag@maccs.dcss.mcmaster.ca (Stephen M. Dunn) writes:
>In article <26909@ut-emx.UUCP> boerner@ut-emx.UUCP (Brendan B. Boerner) writes:
>$2) A TSR Manager.  Programs written to use it would let it know what
>$resources that they need (e.g. what interupts they would like to be
>$activated on).  [...]
>
>   This is a nice idea, but it's a bit late to retrofit DOS with a TSR
>manager.  Think about how many TSRs there are out there - even if all
>TSR makers switched to using this immediately, the number of older
>TSRs would far outnumber those newer ones for years.

This is obviously going to be true for all enhancements.  If we think like
this, then there really isn't much point in bothering.  There are lots of
things that could have been done a long time ago, before such a large base
of software invented incompatible ways of doing the job, but that is no
reason not to improve on things.  

>$6) A larger command line limit.  This would allow paths with length
>$greater than 128 chars.
>
>   This would be nice ... but it would be internal to DOS.  The command line
>passed to programs is found in the PSP, which has been the same size since
>day 1.  The only way around this would be to have DOS put the command line
>in two places - one being the PSP, for backwards compatibility, and the
>other being ... where?  It can't be static because then it would be over-
>written if you shelled out from your program and ran something else.

This doesn't sound so hard - the program loader allocates a memory block
for the command line - as long as needed, then makes the PSP.  Put the first 127
bytes in there as normal for old programs, and put the segment address of the
argument block somewhere else in the PSP (there are still some "reserved" words
I think).  When the program terminates, the shell, or the program terminate
service deallocates the argument block.  I presume that something like this
has to be done in unix ?.  The startup code for DOS-5-aware programs
reads the new argument block when building the argv array, or whatever
your favourite language provides.  Compiler vendors would have to ship a new
startup object module - no big deal.

Richard Brittain,                   School of Elect. Eng.,  Upson Hall   
                                    Cornell University, Ithaca, NY 14853
ARPA: richard@calvin.spp.cornell.edu	
UUCP: {uunet,uw-beaver,rochester,cmcl2}!cornell!calvin!richard