Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!rpi!zaphod.mps.ohio-state.edu!usc!apple!sun-barr!newstop!sun!imagen!qmsseq!pipkins From: pipkins@qmsseq.imagen.com (Jeff Pipkins) Newsgroups: comp.sys.ibm.pc Subject: Re: int 13h vs. int 21h disk I/O confusion Message-ID: <92@qmsseq.imagen.com> Date: 18 Jan 90 20:14:27 GMT References: <26038@cup.portal.com> Reply-To: pipkins@qmsseq.UUCP (Jeff Pipkins) Organization: QMS Inc., Mobile, Alabama Lines: 110 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: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!"