Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!bellcore!decvax!decwrl!glacier!mips!kim
From: kim@mips.UUCP
Newsgroups: net.micro.pc
Subject: Re: Bug With PC-DOS 3.1 DEL command?
Message-ID: <488@mips.UUCP>
Date: Sat, 24-May-86 17:02:26 EDT
Article-I.D.: mips.488
Posted: Sat May 24 17:02:26 1986
Date-Received: Mon, 26-May-86 01:38:16 EDT
References: <785@kontron.UUCP> <856@cyb-eng.UUCP> <803@kontron.UUCP>
Distribution: net
Organization: mips ... where RISC is a way of life
Lines: 32

>> Lest others be misled, I must respond.  ERASE and DEL each result in the
>> SAME CODE being executed within COMMAND.COM.
>> 
>> I suspect the problem might have had to do with some of DOS memory getting
>> scribbled on, causing the DEL to work incorrectly.  I bet the ERASE command
>> was tried and worked successfully after something changed -- perhaps reboot.
> 
> DEL now works reliably -- you probably have described the problem correctly.
> (I sure wish the PC had memory protect -- I have no idea what program I
> ran could have trashed us.)

Hmmmm ... I don't have any "internals" experience with DOS 3.x, but in all
previous releases (1.x, 2.x) the code for the built-in commands like dir,
erase/del, etc. have resided in the *transient* part of COMMAND.COM, which
is relocated to the high end of memory.

Whenever control is passed/returned to COMMAND.COM, it (the *non-transient*
part, which is in low core) runs a checksum on the transient part.  If the
actual checksum is different that what is expected, it causes a reload of
COMMAND.COM from disk before prompting the user for the next command.

I agree that *something* is getting trashed by someone, but I be surprised
if it were the ERASE/DEL code itself (unless, of course 3.x is structuraly
different that 2.x).

/kim
-- 

UUCP:  {decvax,ucbvax,ihnp4}!decwrl!mips!kim
DDD:   408-720-1700 x231
USPS:  MIPS Computer Systems Inc,  930 E. Arques Av,  Sunnyvale, CA 94086
CIS:   76535,25