Path: utzoo!utgpu!news-server.csri.toronto.edu!helios.physics.utoronto.ca!ists!yunexus!geac!maccs!cs4g6ag
From: cs4g6ag@maccs.dcss.mcmaster.ca (Stephen M. Dunn)
Newsgroups: comp.sys.ibm.pc
Subject: Re: Need input for future DOS release
Keywords: future DOS release
Message-ID: <260E5BA2.4917@maccs.dcss.mcmaster.ca>
Date: 26 Mar 90 18:12:49 GMT
References: <53686@microsoft.UUCP> <2017@clyde.concordia.ca> <1990Mar22.202023.25752@seri.gov> <2019@clyde.concordia.ca>
Reply-To: cs4g6ag@maccs.dcss.mcmaster.ca (Stephen M. Dunn)
Organization: McMaster University, Hamilton, Ontario
Lines: 59

In article <2019@clyde.concordia.ca> smw@maxwell.Concordia.CA ( Steven Winikoff ) writes:
$>Have you considered using the PROMPT command to remap those two keys?
$No, mainly because I don't know how to do that.

   Don't bother.  You need ANSI.SYS (or equivalent) for this and it will
slow down your screen I/O.  The idea is to embed an ANSI sequence to
remap a given key into your prompt so that ever time you're at the DOS
prompt, it ensures that your keys are mapped the way you want them.

$It is!  But not all applications are created equal, and not all developers know 
$what they're doing.  Most do, but many older programs don't know about things
$like environment variables, or bother to remember the directory they were called
$from originally...  (Can you say "WordStar"?  I thought you could.  Pre-5.x, of
$course.)

   The reason is that you can't find out what path you were executed from
unless you're using DOS 3 or better.  Of course, this is no excuse for
being too lazy to add code to check for DOS 3 and, if so, keep track of
where you were invoked from ...

$>6)  The ability to SET PATH=C:\NEWDIR;%PATH% outside of a batch file.
$Another good idea.  It really wouldn't cost anything to increase the size of
$the command line buffer, would it now?

   No it wouldn't ... except that then users would expect that they could
pass a huge command line to an external command and would start complaining
of a bug in DOS.

$>10) Verified deletes.  Branch deletes.  Move files without copying.
$YES!  How hard can it be to manipulate directory entries??

   Moving files without copying, for example, has been part of the DOS
RENAME function call since the idea of paths came along.  It's just that
COMMAND.COM's designers decided they didn't want us to be able to do that.

$>12) Windows built in.
$Who could argue with that?

   As long as I'm allowed to wipe it off my hard drive and it doesn't
increase the price of DOS, I don't mind.  But I don't want to be forced
to pay for it and have it clutter up my memory and hard disk and degrade
system performance just because I may want a new version of DOS.

$I wonder if it would pay for Microsoft to license some of the Norton Utilities
$(LD, FS, FA, etc. come to mind at this point...)

   Most of those really aren't hard to write ... the only reason people
are so thrilled with many of them is that Norton did them right, and DOS
either didn't do them, did them wrong, or did them far too late.  Writing
a program like FA would take an experienced programmer a couple of hours.

   But you do have a good point.  Microsoft should have a close look at
the features of various toolkit packages, make a note of some of the things
they do, and write their own to do those functions.
-- 
Stephen M. Dunn                               cs4g6ag@maccs.dcss.mcmaster.ca
          <std_disclaimer.h> = "\nI'm only an undergraduate!!!\n";
****************************************************************************
    "So sorry, I never meant to break your heart ... but you broke mine."