X-Apparently-From: Message-ID: <003f01c0410e$bc749b40$a2881004@dbcooper> From: "Patrick Moran" To: References: <2497644673D AT reze-1 DOT rz DOT rwth-aachen DOT de> Subject: Re: DRDOS FDISK Date: Sat, 28 Oct 2000 11:07:52 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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: "Matthias Paul" To: Sent: Thursday, September 21, 2000 11:07 AM Subject: Re: DRDOS FDISK > Yep. It's true that I wrote about it some time ago and did a quite > huge amount of research to isolate the problem and find the trigger > conditions for my independent development on DR DOS. Where can I find a copy of this? If you still have a copy, would you please e-mail it to me? > The results of this are already reported to Ralf Brown for inclusion > in his INTERxx list, but unfortunately didn't showed up in INTER61. > For those interested, it will probably be covered in INTER62 (INT > 19h). Where can these be found? > I know it sounds strange, but it is actually true what Charles > Dye wrote (he originally isolated the problem long before I even > knew about it): Where can I find this? > MS-DOS/PC DOS, OS/2 (and probably NT too) use the OEM label in > the boot sector to decide which other fields in the BPB (the BIOS > Parameter Block) at the start of the boot sector to trust on and > which other values to leave alone. My research revealed that > they probably do this to detect and work around bugs in their > *own* history. Early issues of MS/PC-DOS FDISK and FORMAT sometimes > wrote invalid data into the tables. However, it was never documented > anywhere, that the OEM label is no longer don't care. This reminds me of a problem I had many years ago: Computer 1 = IBM XT Computer 2 = IBM AT Software = PC-DOS 3.3 (IBM DOS) with 3.31 patch installed. Gazell BACKIT, PCTools 4.xx (probably 4.11) Norton's 3.xx (Probably 3.01) Diskettes 5-1/4 360k I backed up the AT hard drive using BACKIT with compression to floppies. The AT was used for a specialized purpose and did not have a lot of software on it. It only took 11 or 12 diskettes to do a complete backup. However, BACKIT uses a different format than the standard DOS format. It does not used a FAT nor a Directory and added more sectors to the diskette. Each diskette had a capacity of about 400k. The backup went smoothly, but when I did a compare, I got an error on the last or next to last diskette (Murphy's law at work here-:) So I took the diskettes back to our office and checked them on the XT with Norton's DiskTest and PCTools DISKFIX. Neither one found any problem rading and writing to the suspected floppy. I did a thorough test on it and found no problems. I erased the diskettes and reformatted the suspected diskette. then I went back to the AT and backed it up again. Same result! So I got another new diskette to replace the defevtive diskette and backed up the AT again. This time everything went just fine. I was very curious as to what was wrong with this defective diskette. I took it back to the XT and reformatted it and ran Norton's and PCTools on it and found no problems. I inserted another diskette into drive B: and formatted it. I then used Norton's disk editor and checked the boot sector on both diskettes. Two bytes of information were different! Nothing ever did detect a problem except BACKIT. The defective diskeete had a very, very small defect on it. The diskette could be used just fine for any other purpose! So, the question is, does DOS actually every really use that information? It was so long ago, I cannot remeber which two bytes were affected. I have often found diskettes with corrupt information in the boot sector, such as sector size, cluster size, etc. and they seem to work just fine. Somtimes I'll use a disk editor and correct it. It seems that even though the actual information contained in the boot record can be eroneous and yet DOS will give the coorect parameters for it. (According to Norton and Pctools disk editors.) DOS may actually use the first byte in the FAT for the identifier. The reason I find these things is I do a lot of playing around with old programs and operating systems. Sometimes I'll take a DOS or program that was on a 160k diskette and copy the BR to a 360k or 720k. I have to edit the boot record to reflect the proper parameters for the diskette. For example: I wanted to play around with a old DOS, but did not want to physically change my drives around so I could boot from the 5-1/4" So I would change the 3-1/2 to look like a 360K by editing the boot record and install the old DOS to it. I have also copied copy protected diskettes from 160K-360K 5-1/4 to 720k 3-1/2" floppies! DOS 1.x used single sided 8 sector floppies. Here is a trick for anyone interested: To use you 3-1/2" drive as a 5-1/4" 360k drive and have the system recognize it as such, go to your BIOS setup and change the drive A: to a 360K floppy. I have not tried this with 1.2 as I do not have any original 1.2 bootable floppies, just ones I made. This will work even with copy protected floppies. I used it to copy my original Zork I and KQ I floppies. They will boot and run on the 3-1/2" floppy drive! I would appear from all of the above, that some information is actually used and some does not seem to matter. Another thing I have ran across that is very strange. When I have formatted a disk and later use some utility which displays the drives characteristics (such as SI) it will incorrectly show the wrong version or even vendor of the DOS. Many will show it as MSDOS 5.0 or IBM DOS 5.0. This will sometimes happen with MSDOS 6.xx format. Diskettes formatted with PCTools PCFORMAT will often show the incorrect label. The label in the boot record may show it as PCTools 6.0 (or whatever) and yet some SI programs will show it as a DOS 5.0. So it would appear that some programs look for a particular byte or bytes of information to determine what was used to format the diskette and not use the label entry in the boot record. I have never bothered to track this down as it did not seem to be significant at the time. However, now, this may explain the wierd prople I have had with PCTools. I know that PCTools worked just fine with DRDOS 6.0 and believe it worked fine with Novell DOS 7.0, but cannot be positive. I may play around with it in the near future and see if it was also affected. Since I had used NWDOS 7 for a few years before using OpenDOS 7.01, I think I would have remembered it. It seems the problem is fairly recent. (Last couple of years.) The problem I am having is that when I use PCTools diskfix on partition formatted with DRDOS, it will report a ton of lost files and directories. It seems to do it everytime. These files and directories are not lost and were actually on the drive and not erased files. Fortumately I usually have a good backup and can restore the lost directories and files. Sometimes I may lose a few files because of this. So I no longer use DISkFIX on hard drives. I just use Norton's NDD now. Some utilities (I do ot remember which one(s) will sometimes report an error in the boot record. I usually just ignor it because every MS piece of crap OS that is installed, changes it. I do not want to take the chance of getting a corrupted BR so I do not elect to repair it. I think what I will do is use a disk editor and copy the boot sectors of all paertitions and drives to individual files for each one. That way if one does get corrupted I can easily restore it back to what it was. (Some of these may not save an undo for re-writing to repair it.) All of my drives (FAT drives) show MSWIN4.0 as the OEM label in the BR. I booted from floppy with MSDOS 5.0 and still have the same problem. I do not believe that editing the string and propbably anything in the BR would help because NT would probably rewrite them. They ALL were formatted with DRDOS 7.03 (except NTFS.) Of course NT would change drive C: BR because it puts it's loader program there. The MBR, however, was rewritten with the DRDOS boot loader program. I had originally thought that the problem was with DRDOS kernel, but have proved it not to be the case because it also does it with MSDOS 5.0. It has to be something in the format that PCTools does not like. While on the subject of PCTools, does anyone have a patch to make Central Point Backup Y2K compliant. I can use it, but have to be careful with a few things. The date/time stamps are all messed up. This causes a few problems. I could not even use PCTools 8.0 without changing the date on the computer back to 1999 to perform a backup, the restore would not work. The restore will work even if the computer clock is cuurent. > A quick fix is to just replace the OEM label in the boot sectors > created by DR DOS "xxxxxyyy" by "xxxxx3.3", preferable "IBM 3.3". > The "xxxxx" is don't care, but the "yyy" must be in the format "n.n", > and should match the style of BPB written to the disk. Version numbers > above 5.0, however, can cause problems with some 3rd party disk > utilities like PC Tools. I currently use PCTools 9.0 and Norton 8.0 PCTools is the Pro version. I also have the WINDOZE version of PCTools, which my brother uses with WIN 3.1. I also have something for version 10, but that seems to be related to the WINDOZE version. I don't use WINDOZE 3.xx so I never really checked it out yet. > You can do this using DEBUG or using a Disk Editor. Partitions using > this old signature will work OK with MS-DOS/PC DOS and OS/2 in > all known cases. See my comments about NT 4.0. WIN 9x/ME/2000 may also do this. I completely removed 95 and did not check all the BRs with it. I installed ME for a short while and did not like it either, so went to NT. I did not check all the BR with ME. I keep a copy of the MBR and C: BR for each install but did not bother to check the other BRs. This is so if I remove an OS, I can use the proper BR and MBR that was there before the OS was added. > You can also patch FORMAT, FDISK, and SYS to use these signatures > after unpacking them using "PKLITE filename -x". (But don't touch > the FAT32 BPB prototype in FDISK.) What has to be changed in these? If I know what hex strings are needed to be changed, I can use a hex editor and do a search and replace. > However, it would be better to make the use of the BPB entries > identical to the BPBs written by MS-DOS 6 or 7 (DR DOS writes them > in Compaq or PC DOS 3.3 style, hence the old signature "IBM 3.3"), > but this is not applicable for a field patch. The MSWIN4.0 shows up in some SI utilities as MS DOS 6.0. So that is probably not the kind of fix I need for PCTools. I don't know the actual DOS NT 4.01 build 1381 with Service Pack 6 installed uses. That brings up another point. NTFSDOS will not show any entries when I run it under DRDOS 7.03. The docs say it will show long filename as blank entries, but I cannot even get it to show the WINNT directory name when I run DIR in the NT root directory. What would be really nice would be to write a batch file to use debug to search and replace for any versions of DOS effected by this. Another thing would be to write a patch for DRDOS 7.03 FORMAT.COM FDISK.COM and SYS.COM. Then Send this patch to Lineo and have them check it out and include it in an update or send them copies of the updated files and they could include them as a DRDOS 7.03 update. (The way Novell used to do.) This also brings out another point. DRDOS 3.xx/5/6/7.xx/Novell/Open/Caldera are all Compaq compatible. This may explain some of the problems. Compaq is a piece of highly proprietary crap and needs all kinds of special considerations. Can these changes described above be implemented and still be compatible with Compaq? One other note as well. DRDOS will run CP/M programs (as did the original 1.x versions of IBM DOS.) Will these changes affect CP/M capability? This problem may not even be a DRDOS bug, but a Compaq compatibility problem. I really hate those computers and do not understand why anyone would buy one. They sock it to you to upgrade and often the things cannot be upgraded. A few years ago, a person was trying to get either a 28.8K internal modem or a high speed serial port card to run an external 28.8K modem. Compaq made nothing for this nor did anyone else at the time. Then if Compaq did finally make a 28.8K modem for it, they probably vharged 2 to 3 times the normal price for a modem. We had a bunch of compaq 286s where I worked and upgrades for them were very expensive because of their highly proprietary crap. Talking about Compaq, here is a funny story (although it was not funny at the time nor to the owner of this computer.) A local business here bout an XT clone from a local computer dealer. This dealer must have put these things together hinself. Anyway, this XT had a Compaq CGA or EGA card in it!(Don't remeber which.) The bracket on this Compaq card was not a standard IBM brackit. (Surprize, surprize!!!!) It looked like someone took a hammer to bend the brackit to force the card to fit into the XT case!!! (I think they needed a bigger hammer!!!!!-:) The card was always getting unseated (no way to install a mounting screw) and they had to open up the computer and reseat the card frequently!!!!(Idiots!) This dealer either took the card out of an old Compaq or bought a bunch of them at some surplus sale! In any case the person who bought it was told it was a new computer. (This dealer was probably the same one that would install RLL drives and use an MFM controller!!!!) (You would lose nearly 1/3 of drive space!!!) > This would also fix another problem I saw on a Windows 98 machine > with Chip Away Virus in the ROM-BIOS. On this machine, the OEM label > is overwritten with a special "IHC" checksum every time you access > a floppy (even a simple "DIR a:" with a non-write-protected media > will be sufficient). No other changes are made to the media, however. > I saw this only when the GUI was up, not under plain DOS 7 nor > DR-DOS. > It is my assumption that this behaviour is due to this Anti-Virus > feature of the ROM-BIOS (I am not completely sure about this, but > no virus-scanner was able to detect a virus). I guess you had to turn off the virus protection or continuously have to hit yes everytime you wanted to access a floppy!(Really, really stupid.) > The problem is, that overwriting the OEM label of a floppy formatted > under DR-DOS 7.02+ will again trigger the problem mentioned above, > and Windows 98 will no longer be able to access the media, while > there are no problems under DR-DOS, because it definitely does not > make any use of th OEM label... Gates strikes again!!!! > The problem is that these changes have still not been made public > by Caldera/Lineo, although this was fixed more than a year ago, > and, of course, I cannot (at present) make them public myself... Why not? Can you send this info and fixes privately via e-mail? I have the source code for the 7.01 versions of DRDOS, However, it only contains the code for the kernel. I thought it was supposed to be for all of the files. May there was on the CD. I don't even know what source code is included with the current DRDOS CD. Since Lineo/Cladera is no longer working on DRDOS, they should just release the whole ball of wax to public domain or GNU or GPL along with all the source code and even the incopleted projects they were working on. I don't think they are even marketing it for embedded system. They stated that everything now is for their Embedded Linux. They have already won and settled the lawsuit against MS and tool MS for a fortune. They are going completely to the Linux platform and are no longer developing DRDOS. I am not even certain who wrote 7.04/7.05, Caldera, Lineo, or Ontrack? I have those files around here someplace, I look at them and look at the copyright notice in them. Does anyone know if RxDOS implemented DPMS in it. If so, I may go with a combo of Rx and DR DOS. Also does RxDOS also support CP/M? I have an old version of Rx (don't remember which, 1997.) I installed it and liked it, but it still needed a lot of work. Does anyone know what compiler was used with DRDOS? I know they have DJGPP and NASM available via FTP on one or more of their sites. I have a version of DJGPP (around 1997 version) , but don't remember which version. Don't even remeber where I picked it up. Probably Sunsite or one of it's mirror sites. I have not checked out FreeDOS in a long time. There was no one in charge of it for at least a couple of years. I kept checking thier site and no new stuff was on it. I checked their new site recently and see that there is now a newer version. FreeDOS used the Borland C++ compiler. Many people were complaining about that and wanted them to switch to DJGPP. Did they ever switch to DJGPP? Did they implement DPMS? I have Borland Turbo C++ v 3.0, so that is probably what they were using back in 1996, It was version 5. (A?) I have an OEM copy of the source code for MSDOS 3.30. There was some bugs in it before the final release if the used MS Macro Assembler 5.0 instead of 4.0. The one I have is the final release and includes an MASM and some other assembler executables. I would not even attempt to compile (assemble is the correct word, but for some reason everyone says compile.) it with my v 5.1. I have run across this MS crap in the past. I could not compile Quick Basic v 3.5 with my v4.0. Those greedy idiots did not make that possible until version 4.5. I was not about to go out a spend another $100 or another piece of MS incompatible crap. This source code may be of some use to someone trying to fix some of these problems discussed above. A copy of 5.0 or later would be better. Pat __________________________________________________ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com