🚀 go-pugleaf

In article <26038@cup.portal.com>, cliffhanger@cup.portal.com (Cliff C Heyer) writes:
> Books explain int 21h calls as being more 
> functional and portable than int 13h calls.
> But I'm wondering if there other important
> benefits of one method vs. the other.

13h (BIOS) calls can usually be made more efficient, because they bypass 
the DOS overhead.  But then _you_ have to put all of the DOS logic for 
interpreting the disk structure into your program - this is nontrivial, 
especially for a hard disk drive.  (Most hard disk drives _do_ patch into 
13h, but not all, so this isn't a foolproof way of getting to the hard 
disk drive).  All file protections and interpretations are turned off 
when you do I/O to the disk via 13h.  Remember that not all disks have
the same structure, and there are not well-documented ways for an
application program to determine what a given disk's structure is.

There have been benchmarks written which show that for most purposes,
most of the performance benefits which can be achieved with 13h calls
can be nearly equalled by using 21h (DOS) calls _if you use a large
buffer for your reads and writes_.  So for most purposes there really
isn't a compelling reason to use 13h.

The exceptions are for disk utilities that try to fix up the disk
structure.  Even there, it is usually better to use the DOS low-level
interface to the BIOS, since as noted above not all disk drivers will
patch themselves into the 13h vector (though most do).  These are
interrupts 25h and 26h.  Like the BIOS calls, they provide _no_
protection from program bugs, and perform _no_ interpretation of the
disk structure.

Proper use of the 13h, 25h, and 26h I/O calls is fairly difficult -
not recommended unless you have a compelling reason and have a fairly
in-depth understanding of the structure of MS-DOS.

						Bruce C. Wright