Path: utzoo!attcan!uunet!samsung!zaphod.mps.ohio-state.edu!usc!snorkelwacker!spdcc!merk!alliant!linus!mwunix.mitre.org!jcmorris
From: jcmorris@mwunix.mitre.org (Joe Morris)
Newsgroups: comp.sys.ibm.pc
Subject: Re: Need input for future DOS release
Message-ID: <105174@linus.UUCP>
Date: 28 Mar 90 17:38:38 GMT
References: <53686@microsoft.UUCP> <25100009@adaptex>
Sender: news@linus.UUCP
Reply-To: jcmorris@mwunix.mitre.org (Joe Morris)
Organization: The Mitre Corporation
Lines: 60

>Microsoft is working on a major upgrade to DOS and I'd like to solicit
>input from the "power user" communitiy.  I've never met a programmer who
>didn't think that they could have "done it better" with regards to someone
>else's product, so here's an opportunity to enlighten us.

- A defined mechanism for unhooking chains of stolen interrupts.  IBM had
  this problem years ago with the (IBM-provided) "Service Aid" utilities
  for OS/360, and developed a procedure which allowed an interrupt stealer
  to back out of the interrupt chain even if a later program had stolen the
  same interrupt.

- Along the same line, permit a multiplex-interrupt TSR to disappear.  The
  most flagrant problem-causer is the CD-ROM Extensions, which occupies a 
  huge amount of memory.  Users who work hard at it have reported success
  at evicting MSCDEX from memory, but can't seem to get it to reinstall
  if they need it again later.  (Of course, a reboot fixes that problem.)

- Command aliasing and directory linking a la UNIX (tm and all that)

- A way for users to select different CONFIG.SYS files at boot time.  It took
  me about 60 bytes of patching in IBMBIO.COM to do this...

- Disk volume-level read-only status.

- User-installed exits from the system at interesting points.  This would 
  allow a user to intercept a command (e.g., 'foobar') and see if it should
  be given special treatment, such as invoking Mansfield's REXX interpreter
  instead of being limited to .bat, .com, or .exe modules.  Also, permit the
  exit to be established and withdrawn as necessary without having to reboot
  the system: this would allow applications to have specialized front ends
  without requiring CONFIG.SYS changes.

- Provide a way to load and unload device drivers as required without a reboot.

- Provide complete documentation as part of the basic package.  (Try finding
  the command documentation in the PC-DOS 4.0 package.)  This should include
  admitting to last-minute changes.  When was the last time you saw IBM ship 
  a README file?  Also, make sure that the outside of the package clearly
  shows the release and maintenance level of the product inside, such as
  DOS 4.0 vs. 4.01.

- Document *all* the control blocks (and paths to them) which can be reasonably
  expected to be of use to customers.  Even if the control blocks may be 
  altered in future releases, users deserve to be given the information they
  need for today's systems.  The decision to access a control block which 
  may change its format in the next release should be the user's, not the
  vendor's.  Example: where is the Microsoft or IBM documentation on how to
  find the device driver chain?

- Be prepared to admit that a problem exists with the product.  While Microsoft
  sometimes seems to take far too long to fix problems, you can get their
  support people to agree that you have found a bug.  It's almost impossible
  to get IBM to admit that problems exist with DOS.  Boca: that's a HINT!

- At the risk of being thrown out of c.s.i.p, vendors should take a clue from
  Apple's Macintosh line and bundle DOS with the hardware, with updates
  available to anyone who has a bundled system.  If they won't do this,
  at least provide a public mechanism for obtaining bug lists and patches.

Joe