Message-ID: <017701c04365$41ca2aa0$11fea8c0@dell> From: "Ben A L Jemmett" To: References: <00b801c02814$cc72b3a0$0400000a AT alain-nb> <01d601c04023$ddf751e0$cb881004 AT dbcooper> <005301c04062$9af82420$11fea8c0 AT dell> <001601c041bf$4c924ff0$6f1e0404 AT dbcooper> <000101c041dc$47239a20$11fea8c0 AT dell> <010a01c042dd$202ba230$3d1e0404 AT dbcooper> Subject: Re: DRDOS FDISK Date: Tue, 31 Oct 2000 17:27:27 -0000 Organization: Jemmett Glover Software Development MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Reply-To: opendos AT delorie DOT com > > 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/)