Mail Archives: opendos/2000/11/01/16:29:39
----- Original Message -----
From: "Ben A L Jemmett" <ben DOT jemmett AT ukonline DOT co DOT uk>
To: <opendos AT delorie DOT com>
Sent: Tuesday, October 31, 2000 10:27 AM
Subject: Re: DRDOS FDISK
> > I originally started this thread and was talking about FDISK.
> DRDOS FDISK, according to the Subject header.
>
> > FDISK only
> > deals with the MBR and has nothing to do with Boot Records. However,
since
> > DRDOS FDISK also will format the drive automatically, it is somewhat
> > related.
> Directly related, according to the subject and the bug being discussed.
I think what happened is that some of the people that responded, did not
understand the difference betweet the MBR/Partition Table and the Boot
Record. The were talking bout stuff in the MBR that is not there. I tried to
explain the difference in one of my messages. Everyone kept talking about a
format problem and nothing to do with the MBR. Then they would say something
about the MBR, when they really meant the Boot Record. I was looking for
problems with FDISK. FDISK does not format an NTFS, ext2fs, HPFS, or
anything other than FAT 16 and probably FAT 32. All it does when it does
format a FAT partition is write the boot record and the FAT and the root
directory. It then checks the system area. Then if you tell it to it will
check the whole partition. I usually run unconditional format after FdISK is
done anyway. Thus I guess I have never run into any of these problems. I was
trying to find out what the problem with FDISK is and their does not appear
to be any. It is the format it puts on the disk that is a problem. I use
DRDOS FDiSK to make NTFS, FAT 32, ext2fs and FAT 16 partitions and never had
a problem with any of those partitions.
> Can I just clarify something? I'm talking about a problem described by
the
> person you replied to, specifically that FDISK in 7.03 is buggy and
creates
> partitions either incompatible with other DOSes or that waste too much
> space. It's not a problem I have - I run OpenDOS 7.02 beta 2 when I run
> DOS - and create and format DOS partitions with tools unaffected by the
> problem. You seem to be talking about something else, and it's all gone
of
> on a tangent somewhere.
It certainly has. Now everyone is talking about Boot Records and on many
different makes and versions of DOS.
> Good point - in that case, the broken v2 disks may be unreadable in later
> versions, not unbootable. Let me restate: In versions 1 and 2 of DOS,
the
> BPB in the boot sector was ignored. Due to this, some OEMs decided their
> DOS versions didn't need to put a valid BPB in these. When version 3 came
> along, the BPB was used by parts of DOS (and the bootstrap loader uses
this
> information, which it didn't previously), and so the disks without BPBs
were
> reported to be invalid. Now, I guess MS fixed this with later releases of
> version 3 if they can be read (they probably checked to see if the BPB
data
> matched what the BPB media descriptor implied, and if not use the default
> BPB as earlier versions did).
I do know that some OEMs put their own stuff into DOS. I have Wyse DOS 3.21
which allowed for greater than 32MB partitions. Some versions (2.11 for
sure) of Compaq DOS would completely destroy all previous information on the
diskette when you used it'e FORMAT command. It would fill all sectors 00 or
F6 that were not in the system area.
I don't understand why any OEM would forget about using the BPB if it is
part of DOS. They are sent the MS source code for DOS and build on it. Why
would they want to go to the trouble to delete that from the source code.
Maybe they were too stupid to realize they were playing with fire. Maybe
they never read the MS manuals that explained it. Who knows. Many
programmers are pinheads anyway. I even started out with a copy of Tandy DOS
3.2 when I built my first IBM compatble, it was a 286. I did not have any
DOS to check it out, then I found the Wyse DOS for sale at a liquidation
mail order place and ordered it for about $29.
> That's probably because they were formatted originally by either IBM
> Personal Computer DOS v1 or v2, or MS-DOS v1.25+ or v2. Those versions
> (obviously) obeyed the standards IBM and Microsoft laid down for the boot
> sector layout. Some OEM versions didn't, as the information missing
seemed
> unimportant at the time.
That is true. They were not formatted with say DOS 3.3 and then copied.
These are orgininals or copies of originals. Whenever I made backups of the
originals I would boot from that DOS, because there are problems sometimes.
I'll explain further down when I reply to another area.
> Either that one or the one at offset 0Ah in the BPB - I'll guess that DOS
> uses the FAT one in preference to the BPB one.
I don't think so. I am not certain what that is used for, it is an extended
signature byte. It may be different in some versions, but it seems like it
was always a 29 hex. (At least for HDD.)
> > One was so stupid that they put a couple of
> > bytes of information at the end of the second FAT which would not be
used
> in
> > any case. So if you did a DISKCOPY of the diskette, the byte(s) located
> > there would not be copied.
> I think you mean a COPY *.* - DISKCOPY does a sector-by-sector copy of a
> disk, including the FATs and bootsector (at least, the one in my DOS 3.2
> does - ended up with a few duff copies due to bad sectors because of
that).
> The best way of protecting a disk against DISKCOPY is to format the last
> track with a higher track ID than should exist - Anadisk can do this with
me
> nus, or a short assembler program can do it. You can then seek the heads
to
> that track and read the data, but DISKCOPY would seek to track 79 which no
> longer exists.
Some even used tracks beyond 39 and DOS would not copy those. AFAIK there
were never any HD disk copy protection, it was only used on DD disks.
This may have changed or may some OEM DOS does it differently, but what IBM
DOS DISKCOPY did/does is first it formats the disk then it copies all of the
files. It may or may not copy the BR. But as I recall, if I copied a 3.3
formatted diskette with MSDOS 5.0 installed and used 5.0 DISKCOPY, the BR
would show the OEM ID as MSDOS5.0. I believe this is the reason I always
chose to format a system diskette with that version DOS booted. This may not
have always been this way, but I did notice that at one time. The IBM manual
(3.3) stated somewhere that DiSKCOPY worked the way I described above. It
did/does not copy sector by sector, you need a utility like COPTIIPC to do
this.
You can check it out sometime, and I am certain if you use PC-DOS 3,.3 or
3.21 and possibly 5.0, format 2 diskettes uncondionally then use a
diskeditor and change the last byte in the second copy of the FAT to FF and
then run MS/PC DISKCOPY and then check the copy. I'll bet the FF is not
there. Now DRDOS is different, it does copy sector by sector, but I don't
recall which ones do this. I know that 7.01-7.03 does because you can make
diskette images with it. This particualar game I was talking about would not
run if you used diskcopy. I looked at the original and saw the FF or
whatever it was in the last byte of the second copy of the FAT and looked in
the first copy of the FAT and it was not there. I checked for it in the
copied diskette and it was not there. I edited the diskette and put the FF
or whatever in the 2nd FAt and the game ran fine.
Pat
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
- Raw text -