Subject: Weird DOS INIT bug
Path: lobby!newstf02.news.aol.com!portc03.blue.aol.com!newsfeed.cwix.com!207.207.0.26!nntp.giganews.com!cyclone.swbell.net!typhoon01.swbell.net.POSTED!not-for-mail
Message-ID: <36BFD110.FEB6E710@swbell.net>
From: Rubywand <rubywand@swbell.net>
Reply-To: rubywand@swbell.net
X-Mailer: Mozilla 4.5 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
Newsgroups: comp.sys.apple2
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Lines: 49
Date: Tue, 09 Feb 1999 00:09:20 -0600
NNTP-Posting-Host: 207.193.10.33
X-Complaints-To: abuse@swbell.net
X-Trace: typhoon01.swbell.net 918545363 207.193.10.33 (Mon, 08 Feb 1999 23:29:23 PDT)
NNTP-Posting-Date: Mon, 08 Feb 1999 23:29:23 PDT
Organization: SBC Internet Services




     One of the neat features of DOS 3.3 is that its INIT command allows
creating new bootable diskettes which can INIT still other diskettes.
Unlike the situation with ProDOS, you do not need a separate Format and
Copy utility.

     For a time, I used this feature to do INITs from my stock HELLO
program. Since you don't want to INIT a valuable disk by mistake, the
little INIT routine tried to do a CATALOG first. (If the disk CATALOGed,
you got to see what was on it before going on with the INIT. If, the
CATALOG produced an error, an ONERR branched to an immediate INIT.)

     The INIT option was handy; but, unfortunately, the routine and
assorted variations often produced corrupted disks and it had to be
scrapped. Naturally, it was perplexing that such a simple, perfectly
correct routine should blatantly screw up so often and, yet, other
times, work fine.

     Then, one day a couple months ago, I happened to be interested in
the format of a partcular disk after doing an unsuccessful CATALOG and,
so, checked the contents of the VTOC buffer in memory. It was a mess.
This led to a question about where the basic VTOC info might be stored
for doing an INIT. 'Obviously', the VTOC buffer was no good for this
purpose.

     It turns out that, good or bad, the buffer is where the info comes
from. Every time my INIT routine tried to CATALOG a blank or non-DOS 3.3
diskette, it was trashing the contents of the buffer which, of course,
was soon placed in the VTOC sector of the newly formatted disk as part
of the INIT! The result depends upon what sort of garbage gets placed in
the new disk's VTOC sector. It may be a crash near the end of the INIT
or a diskette that won't boot or, even worse, a mysterious problem you
run into later. 

     DOS should either make sure that it is writing a valid VTOC sector
during INIT or it should not update the VTOC buffer for an unsuccessful
CATALOG. (You can easily replicate the bug's effects by booting DOS 3.3
and attempting to CATALOG a ProDOS diskette. Then, try INITing a
diskette.)

     The good news is that a successful CATALOG and other activitities
automatically place good VTOC info into the buffer. So, doing an INIT
after a bad CATALOG is one of the few situations which is likely to mess
things up. (My new INIT routine automatically POKEs in good VTOC data
when a CATALOG produces an error.)



Rubywand