kenny@engr.uky.edu (Kenny Pitt) (08/19/88)
I have a bone to pick with Peter Norton. I decided to do it here since I am
using this as an opportunity to let you all know about some of the software
incompatibilities I have discovered with DOS 4.0.
As almost everyone who has done any programming on the IBM PC knows, IBM and
Microsoft have provided us with a number of invaluable DOS function calls
through the "int 21h" interface. All the functions that were intended for
general use have been fully documented and publicized. There are, however,
some other undocumented, unpublicized functions that are used by DOS
internally that are not intended for general use. With the exception that I
have converted decimal numbers to hex, I quote here directly from page 281
of my copy of "The Peter Norton Programmer's Guide to the IBM PC."
Function 24 (18h) and functions 29 (1dh) through 32 (20h) are used
by DOS for its own internal purposes. Although there is limited
information about these services available, it is unwise to use
this information or spread it around. Any DOS function that is not
publicly advertised as an available service cannot be relied upon
to be usable in future revisions of DOS.
Now we all know that Peter Norton knows about as much about the IBM PC as
anyone and has provided us with an invaluable tool in his famous Norton
Utilities. Unfortunately, this is one time where Peter didn't practice what
he preaches. Several of his Norton Utilities make calls to the undocumented
DOS function 1fh in order to obtain some information about disk format. In
DOS 4.0, the table returned by this function has changed from the format in
the DOS 2.x and 3.x versions. This means that all programs that rely on this
table for information are now incompatible with DOS 4.0.
Here is a list of a few software packages that I have already found to be
incompatible with DOS 4.0 due to the use of DOS function 1fh or another
undocumented function, function 32h, which returns the same information. For
some packages I have listed in parentheses the component programs that I have
had trouble with. In these cases, other components may be compatible or I may
have just not gotten around to trying them all.
Norton Utilities, Advanced Edition (NU.EXE, SD.EXE, QU.EXE, UD.EXE,
DS.EXE)
SoftLogic Solutions Disk Optimizer V2.01
PCTools Deluxe V4.11 (PCTOOLS.EXE, COMPRESS.EXE, MIRROR.EXE)
Shareware Disk OrGanizer V1.01a
Some other programs that are incompatible, but not necessarily due to use of
the uncdocumented function calls are:
Shareware NARC archive viewer/extractor (gets errors and crashes when it
tries to read the FAT to build the directory tree. May be getting its FAT and
directory pointers from one of the undocumented function calls)
SpinRite V1.0 (does not recognize the larger partition sizes available
under DOS 4.0)
For those who are interested, here is some technical information that I have
gleaned from hex dumps of the FAT on my 42Meg hard drive formatted under DOS
4.0 and from a lot of work with CodeView on such programs as Norton's Speed
Disk.
The undocumented function calls 1fh and 32h return a pointer in DS:BX to a
table that contains some information about disk allocation for a drive
specified in the AL register. The important pieces in terms of compatibility
begin at offset 0fh where the number of sectors in the FAT is found. In DOS
3.3 and earlier the maximum number of sectors in the FAT was 64, so 1 byte was
sufficient to hold this value. However, in DOS 4.0 this value can be much
higher since disks of up to 2 gigabytes (2048Meg) are supported so it was
changed to a word. This throws the position of all following information off
by 1 byte. The most important piece that is affected is the one immediately
following which contains the logical sector number where the first directory
sector begins. Programs which try to read this sector number from offset 10h
will get the wrong value under DOS 4.0 since it is now at offset 11h. This
appears to be the main problem with the Norton Utilities and some of the disk
optimizer programs, but there may be other considerations as well.
As a sidenote to the above discussion, when I first read that DOS 4.0
supported 32-bit logical sector numbers, I assumed that it also supported a
32-bit FAT. This may or may not be true, but for disks up to 128Meg, DOS 4.0
definately sticks with a 16-bit FAT since a 16-bit FAT using 2k clusters adds
up to exactly 128 Meg. This means that programs that read the FAT directly
SHOULDN'T have any trouble with DOS 4.0 since the FAT format up to 128Meg is
unchanged from the DOS 3.x series. The reason DOS 3.x could not pass the
32Meg barrier even with a 16-bit FAT is that DOS has to compute logical sector
pointers internally to access a particular cluster. DOS 3.x used 16-bit
sector numbers internally and since sectors are only 512 bytes, 65536 x 512 is
only 32Meg. The problem with DOS 4.0, then, seems to be in finding the proper
pointers to the FAT and directory sectors.
If anyone (maybe one of the folks from Microsoft) could post some information
on the various FAT formats used by DOS 4.0 in order to achieve the 2048Meg
disk size I would greatly appreciate it. I am also interested in knowing why
SHARE.EXE is needed when the partition size is greater than 32Meg.
I hope that SOME of this information has been helpful to SOMEONE, and if
anyone can expand on any of this or correct me on any of these points, I would
be glad to here from you.
--
-- Kenny Pitt | INTERNET: kenny@engr.uky.edu
-- | UUCP: ihnp4!cbosgd!ukma!ukecc!kenny
-- "Fascinating." | BITNET: kenny%ukecc.uucp@ukma
--Ralf.Brown@B.GP.CS.CMU.EDU (09/01/88)
In article <2644@ukecc.engr.uky.edu>, kenny@engr.uky.edu (Kenny Pitt) writes: }.... I quote here directly from page 281 }of my copy of "The Peter Norton Programmer's Guide to the IBM PC." } } Any DOS function that is not } publicly advertised as an available service cannot be relied upon } to be usable in future revisions of DOS. Just because a function is documented does not mean it will stay the same in future releases, either. INT 21h/AH=38h (Get Country-Dependent Information) changed rather drastically between DOS 2.x and 3.x, and not entirely in an upwardly-compatible fashion (the buffer for returned data has everything past the second item shifted by four bytes). -- UUCP: {ucbvax,harvard}!cs.cmu.edu!ralf -=-=-=- Voice: (412) 268-3053 (school) ARPA: ralf@cs.cmu.edu BIT: ralf%cs.cmu.edu@CMUCCVMA FIDO: Ralf Brown 1:129/31 Disclaimer? I |Ducharm's Axiom: If you view your problem closely enough claimed something?| you will recognize yourself as part of the problem.
feg@clyde.ATT.COM (Forrest Gehrke) (09/01/88)
In article <2644@ukecc.engr.uky.edu>, kenny@engr.uky.edu (Kenny Pitt) writes: |> I have a bone to pick with Peter Norton. I decided to do it here since I am |> using this as an opportunity to let you all know about some of the software |> incompatibilities I have discovered with DOS 4.0. |> |> [quoted from Norton's book]....... Any DOS function that is not |> publicly advertised as an available service cannot be relied upon |> to be usable in future revisions of DOS. |> |> Now we all know that Peter Norton knows about as much about the IBM PC as |> anyone and has provided us with an invaluable tool in his famous Norton |> Utilities. Unfortunately, this is one time where Peter didn't practice what |> he preaches. Several of his Norton Utilities make calls to the undocumented |> DOS function 1fh in order to obtain some information about disk format. In |> DOS 4.0, the table returned by this function has changed from the format in |> the DOS 2.x and 3.x versions. This means that all programs that rely on this |> table for information are now incompatible with DOS 4.0. This is problem for any program which must read disk information. There are no other means than these undocumented functions, except to look at the disk boot record and the FAT itself. If what you have described is the case, these latter methods will fail also, because the formats of the boot record and FAT must also have been changed. Norton describes the organization of the boot record and FAT in his book. With DEBUG you could look at these sectors to see how these have been changed. I am sure this information would be of interest. Presumably, then the fault must be laid at Microsoft's door for not having come up with a scheme which is downwardly compatible (or having failed to think big enough back at dos 2.0). Forrest Gehrke
ldh@hcx1.SSD.HARRIS.COM (09/02/88)
By the way ... Norton now has available a revised version of his utilities (I just received my copy) that supposedly works with DOS 4.. I say supposedly as I do not (yet) have 4.x to verify it with ... Leo Hinds *net: ldh@hdw.harris.com uunet!hcx1!hardy!ldh usps: Harris CSD, ms 156, 2101 W Cypress Creek Rd, Ft Lauderdale FL 33309 at&t: (305)973-5229