Mail Archives: opendos/2000/10/31/13:07:23
> > Well, the original poster asks about the OEM signature, so wouldn't it
be
> > reasonable to assume they meant the OEM label?
> Your message did not include that information.
I beg your pardon? I certainly did:
On Friday, October 27, 2000 at 10:09 PM, I wrote:
| > > BTW, I lost the message with the information about what should be in
| > > the OEM signature to be MS-DOS compatible. Can someone please
| > > resend it to me? :)
| > In retrospec of this paragraph that I am replying to now, I am at a loss
| > as to WHAT signature you want.
| The OEM label, found in every DOS boot sector. DOS boot sectors are laid
| out thus:
On Sunday, October 29, 2000 at 6:10 PM, I wrote (in the post you are
replying to):
| > > > > BTW, I lost the message with the information about what should be
in
| > > > > the OEM signature to be MS-DOS compatible. Can someone please
| > > > > resend it to me? :)
| > > > In retrospec of this paragraph that I am replying to now, I am at a
| > > > loss as to WHAT signature you want.
| > > The OEM label, found in every DOS boot sector. DOS boot sectors are
| > > laid out thus:
| > Thus, I do not know what signature you are asking about.
| > both of these and the OEM ID are signatures.
| Well, the original poster asks about the OEM signature, so wouldn't it be
| reasonable to assume they meant the OEM label?
> I can't remeber what was said a hundred messages ago, plus this
> list is not the only place I read such messages.
Diddums. It's certainly not the only place I read such things either, but I
kept track of the conversation. It's not my problem that you can't.
> 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.
> But all the problem thus far had been with the format and not with
> the MBR.
But still with FDISK. Since the subject we are concerned with is a problem
with FDISK - not a problem with the MBR, not a problem with the format, but
with FDISK - I don't see what the problem is.
> If the problem you are refeering to is just with
> the FDISk format, then just use FORMAT.COM /X/Q and fix it.
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.
> > > Are you saying that DOS 3.0 and later cannot read diskettes formatted
> > > with earlier DOS?
> > I'm saying some v2 issues created floppies that cannot be read (or maybe
> > just booted from) in v3+.
> This makes no sense. When you boot, there is no DOS version until the
system
> is booted, so if you boot with v3 you will have v3. If you boot with v2
you
> will have v2 installed. If you boot with v2 you may not be able to read
the
> drive made with v3.
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).
At the time, a popular theory was that DOS v3 looked for the magic initials
'IBM' in the OEM ID field. The correct explanation for the problem is given
in the paragraph above. However, IBM actually added an extra check in v4
(if the letters 'IBM' didn't appear in the OEM ID, the disk was invalid),
but MS removed this for their issues of v4.
> Of course I do have the v2.xx DOS diskettes for installing DOS as
> well as 1.x. I also have the Inside the IBM PC diskettes that came with
the
> boot by Peter Norton that were formatted with v1. I can read all of these
> just fine.
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.
> > I'm not sure is DOS 1 kept a BPB in the boot sector at all
> It doesn't,
I know - I meant to type 'I'm not sure if DOS 1 kept a BPB...'. I checked
this morning, and it doesn't. MS/PC-DOS 2 does, and all DOS 2 versions are
supposed to, but some didn't.
> [was the media descriptor correct?]
> I would imagine so and I assume you are talking about the first byte in
each
> FAT, as DOS reported the correct information.
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.
> 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.
Regards,
Ben A L Jemmett.
(http://web.ukonline.co.uk/ben.jemmett/, http://www.deltasoft.com/)
- Raw text -