X-Apparently-From: Message-ID: <00ba01c04442$62576980$eb881004@dbcooper> From: "Patrick Moran" 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> <017701c04365$41ca2aa0$11fea8c0 AT dell> Subject: Re: DRDOS FDISK Date: Wed, 1 Nov 2000 08:25:28 -0700 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.00.3018.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Reply-To: opendos AT delorie DOT com ----- Original Message ----- From: "Ben A L Jemmett" To: 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