Path: utzoo!attcan!uunet!samsung!think!snorkelwacker!mit-eddie!uw-beaver!ssc-vax!uvicctr.UVic.CA!sbanner1
From: sbanner1@uvicctr.UVic.CA.UUCP (S. John Banner)
Newsgroups: comp.sys.ibm.pc
Subject: Re: Need input for future DOS release
Message-ID: <992@uvicctr.UVic.CA.UUCP>
Date: 27 Mar 90 18:29:55 GMT
Organization: University of Victoria, Victoria B.C. Canada
Lines: 118

>BACKGROUND:
>
>1)  *** Gordon Letwin asks for desired DOS enhancements. 
>2)  >>  I replied with a couple of thoughts, to get a discussion started.  
>3)  >   Marshall Buhl (marshall@wind55.seri.gov) added some good ideas.  
>-------------------------------------------------------------------------
>
>>>smw@maxwell.Concordia.CA ( Steven Winikoff ) writes:
>>>
>>>In any case, off the top of my head, some things I'd like to see:
>>>
>>>1) A way that works, consistently across all commands (built-in or otherwise),
>>>   to change the switch character and path separator character (so that I can 
>>>   make DOS look more like Unix!)
>
>> Marshall Buhl (marshall@wind55.seri.gov) writes:
>>
>>This would be a bitch.  I know I hardcoded these characters in my sorted
>>directory listing program.  I'm sure others have too.
>
>I'm sure you're right; I never said it would be easy, or even possible, to do; 
>it's just something I'd like to see.  For programs where you don't have source
>and which embed paths with backslashes, presumably either you'd wrap the program
>with a batch file which changes the switch and path separator back to - and \
>respectively, or else just not ever change them in the first place.  I agree
>that it would add complexity, but I think it can be done...  (I may, of course,
>be wrong!)
Definitely a big problem, but if the DOS utilities started using it,
the others would follow pretty quick.  You don't have to try fixing
things in a way that non-DOS (i.e. programs that come with DOS) programs
understand (beyond the current undocumented call), just make that
undocumented call that everyone uses actually work, and make the DOS
utilities use the UNIX standard.

>>Have you considered using the PROMPT command to remap those two keys?
Don't do it, it's not worth the hastle.

Annother request that came in here somewhere that I will certainly
add my vote for is real wild cards.  This is the single biggest
defisioncy that DOS has ever had (IMHO anyhow).

>>Additional requests from me:
>>
>>5)  A decent batch language with console I/O and better branching.  Also
>>    integer and real math.
>YES!  This could be fully upward compatible, even.
Yep, this would be a good one.

>>6)  The ability to SET PATH=C:\NEWDIR;%PATH% outside of a batch file.
Yep, nice and fairly easy to impliment.

>>7)  A 4 GB address space.  Aw, heck.  Let's go for a full TB.  ;-)  I
>>    remember when 64K seems like more than anyone could ever put to use.
>Now, that really would be difficult; you'd have to find some way of remapping
>the space currently used above 640k...  but I agree it would be wonderful if
>it could be done without fundamental changes to the nature of the system.
Difficult yes, but not that hard.  Use 32Bits for the length of a memory
block (no more worse on compatability than the FAT change in DOS4.00),
and have an Extended Allocate Memory function that will return an
extended segment address (giving preference to memory beyond the first
Meg), and all the current programs run just fine, and new programs can
use as much as the longest available segment.  As for relocating DOS,
that doesn't have to happen, because you can just mark the ``memory
block'' from A000:0000-F000:FFFF, as used, and every one is happy.

>>8)  32-bit operating system.  Hooks for future 64-bit.
Get serious folks, I know I don't want to be using DOS37 in the year
2000.  Just update it so that it is still usefull, as there are still
lots of people for whom it is the best alternative due to the hardware
they have.  Just work on phasing DOS out, while phasing in a real OS
(no, not OS/2; I would be happy with UNIX myself, but I don't expect
to see that one do it either).

>>10) Verified deletes.  Branch deletes.  Move files without copying.
>YES!  How hard can it be to manipulate directory entries??
Yep, definitely a good one.

>>12) Windows built in.
>Who could argue with that?
I could.  That's why I refuse to by a Mac.  Don't do it.

>>13) A good, standard way to load/unload TSRs.  Also, be able to use holes 
>>    in RAM.
>Again, difficult but worthwhile.  Unloading an arbitrary number of TSRs is
>a *hard* problem (at least, it is if you haven't saved the machine state
>before each one was loaded...)
Yep, that would be usefull.

>>15) Push and Pop directories.
>Once you've used these on Unix, it's hard to be without them.  They're also
>extremely useful, needless to say, in batch files that need to change their
>working directory!
Yep, real nice.

>>16) Virtual memory management.
>Indeed!  Why not?
Indeed, if you have access to the full memory (see above), it shouldn't
be THAT much harder to add, though maybe as a device driver would be
sufficent...

>>Gee, maybe I should try Unix or a Mac.  8-)
I plan on using Unix, just as soon as I can afford my own Unix box, but
as I said above, I would rather spend my life writing software for a
256K, 4.77Mhz IBM 3270/XT (if you have never used one, you don't know
the meaning of a slow IBM/PC yet), using MicroSoft C5.1 than have to
use a Mac for a significant portion of my work (Oh, No, I think my
biases are peeking through :-).  But seriously folks, that is one of
the biggest advantages of the PC, over the Mac.  If you don't like
COMMAND.COM, you can always write/buy a replacement, and use that
instead, whereas on the Mac you are pretty much tied to that hideous
mouse.

                      S. John Banner

ccsjb@uvvm.UVic.CA
ccsjb@uvvm.bitnet
...!uw-beaver!uvicctr!sol!sbanner1
...!ubc-vision!uvicctr!sol!sbanner1