Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!sun-barr!newstop!sun!imagen!qmsseq!pipkins
From: pipkins@qmsseq.imagen.com (Jeff Pipkins)
Newsgroups: comp.sys.ibm.pc
Subject: Re: Stumpers
Message-ID: <75@qmsseq.imagen.com>
Date: 8 Jan 90 16:08:03 GMT
References: <21990002@hpvcfs1.HP.COM>
Reply-To: pipkins@qmsseq.UUCP (Jeff Pipkins)
Organization: QMS Inc., Mobile, Alabama
Lines: 44

In article <21990002@hpvcfs1.HP.COM> rexw@hpvcfs1.HP.COM (Rex Wickenkamp) writes:
>1)  I have access to a Compaq 386/20e.  This Compaq seems to have a problem
>    when exiting out of applications, as it will show an empty screen for
>    approximately 15 seconds, before returning to the DOS prompt.  Does
>    anyone have any ideas what I can use to check this puppy out?

The command interpreter, COMMAND.COM, has three parts: initialization,
resident, and transient.  The resident part consumes a block of memory
in low memory, above MS-DOS proper (if you can use that word with DOS ;->)
and just above user-installed device drivers.  The transient part is
loaded in high memory that is NOT allocated at all!  It is loaded in free
memory!  Applications are loaded above the resident part, and may
subsequently allocate and overwrite the transient part.  When the app.
terminates, control returns to the resident part, which then does a
simple checksum on the transient part to determine if it is still
there.  If the checksum works, control jumps into the transient part.
Otherwise, it is reloaded from disk.  This scheme is supposed to save
memory (at the expense of time), but also can be a major contributing
factor to the mysterious unreliability of MS-DOS.  Any application program
can legitimately allocate memory, swap any two bytes that just happens
to be in the transient part of COMMAND.COM, and exit.  Since a checksum
is used instead of a CRC check, the checksum will be the same.  In fact
it is a simple matter for a virus or trojan to insert whatever code it
wants followed by a couple of bytes to compensate for the checksum.

The 15-second wait that you are experiencing is most likely the time
it is taking for DOS to reload the transient part of COMMAND.COM.
It should be obvious that this is entirely too long.  Here is my guess
as to why:

COMMAND.COM may be occupying a marginally bad area of the hard
disk.  Every time a sector is read, a CRC check is done, and if it
is bad, a certain number of retry-reads will be performed.  The
retry usually involves a reseek and always involves another full
rotation of the disk.  Use something like Norton's dt (disk test)
with the file check option to check it.  If you don't have that,
use the DOS command VERIFY=ON and then copy COMMAND.COM to NUL and
see if you get errors or if it takes a long time.

Hope this helps.  Anyone else care to hazard a guess?

(Opinions expressed here are mine and do not necessarily reflect
those of my employer, etc.  "I can neither confirm nor deny the
presence of nuclear weapons on this vessel" - U.S. Navy)