Message-ID: <007c01c262ef$27db8980$c03dfea9@atlantis> From: "Matthias Paul" To: References: <001501c26296$2e6877d0$3036ed18 AT ross2mustss87c> Subject: Combining DR-DOS 7.03 with OEM DR-DOS 7.05 to gain LBA capabilities (Was: Re: HIMEM.SYS and DOS 8) Date: Mon, 23 Sep 2002 11:55:06 +0200 Organization: Aachen University of Technology (RWTH), Germany MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id g8NApYD20506 Reply-To: opendos AT delorie DOT com On 2002-09-23, John T Ross: > You previously explained to me use of the extended > partition type C5h, instead of the old 05h type, to allow > DR-DOS 7.03 coexist with a LBA enabled OS using disk > space above 8 Gb. Yes, this still stands and is the recommended method. I am using it myself for years and have not had a single problem with it. > Will you elaborate on the combination of the DR-DOS 7.05 > IBMBIO.COM and DR-DOS 7.03 IBMBIO.COM files? I > understand one's need to ensure the hard drive doesn't > contain any FAT32 partitions. I agree that a binary patch > to keep the 7.05 BIOS from logging into FAT32 partitions > is a useful saftey net. OK. > If I use a PC with a flash BIOS that supports LBA hard > drives, what does this 4th solution offer that the former > doesn't? Since the DR-DOS 7.05 IBMBIO.COM supports LBA, you can access disks larger than 8 Gb. The problem is that the 7.05 DOS BIOS will also log in FAT32 partitions, and the 7.03 BDOS does not know how to handle them, so you will end up with invalid drives, which might be potentially dangerous and is inconvenient in any way. Hence the patch to keep the DOS BIOS from recognizing FAT32 partitions. This is not needed, if you do *not* have any FAT32 partitions. Please note, that such a patch does *not* exist at this time, but it seems relatively easy to derive one after a few sharp looks at IBMBIO.COM. Sorry, I don't have any time left for it at the moment, but if there is a strong interested I will put it on my (already long, sigh!) list to look at. > I assume it limits one to using a single OS on the > hard drive? No. There is no difference in handling compared to DR-DOS 7.03. The only requirement (without a patch) is that you must not have or create any FAT32 partitions. However, this is a problem, because most users today *do* have FAT32 partitions on huge harddisks. > Since no FAT32 partitions are used (or read with the > binary patch) DR-DOS 7.03 is still limited to 2 Gb > partitions isn't it? Yes, as the FAT16B partition limit is 2 Gb (with 32 Kb sized clusters)... This is no limit in DR-DOS, it is a limit in the design of the filesystem and applies to all systems supporting FAT16. Only Windows NT and FreeDOS support 64 Kb clusters, which give a maximum of 4 Gb per (non-standard) FAT16B partition. But 64 Kb clusters are extremely inefficient, even 32 Kb clusters are... After all, reducing the cluster overhang was one of the two reasons, why FAT32 was introduced. So, the advantage of the described solution would not be to increase the size of a single FAT16B partition. But you would be able to use *more* such partitions on a single harddisk, as the partitions do no longer have to be located in the first 8 Gb of the harddisk. > Would this combination of IBMBIO.COM files and the > binary patch mean the evolution of DR-DOS 7.03b to > DR-DOS 7.03c? What do you mean by DR-DOS 7.03B or 7.03C? Since you still use the 7.03 IBMDOS.COM file, the DOS kernel (BDOS) would not change in any way. Anyway, I still recommend the E5h method, it's a proven method. It's a bit more complicated to set up and does not give you LBA capabilities, but don't forget that DR-DOS 7.04/7.05 is an OEM version, which has not undergone such extensive testing as the desktop DR-DOS 7.03 version has. I would consider DR-DOS 7.04/7.05 to be still BETA in terms of reliability for desktops. So, use it at your own risk... Of course, the actual solution would be to fix the problems in DR-DOS 7.05, but this isn't possible with just a binary patch. Greetings, Matthias -- ; http://www.uni-bonn.de/~uzs180/mpdokeng.html; http://mpaul.drdos.org "Programs are poems for computers."