[comp.os.msdos.misc] Where in the world is IBMBIO.COM? Was:Re:help:peculiar msdos 3.3 crash

cctr132@canterbury.ac.nz (10/06/90)

There has been a lot of traffic about where the DOS system files have to be on
a disk to make it a usable boot disk.  Most recently it was started afresh by
someone who (from memeory) trashed IBMBIO.COM with CHKDSK /F.  This poor
unfortunate's plea for help was responded to almost immediately by someone
telling him/her to do a *low-level format* - one of the grossest pieces of
over-treatment I've seen prescribed on the net.  This has led to something of a
disagreement over what files should be where, etc.

Could someone who is an *acknowledged* expert/guru put this to bed *for good*?
Please??

And if it isn't already (can't remember & haven't got my copy handy) could this
be put in the FAQ list for this group?  (Though I wonder if they are ever read
by the people who should read them.)

Anyway, I'm going to add my two cents worth, coz whilst I feel that the latest
contribution to this debate almost clears things up, there is, given my
understanding, still some confusion here.

In article <1286.270b48d3@iccgcc.decnet.ab.com> Stan Brown writes:

>In article <5XwDq2w163w@bluemoon.UUCP>, andy (Andy Vaught) writes:
>> It looks like you're going to have to go and do a low-level reformat and 
>> backup.

Actually, a backup, re-format, then restore - but I feel that re-formatting is
wholly unnecssary, see what follows.

>In an earlier posting, I disagreed.  I still disagree.(*)
>
>>         IBMDOS and IBMBIO require very special treatment, since they have 
>> to be loaded by a simple loader that has almost no idea of what the DOS 
>> file structure is like.
>
>True as far as it goes.  But "almost no idea" is not the same as "no idea".
>
>> The following restrictions apply:
>>  1) IBMBIO.COM (IO.SYS) must be the first file in the root directory
>>  2) IBMDOS.COM (MSDOS.SYS) must be the second file
>>  3) The files must be the first files stored on disk, and they must be
>> stored in order in contiguous clusters.
>
>1 and 2 are true for all DOS versions up through 3.3 (which was the
>original poster's question).  3 is >> FALSE << for DOS 3.3.  Sometime
>before then-- I'm not sure how far back--Microsoft removed condition 3
>so that you could install a new version of DOS by doing SYS C: without
>formatting the hard disk.  As a side effect, you can also RE-install the
>same version of DOS, unless IBMBIO.COM or the first sector of IBMDOS.COM
>has been deleted.

As I understand things, Stan is right, but not totally, *or* he hasn't made
himself clear.  Somewhere along the line, 3 was *changed* so (I think) all of
IBMBIO.COM/IO.SYS has to be contiguous from the first data cluster of the disk,
and X bytes of IBMDOS.COM/MSDOS.SYS have to be contiguous from the end of
the first file.  By this point in proceedings enough of DOS is loaded for it to
be able to read directory and FAT entries, and thus work out which clusters to
read, whereas up to this point it has just been doing contiguous absolute disk
reads.  The people whose opinions I tend to trust aren't totally clear on this
point, and it may be that only the first X bytes of the first system file
need to be contiguous from the beginning of the data area of the disk.

>There may be another problem that will make you reformat your hard disk,
>but this problem is not it.

I agree with Stan that there is no need to re-format this disk, *at present*.

>(*) If IBMBIO.COM/IBMDOS.COM are scrogged beyond repair, and something
>else is occupying their sectors, then you do have to reformat your hard
>disk.  But it's not a low-level reformat, just a simple "FORMAT C: /S".

I agree with Stan, *BUT* only on the point of not needing a low-level
format.  If the owner of the afflicted disk has any of the half-decent disk
repair utilities, s/he should be able to *easily* recover from this situation
by running the appropriate routine in that util for restoring a disk to
"bootable" condition.  These relocate clusters belonging to files that
shouldn't, but do, have clusters near the beginning of the disk, juggle the
root directory to make space for the two system files at the "top", and then
reinstall the appropritae files.

If they haven't one of these utils?  Recovery is *still* posible, but it may
take a little longer - less time than a full backup, re-format, and restore
though!  Early versions of PC-Tools, Nortons, etc (before they incorporated
their extensive disk recovery utils) allow you to work out which files occupy
any given cluster on a disk, so use of one of these (if available) to locate
the file/s taking up the first 60-70 k of disk and deleting these (copy them to 
another disk first, if necessary), and deleting the first two files in the root 
directory (copy them to another disk first) will leave the disk in a state that 
SYS can easily handle.  (The system could be re-installed using one of the
utils mentioned, but there are a couple of traps for young players here.)

You don't have an early version of these utils?  I haven't had time to unpack
them yet, but one of two very recent postings from c.b.i.p. may help.  Can't
remember which but ZAP33 or XPACK claims to be a bundle of "PC-Tools like" disk
maintenance utils, and there may be something in there that is of use.

I am not totally sure that my contributions here are fully accurate, but I have
done several successful restores using the second method outlined above, which
leads me to conclude that any errors in my understanding of the requirements
are on the conservative side.

I apologize to the original poster if s/he has followed these people's advicce
unnecessarily, but our mailer was down for a while after I saw the original
post, otherwise I would have sent email as well.

+---------------------------------------------------------------------------+
| Nick FitzGerald, PC Applictions Consultant, CSC, Uni. of Canterbury, N.Z. |
| Internet: n.fitzgerald@canterbury.ac.nz            Phone: (64)(3) 642-337 |
+---------------------------------------------------------------------------+