cliffhanger@cup.portal.com (Cliff C Heyer) (01/17/90)
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. A point of confusion is what do compilers output. The C compiler gives you a choice of what to use, but I assume other languages may use either 13h or 21h when you compile a program, and you might not know which one is used(?) Also 21h gives more than one way of doing disk I/O (FCBs, Fcn. 44 & _dos_ interface calls). Do you use switches to control which is used in some languages? Further, books say 13h is for floppies only. If you write a program using 13h, does it crash if you try it on a hard disk? Does the compiler generate code that detects a hard disk and and substitute 21h calls? Also, do 13h and 21h access installed device drivers the same way, or does 13h speak the WD1003 interface language only and bypass any installed device drivers. Perhaps I have not found the right book that really explains all this stuff. Cliff
dhinds@portia.Stanford.EDU (David Hinds) (01/18/90)
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. > Int 13h points to the BIOS low-level disk I/O routines. It does only low-level I/O - like seek to track n, and read m sectors. Programs running under DOS should never use it, because it bypasses DOS's file structure, and using it can easily trash your disks. It works independent of DOS, and knows nothing about device drivers. Int 21h is the standard entry point for all DOS services. I doubt that any compiler's I/O library would use Int 13h calls, because they would be nothing but trouble. -David Hinds dhinds@portia.stanford.edu
kaleb@mars.jpl.nasa.gov (Kaleb Keithley) (01/19/90)
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. > >Perhaps I have not found the right book that >really explains all this stuff. > I am do not make a habit of endorsing any Microsoft product, but I have found the MS-DOS encyclopedia from Microsoft Press to be an invaluable resource for answering just such questions as these. At $65 for the paperback, it is a good investment. Chewey, get us outta here! kaleb@mars.jpl.nasa.gov (818)354-8771 Kaleb Keithley
pipkins@qmsseq.imagen.com (Jeff Pipkins) (01/19/90)
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. Int 13h is a BIOS call. It was written for use by the operating system. Int 21h is an operating system call (PC/MS-DOS). Int 13h was not intended for direct use via an application program. >A point of confusion is what do compilers >output. The C compiler gives you a choice of >what to use, but I assume other languages >may use either 13h or 21h when you compile >a program, and you might not know which one >is used(?) Also 21h gives more than one >way of doing disk I/O (FCBs, Fcn. 44 & >_dos_ interface calls). Do you use switches >to control which is used in some languages? First of all, file I/O is not part of the C language per se; no file I/O is included in the C language at all. So the compiler does not emit code to call file I/O services. C programs usually perform file I/O by calling functions in a "standard" library, in other words, by calling read(), write(), fread(), printf(), etc. These function SHOULD NOT call int 13h, but should make all requests via standard DOS calls (int 21h). This is true of MSC & Turdo C libraries. >Further, books say 13h is for floppies only. Not so. There are some functions provided by int 13h that are only for floppies, some that are only for fixed disk, some new ones that are only for ESDI disks, and many that are for any disk. >Also, do 13h and 21h access installed device >drivers the same way, or does 13h speak >the WD1003 interface language only and >bypass any installed device drivers. Original intent was that the disk device driver(s) perform the actual dirty work by making calls to int 13h, but there is certainly nothing to prevent a driver from taking over int 13h and providing its own services. >But I'm wondering if there other important >benefits of one method vs. the other. Always use the int 21h calls in your application programs. If you MUST do absolute reads & writes, use int 25h & int 26h (also DOS calls), but only if you must. The only time it makes sense to use int 13h is: (A) if you are writing a disk device driver or disk caching program (B) if you need a function not provided by DOS (like format a track), or (C) if you are writing a TSR, there are certain reasons for using and/or watching the int 13h vector. >Perhaps I have not found the right book that >really explains all this stuff. Good conclusion. Unfortunately, neither have I, but I'm sure that it's because I haven't been looking. Standard advice is to start with one of Peter Norton's books. If you do, make sure it is a recent one; disk drive software in MS-DOS and various BIOSes have changed a lot since the PC was introduced. Here are some invaluable references: The MS-DOS Encyclopedia: stupid, arragant name, outrageous $75 price for paperback book, but every MS-DOS systems programmer should have one. The MS-DOS (or PC-DOS) technical reference manual: You can live without it if you have the MS-DOS Encyclopedia. If you are an MS-DOS application programmer, you can get by with this instead. The IBM PC and/or AT tech. ref. manual: Contains original PC/AT BIOS listings, with some hardware info as well. PD1:<MSDOS.SYSUTL>INTER190.ARC Useful listing of interrupt service calls, many are otherwise undocumented for the general public. Calls are documented for DOS and BIOS, as well as many other applications and system software gadgets that run on the same architecture. =========================================== pipkins@imagen.com All opinions expressed are mine only. Remember what my "Papaw" used to say, "I've already told you more than I know!"
cs4g6ag@maccs.dcss.mcmaster.ca (Stephen M. Dunn) (01/19/90)
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.
Well, int 21h is an MS-DOS call; int 13h is an IBM PC call. int 21h works
with files; int 13h works with individual tracks and sectors. int 21h works
with all kinds of disks; int 13h works with floppies only.
$is used(?) Also 21h gives more than one
$way of doing disk I/O (FCBs, Fcn. 44 &
$_dos_ interface calls). Do you use switches
$to control which is used in some languages?
These days, I don't think any compilers would generate FCB calls for
any function that can be done using handles. Handle calls are available
in DOS 2.00 and up, and since virtually nobody uses DOS 1.xx anymore, it
makes no sense to have to put up with the restrictions of FCBs (such as
not being able to use pathnames). I've only been using assorted compilers
on PCs for about three years, but the ones I've used (Turbo Pascal 3 and +,
Lattice C 3.10, Turbo C 2.0, Clipper, a couple of others) all require DOS
2 or higher and use handles, and I've never seen one that allows you to
force it to use FCBs. One big reason for this would be that this change
would not be in the code generated for the compiler, but would actually
require a whole new disk I/O library to be created for each memory model.
Also, there's the lack of flexibility in FCB calls ...
[questions about hard disks and stuff]
I've never tried using int 13h, but I would imagine it would return an
error code if you tried it on a hard disk (but then again, we're discussing
IBM here ...) If you want a method that works on all MS-DOS machines and
will use hard or floppy disks, but you don't want to use file I/O calls,
you might want to check out int 25h (absolute disk read) and 26h (absolute
disk write).
--
Stephen M. Dunn cs4g6ag@maccs.dcss.mcmaster.ca
<std_disclaimer.h> = "\nI'm only an undergraduate!!!\n";
****************************************************************************
"I want to look at life - In the available light" - Neil Peartbcw@rti.UUCP (Bruce Wright) (01/20/90)
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