From: "Matthias Paul" Organization: Rechenzentrum RWTH Aachen To: opendos AT delorie DOT com Date: Wed, 5 Jul 2000 17:47:50 +0100 Subject: Re: good DOS - bad DOS X-mailer: Pegasus Mail v3.22 Message-ID: <1D09E41F5D@reze-1.rz.rwth-aachen.de> Reply-To: opendos AT delorie DOT com On Sun, 25 Jun 2000, Christoph Fuchs wrote: > Can anybody tell me why DR-DOS 7.02 is better than DR-DOS 7.03? > I only use #7.03, but I tried #7.02, too. > In my opinion, #7.03 is the better one. Or isn't it like this? I too think that 7.03 is "better" compared to 7.02. But mind that due to the multitude of dirty hacks in applications, DOS is a very fragile architecture, and even minor changes or bug fixes may cause other applications to fail. And if you happen to use such an application you might be better off with 7.02.. In an ideal world where all necessary interfaces would have been bug-free and documented right from the start, and only a *single* way to get a single info would exist, this should have never happened. But real life is different, and almost any non-trivial DOS application uses undocumented DOS (or even worse, just peeks and pokes around in DOS s code or data, even leaving the "well-known" undocumented interfaces alone...) Under DOS, the term compatibility goes to such an extend, that for example DR-DOS has to emulate obvious bugs in MS-DOS to get some applications working. (Reading the OpenDOS kernel source history or Ralf Brown s INTERxx gives a good overview on this. BTW, the next issue, INTER61, should eventually be available this weekend.) But you never know all the invalid (and undocumented) assumptions (closed-sourced) applications make on the operating system, so changing anything to work around a problem with application A is similar to risking compatibility problems with application B. This makes it very difficult to enhance the kernel. Think of the FDISK 2.00-2.14 problems: Changing the OEM label or even changing the sector/cluster allocation scheme (to be sub- optimal in terms of storage space) should not have caused any problems at all, since the BIOS Parameter Block (BPB - a structure at the beginning of each drive s boot sector) contains all the info how to properly access the drive. Even when created with DR-DOS FDISK 2.00-2.14... DR-DOS uses this info and has no problems to access such partitions - but as we know know - MS- DOS/PC DOS and OS/2 only partially use this info, and only under certain conditions. Another problem with DR-DOS 7.03 is the INT 21h/6602h bug, I mentioned some months ago. There are a number of other problems: e.g. a bug in the 2nd level BIOS decompressor code may cause the floppy parameters to get trashed if they were not copied to 5C00h by the boot sector (which is a rare condition that can only happen with certain boot loaders), there s a bug introduced with the improper *removal* of the LPT4 device (which was not actually buggy BTW), when somone still attempts to use PRN=4 afterwards, there s a bug where on old machines (not supporting resume from power saving modes) some BIOS code may reside in un-allocated memory. However, many other bugs that existed in earlier issues have been fixed (see WHATSNEW.TXT), and all of the problems listed here have already been fixed Caldera/Lineo in-house, although this is still not publically available for reasons I cannot explain. DR-DOS 7.02 pro s: - it still supports that LPT4 device ;-) - the original issue should also still allow to boot off any harddisk (I m not completely sure about this any more) DR-DOS 7.03 pro s: - it allows to relocate BIOS and COMMAND shell into the HMA under all conditions again - it allows to login non-standard drives DR-DOS 7.03 con s: - it has a slightly bigger total memory footprint, which however is more than backed up by the better HMA load capabilities Hope it helps, Matthias ------------------------------------------------------------------- Matthias Paul, Ubierstrasse 28, D-50321 Bruehl, Germany eMail: Web : http://www.rhrz.uni-bonn.de/~uzs180/mpdokeng.html -------------------------------------------------------------------