Mail Archives: opendos/2000/10/28/14:42:09
----- Original Message -----
From: "Matthias Paul" <PAUL-MA AT reze-1 DOT rz DOT rwth-aachen DOT de>
To: <opendos AT delorie DOT com>
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
- Raw text -