`
`Foreword, Bill Gates
`General Editor, Ray Duncan
`
`HUAWEI EX. 1010 - 1/1582
`
`
`
`The
`
`Encyclopedia
`
`HUAWEI EX. 1010 - 2/1582
`
`
`
`
`
`...
`
`Encyclopedia Staff
`
`Editor-in-Chlef: Susan Lammers
`
`Editorial Director: Patricia Pratt
`
`Senior Editor: Dorothy L. Shattuck
`
`Senior Technical Editor: David L. Rygmyr
`
`Special Projects Editor: Sally A. Brunsman
`
`Editorial Coordinator: Sarah Hersack
`
`Associate Editors and Technical Editors:
`Pamela Beason, Ann Becherer, Bob Combs,
`Michael Halvorson, Jeff Hinsch, Dean Holmes,
`Chris Kinata, Gary Masters, Claudette Moore,
`Steve Ross, Roger Shanafelt, Eric Stroo,
`Lee1 Thomas, JoAnne Woodcock
`
`Copy Chief: Brianna Morgan. Proofreaders:
`Kathleen Atkins, Julie Carter, Elizabeth
`Eisenhood, Matthew Eliot, Patrick Forgette,
`Alex Hancock, Richard Isomaki, Shawn Peck,
`Alice Copp Smith
`
`Editorial Assistants: Wallis Bolz, Charles Brod,
`Stephen Brown, Pat Erickson, Debbie Kern, Susanne
`McRhoton, Vihn Nguyen, Cheryl VanGeystel
`
`Index: Shane-Armstrong Information Services
`
`Production: Larry Anderson, Jane Bennett, Rick
`Bourgoin, Darcie S. Furlan, Nick Gregoric, Peggy
`Herman, Lisa Iversen, Rebecca Johnson, Ruth Pettis,
`Russell Steele, Jean Trenary, Joy Ulskey
`
`Marketing and Sales Director: James Brown
`
`Director of Production: Christopher D. Banks
`
`Publisher: Min S. Yee
`
`HUAWEI EX. 1010 - 4/1582
`
`
`
`Contributors
`
`Ray Duncan, General Editor Duncan received a B.A. in Chemistry from the University of Califor-
`nia, Riverside, and an M.D. from the University of California, Los Angeles, and subsequently received
`specialized training in Pediatrics and Neonatology at the Cedars-Sinai Medical Center in Los Angeles. He
`has written many articles for personal computing magazines, including BYTE, PC Magazine, Dr. Dobb·s
`journal, and Sojtalk!PC, and is the author of the Microsoft Press book Advanced MS-DOS. He is the
`founder of Laboratory Microsystems Incorporated, a software house specializing in FORTH interpreters
`and compilers.
`
`Steve Bostwick
`Bostwick holds a B.S. in Physics from the University of California, Los Angeles, and
`has over 20 years' experience in scientific and commercial data processing. He is president of Query
`Computing Systems, Inc., a software firm specializing in the creation of systems for applications that
`interface microcomputers with specialized hardware. He is also an instructor for the UCLA Extension
`Department of Engineering and Science and helped design their popular Microprocessor Hardware and
`Software Engineering Certificate Program.
`
`Keith Burgoyne Born and raised in Orange County, California, Burgoyne began programming in
`1974 on IBM 370 mainframes. In 1979, he began developing microcomputer products for Apples,
`TRS-80s, Ataris, Commodores, and IBM PCs. He is presently Senior Systems Engineer at Local Data of
`Torrance, California, which is a major producer ofiBM 3174/3274 and System 3X protocol conversion
`products. His previous writing credits include numerous user manuals and tutorials.
`
`Robert A Byers Byers is the author of the bestselling Everyman "s Database Primer. He is presently
`involved with the Emerald Bay database project with RSPI and Migent, Inc.
`
`Thorn Hogan During 11 years working with personal computers, Hogan has been a software devel-
`oper, a programmer, a technical writer, a marketing manager, and a lecturer. He has written six books,
`numerous magazine articles, and four manuals. Hogan is the author of the forthcoming Microsoft Press
`book PC Programmers Sourcebook.
`
`jim Kyle Kyle has 23 years' experience in computing. Since 1967, he has been a systems program-
`mer with strong telecommunications orientation. His interest in microcomputers dates from 1975. He is
`currently MIS Administrator for BTl Systems, Inc., the OEM Division ofBancTec Inc., manufacturers of
`MICR equipment for the banking industry. He has written 14 books and numerous magazine articles
`(mostly on ham radio and hobby electronics) and has been primary Forum Administrator for Computer
`Language Magazine's CLMFORUM on CompuServe since early 1985.
`
`Gordon Letwin
`Letwin is Chief Architect, Systems Software, Microsoft Corporation. He is the author
`of Inside OS/2, published by Microsoft Press.
`
`Charles Petzold
`Petzold holds an M.S. in Mathematics from Stevens Institute of Technology. Before
`launching his writing career, he worked 10 years in the insurance industry, programming and teaching
`programming on IBM mainframes and PCs. He is the author of the Microsoft Press book Programming
`Windows 2. 0, a contributing editor to PC Magazine, and a frequent contributor to the Microsoft Systems
`journal.
`
`Chip Rabinowitz Rabinowitz has been a programmer for 11 years. He is presently chief program(cid:173)
`mer for Productivity Solutions, a microcomputer consulting firm based in Pennsylvania, and has been
`Forum Administrator for the CompuServe MICROSOFT SIG since 1986.
`
`Contributors
`
`Vii
`
`HUAWEI EX. 1010 - 5/1582
`
`
`
`Jim TomUn
`Tomlin holds a B.S. and an M.S. in Mathematics. He has programmed at Boeing,
`Microsoft, and Opcon and has taught at Seattle Pacific University. He now heads his own company in
`Seattle, whkh specializes in PC systems programming and industrial machine vision applications.
`
`Richard Wilton Wilton has programmed extensively in PL/1, FORTRAN, FORTH, C, and several
`assembly languages. He is the author of Programmer's Guide to PC & PS/2 Video Systems, published
`by Microsoft Press.
`·
`
`Van Wolverton A professional writer since 1963, Wolverton has had bylines as a newspaper reporter,
`editorial writer, political columnist, and technical writer. He is the author of Running MS-DOS and
`Supercharging MS-DOS, both published by Microsoft Press.
`
`William Wong Wong holds engineering and computer science degrees from Georgia Tech and
`Rutgers University. He is director of PC Labs and president of Logic Fusion, Inc. His interests include
`operating systems, computer languages, and artificial intelligence. He has written numerous magazine
`articles and a book on MS-DOS.
`
`JoAnne Woodcock Woodcock, a former senior editor at Microsoft Press, has been a writer for
`Encyclopaedia Britannica and a freelance and project editor on marine biological studies at the
`University of Southern California. She is co-editor (with Michael Halvorson) of XENIX at Work and
`co-author (with Peter Rinearson) of Microsoft Word Style Sheets, both published by Microsoft Press.
`
`Special Technical Advisor
`Mark Zbikowski
`
`Technical Advisors
`
`Paul Allen
`Steve Ballmer
`Reuben Borman
`Rob Bowman
`John Butler
`Chuck Carroll
`Mark Chamberlain
`David Chell
`Mike Colee
`Mike Courtney
`Mike Dryfoos
`Rachel Duncan
`Kurt Eckhardt
`Eric Evans
`Rick Farmer
`Bill Gates
`
`Michael Geary
`Bob Griffin
`Doug Hogarth
`James W. Johnson
`Kaamel Kermaani
`Adrian King
`Reed Koch
`James Landowski
`Chris Larson
`Thomas Lennon
`DanLipkie
`Marc McDonald
`Bruce McKinney
`Pascal Martin
`Estelle Mathers
`Bob Matthews
`
`David Melin
`Charles Mergentime
`Randy Nevin
`Dan Newell
`TaniNewell
`David Norris
`Mike O'Leary
`BobO'Rear
`Mike Olsson
`Larry Osterman
`Ridge Ostling
`Suni!Pai
`Tim Paterson
`Gary Perez
`Chris Peters
`Charles Petzold
`
`John Pollock
`Aaron Reynolds
`Darryl Rubin
`Ralph Ryan
`Karl Schulmeisters
`RajenShah
`Barry Shaw
`Anthony Short
`Ben Slivka
`Jon Smirl
`Betty Stillmaker
`John Stoddard
`Dennis Tillman
`Greg Whitten
`Natalie Yount
`SteveZeck
`
`Viii
`
`The MS-DOS Encyclopedia
`
`HUAWEI EX. 1010 - 6/1582
`
`
`
`Contents
`
`Foreword by Bill Gates
`Preface by Ray Duncan
`Introduction
`Section I: The Development ofMS-DOS
`Section II: Programming in the MS-DOS Environment
`Part A: Structure of MS-DOS
`
`xiii
`
`XV
`xvii
`1
`47
`
`Article 1:
`Article 2:
`Article 3:
`
`An Introduction to MS-DOS 51
`The Components of MS-DOS 61
`MS-DOS Storage Devices 85
`
`Part B: Programming for MS-DOS
`
`Article 4: Structure of an Application Program 107
`Article 5: Character Device Input and Output 149
`Article 6:
`Interrupt-Driven Communications 167
`Article 7: File and Record Management 247
`Article 8: Disk Directories and Volume Labels 279
`Article 9: Memory Management 297
`Article 10: The MS-DOS EXEC Function 321
`
`Part C: Customizing MS-DOS
`
`Article 11: Terminate-and-Stay-Resident Utilities 347
`Article 12: Exception Handlers 385
`Article 13: Hardware Interrupt Handlers 409
`Article 14: Writing MS-DOS Filters 429
`Article 15: Installable Device Drivers 447
`
`Part D: Directions ofMS-DOS
`
`Article 16: Writing Applications for Upward Compatibility 489
`Article 17: Windows 499
`
`PartE: Programming Tools
`
`Article 18: Debugging in the MS-DOS Environment 541
`Article 19: Object Modules 643
`Article 20: The Microsoft Object Linker 701
`
`Contents
`
`ix
`
`HUAWEI EX. 1010 - 7/1582
`
`
`
`723
`
`961
`
`1175
`
`1431
`
`Section lll: User. Commands
`Introduction 725
`
`User commands are listed in alphabetic order. This section includes ANSI.SYS,
`BATCH, CONFIG.SYS, DRIVER.SYS,_ EDLIN, RAMDRIVE.SYS, and VDISK.SYS.
`Section IV: Programming Utilities
`Introduction 963
`
`CREF 967
`EXE2BIN 971
`EXEMOD 974
`EXEPACK 977
`LIB 980
`LINK 987
`MAKE 999
`MAPSYM 1004
`MASM 1007
`
`Microsoft Debuggers:
`
`DEBUG 1020
`SYMDEB 1054
`CodeView 1157
`Section V: System Calls
`Introduction 1177
`
`System calls are listed in numeric order.
`Appendixes
`
`Appendix A:
`AppendixB:
`AppendixC:
`AppendixD:
`AppendixE:
`AppendixF:
`AppendixG:
`AppendixH:
`Appendix I:
`Appendix]:
`AppendixK:
`AppendixL:
`AppendixM:
`AppendixN:
`AppendixO:
`
`MS-DOS Version 3.3 1433
`Critical Error Codes 1459
`Extended Error Codes 1461
`ASCII and IBM Extended ASCII Character Sets 1465
`EBCDIC Character Set 1469
`ANSI.SYS Key and Extended Key Codes 1471
`File Control Block (FCB) Structure 1473
`Program Segment Prefix (PSP) Structure 1477
`8086/8088/80286/80386 Instruction Sets 1479
`Common MS-DOS Filename Extensions 1485
`Segmented (New) .EXE File Header Format 1487
`Intel Hexadecimal Object File Format 1499
`8086/8088 Software Compatibility Issues 1507
`An Object Module Dump Utility 1509
`IBM PC BIOS Calls 1513
`
`X
`
`The MS-DOS Encyclopedia
`
`HUAWEI EX. 1010 - 8/1582
`
`
`
`Indexes
`
`Subject 1533
`Commands and System Calls 1565
`
`1531
`
`Contents
`
`xi
`
`HUAWEI EX. 1010 - 9/1582
`
`
`
`I !
`
`'
`
`Foreword
`
`Microsoft's MS-DOS is the most popular piece of software in the world. It runs on more
`than 10 million personal computers worldwide and is the foundation for at least 20,000
`applications- the largest set of applications in any computer environment. As an industry
`standard for the family of 8086-based microcomputers, MS-DOS has had a central role in
`the personal computer revolution and is the most significant and enduring factor in fur(cid:173)
`thering Microsoft's original vision- a computer for every desktop and in every home. The
`challenge of maintaining a single operating system over the entire range of 8086-based
`microcomputers and applic:;ttions is incredible, but Microsoft has been committed to meet(cid:173)
`ing this challenge since the release of MS-DOS in 1981. The true measure of our success
`in this effort is MS-DOS's continued prominence in the microcomputer industry.
`
`Since MS-DOS's creation, more powerful and much-improved computers have entered the
`marketplace, yet each new version of MS-DO$ reestablishes its position as the foundation
`for new applications as well as for old. To explain this extraordinary prominence, we must
`look to the origins of the personal computer industry. The three most significant factors in
`the creation of MS-DOS were the compatibility revolution, the development of Microsoft
`BASIC and its widespread acceptance by the personal computer industry, and IBM's deci(cid:173)
`sion to build a computer that incorporated 16-bit technology.
`
`The compatibility revolution began with the Intel8080 microprocessor. This technolog(cid:173)
`ical breakthrough brought unprecedented opportunities in the emerging microcomputer
`industry, promising continued improvements in power, speed, and cost of desktop com(cid:173)
`puting. In the minicomputer market, every hardware manufacturer had its own special
`instruction set and operating system, so software developed for a specific machine was in(cid:173)
`compatible with the machines of other hardware vendors. This specialization also meant
`tremendous duplication of effort- each hardware vendor had to write language compilers,
`databases, and other development tools to fit its particular machine. Microcomputers
`based on the 8080 microprocessor promised to change all this beqmse different manu(cid:173)
`facturers would buy the same chip with the same instruction set.
`
`From 1975 to 1981 (the 8-bit era of microcomputing), Microsoft convinced virtually
`every personal computer manufacturer- Radio Shack, Commodore, Apple, and doz~ns
`of others- to build Microsoft BASIC into its machines. For the first time, one common lan(cid:173)
`guage cut across all hardware vendor lines. The success of our BASIC demonstrated the
`advantages of compatibility: To their great benefit, users were finally able to move appli(cid:173)
`cations from one vendor's machine to another.
`
`Most machines produced during this early period did not have a built-in disk drive.
`Gradually, however, floppy disks, and later fixed disks, became less expensive and more
`common, and a number of disk-based programs, including WordStar and dBASE, entered
`the market. A standard disk operating system that could accommodate these develop(cid:173)
`ments became extremely important, leading Lifeboat, Microsoft, and Digital Research all to
`support CP/M-80, Digital Research's 8080 DOS.
`
`Foreword
`
`Xiii
`
`HUAWEI EX. 1010 - 10/1582
`
`
`
`
`
`
`
`
`
`
`
`Italic font indicates user-supplied variable names, procedure names in text, parameters
`whose values are to be supplied by the user, reserved words in the C programming lan(cid:173)
`guage, messages and return values in text, and, occasionally, emphasis.
`
`A typographic distinction is made between lowercase l and the numerall in both text and
`1
`program listings.
`
`Cross-references appear in the form SECTION NAME: PART NAME, CoMMAND NAME, OR IN(cid:173)
`TERRUPT NUMBER: Article Name or Function Number.
`
`Color indicates user input and program examples.
`Terminology
`Although not an official IBM name, the term PC-DOS in this book means the IBM imple(cid:173)
`mentation of MS-DOS. If PC-DOS is referenced and the information differs from that for
`the related MS-DOS version, the PC-DOS version number is included. To avoid confusion,
`the term DOS is never used without a modifier.
`
`The names of special function keys are spelled as they are shown on the IBM PC keyboard.
`In particular, the execute key is called Enter, not Return. When <Enter> is included in a
`user-entry line, the user is to press the Enter key at the end of the line.
`
`The common key combinations, such as Ctrl-C and Ctrl-Z, appear in this form when the
`actual key to be pressed is being discussed but are written as Control~C, Control-Z, and so
`forth when the resulting code is the true reference. Thus, an article might reference the
`Control-Chandler but state that it is activated when the user presses Ctrl-C.
`
`Unless specifically indicated, hexadecimal numbers are used throughout. These numbers
`are always followed by the designation H (h in the code portions of program listings).
`Ranges of hexadecimal values are indicated with a dash- for example, 07 -OAH.
`
`The notation (more) appears in italic at the bottom of program listings and tables that are
`continued on the next page. The complete caption or table title appears on the first page
`of a continued element and is designated Continued on subsequent pages.
`
`Introduction
`
`xix
`
`HUAWEI EX. 1010 - 15/1582
`
`
`
`Section V, System Calls, documents Interrupts 20H through 27H and Interrupt 2FH. The
`Interrupt 21H functions are listed in individual entries. This section, like the User Com(cid:173)
`mands and Programming Utilities sections, presents a quick review of usage for the ex(cid:173)
`perienced user and also provides extensive notes for the less-experienced programmer.
`
`The 15 appendixes provide quick-reference materials, including a summary of MS-DOS
`version 3.3, the segmented (new) .EXE file header format, an object file dump utility, and
`the Intel hexadecimal object file format. Much of this material is organized into tables or
`bulleted lists for ease of use.
`
`The book includes two indexes- one organized by subject and one organized by com(cid:173)
`mand name or system-call number. The subject index provides comprehensive references
`to the indexed topic; the command index references only the major entry for the com(cid:173)
`mand or system call.
`
`Program listings
`
`The MS-DOS Encyclopedia contains numerous program listings in assembly language, C,
`and QuickBASIC, all designed to run on the IBM PC family and compatibles. Most of these
`programs are complete utilities; some are routines that can be incorporated into function(cid:173)
`ing programs. Vertical ellipses are often used to indicate where additional code would be
`supplied by the user to create a more functional program. All program listings are heavily
`commented and are essentially self-documenting.
`
`The programs were tested using the Microsoft Macro Assembler (MASM) version 4.0, the
`Microsoft C Compiler version 4.0, or the Microsoft QuickBASIC Compiler version 2.0.
`
`The functional programs and larger routines are also available on disk. Instructions for
`ordering are on the page preceding this introduction and on the mail-in card bound into
`this volume.
`
`Typography and Terminology
`
`Because The MS-DOS Encyclopedia was designed for an advanced audience, the reader
`generally will be familiar with the notation and typographic conventions used in this
`volume. However, for ease of use, a few special conventions should be noted.
`Typographic conventions
`Capital letters are used for MS-DOS internal and external commands in text and syntax
`lines. Capital letters are also used for filenames in text.
`
`xviii
`
`The MS-DOS Encyclopedia
`
`HUAWEI EX. 1010 - 16/1582
`
`
`
`
`
`
`
`
`
`
`
`
`010 - 17/1582
`
`
`
`HUAWEI EX. 1010 - 17/1582
`
`
`
`
`
`HUAWEI EX. 1010 - 18/1582
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`HUAWEI EX. 1010 - 64/1582
`
`
`HUAWEI EX. 1010 - 64/1582
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Article 6: Interrupt-Driven Communications
`
`Pop
`Les
`Lea
`Mev
`Cbw
`Add
`Add
`Jmp
`
`Ds
`Bx,PackHd
`Di,Asy_funcs
`Al,es:code[bx]
`
`get packet pointer
`point DI to jump table
`command code
`
`Ax, Ax
`Di,ax
`[di]
`
`double to word
`
`go do it
`
`get packet pointer
`
`set return status
`restore registers
`
`Exit from driver request
`
`Proc
`ExitP
`Bsyexit:
`Mev
`Jmp
`
`Far
`
`Ax,StsBsy
`Short Exit
`
`Mchek:
`BldBPB:
`Zexit: Xor
`Exit:
`Les
`Or
`Mev
`Pop
`Pop
`Pop
`Pop
`Pop
`Pop
`Pop
`Pop
`Popf
`Pop
`Ret
`Endp
`
`ExitP
`
`Ax,Ax
`Bx,PackHd
`Ax,StsDne
`Es:Stat[Bx],Ax
`Es
`Ds
`Bp
`Di
`Dx
`ex
`Bx
`Ax
`
`Si
`
`Subttl Driver Service Routines
`Page
`
`Read data from device
`
`Read:
`
`dbg
`Mev
`Mev
`Mev
`Push
`Push
`Mev
`Test
`Je
`Add
`
`'
`
`get requested nbr
`get target pointer
`
`'R' I'd', I
`Cx,Es:Count[bx]
`Di,Es:Xfer[bx]
`Dx,Es:Xseg[bx]
`Bx
`Es
`Es,Dx
`InStat[si],Badinp Or LostDt
`no error so far ...
`No_lerr
`error, flush SP
`Sp,4
`
`save for count fixup
`
`320
`321
`322
`323
`324
`325
`326
`327
`328
`329
`330
`331
`332
`333
`334
`335
`336
`337
`338
`339
`340
`341
`342
`343
`344
`345
`346
`347
`348
`349
`350
`351
`352
`353
`354
`355
`356
`357
`358
`359
`360
`361
`362
`363
`364
`365
`366
`367
`368
`369
`370
`
`Figure 6-1. Continued.
`
`(more)
`
`Section II: Programming in the MS-DOS Environment
`
`189
`
`HUAWEI EX. 1010 - 199/1582
`
`
`
`
`
`Article 6: Interrupt-Driven Communications
`
`'W', 'r'' •
`'
`cx,es:count[bx]
`Di,es:xfer[bx]
`Ax,es:xseg[bx]
`Es,ax
`
`Al,es: [di]
`Di
`
`Put_out
`Ah,O
`Wwait
`Start_output
`Wlup
`
`Zexit
`
`get the byte
`
`put away
`
`wait for room!
`get it going
`
`dbg
`Mev
`Mev
`Mev
`Mev
`
`Mev
`Inc
`
`Call
`Cmp
`Jne
`Call
`Loop
`
`Jmp
`
`Output status request
`
`Wwait:
`
`421 Write:
`422
`423
`424
`425
`426
`427 Wlup:
`428
`429
`430
`431
`432
`433
`434
`435
`436
`437
`438
`439
`440
`441
`442
`443
`444
`445
`446
`447
`448
`449
`450
`451
`452
`I oct lin:
`453
`Mev
`454
`Mev
`455
`Mev
`456
`Mev
`457
`Cmp
`458
`Je
`459
`MOV
`460
`Jmp
`461
`Doiocin:
`462
`Mev
`463
`MOV
`464
`Mev
`465
`466 Getport:
`In
`467
`Stos
`468
`Inc
`469
`Loop
`470
`471
`
`Txstat:
`
`Txroom:
`
`Mev
`Dec
`And
`Cmp
`Jne
`Jmp
`
`Jmp
`
`Ax,ofirst[si]
`Ax
`Ax,bufmsk
`Ax,oavail[si]
`Txroom
`Bsyexit
`
`Zexit
`
`buffer full
`
`room exists
`
`IOCTL read request, return line parameters
`
`Cx,es:count[bx]
`Di,es:xfer[bx]
`Dx,es:xseg[bx]
`Es,dx
`Cx,10
`Doiocin
`Ax,errbsl
`Exit
`
`Dx,port[si]
`Dl,Lctrl
`Cx,4
`
`Al,dx
`Byte Ptr [DI]
`Dx
`Get port
`
`base port
`line status
`LCR, MCR, LSR, MSR
`
`Figure 6-1. Continued.
`
`(more)
`
`Section Jl- Programming in the MS-DOS Environment
`
`191
`
`HUAWEI EX. 1010 - 201/1582
`
`
`
`
`
`
`
`Part B: Programming for MS-DOS
`
`Push
`Pushf
`Cli
`Mov
`Mov
`Inc
`And
`Cmp
`Je
`Add
`Mov
`Mov
`dbg
`Mov
`Jmp
`
`Mov
`
`Poerr:.
`
`574
`575
`576
`577
`578
`579
`580
`581
`582
`583
`584
`585
`586
`587
`588
`589
`590
`591
`592
`593
`594
`595
`596
`597
`598 Get_out Proc
`Push
`599
`Push
`600
`Pushf
`601
`Cli
`602
`Mov
`603
`Cmp
`604
`605
`Jne
`Mov
`606
`Jmp
`607
`608 Ngoerr:
`609
`610
`611
`612
`613
`614
`615
`616
`617 Goret:
`Popf
`618
`Pop
`619
`Pop
`620
`Ret
`621
`622 Get_out Endp
`623
`624
`
`Poret:
`
`Popf
`Pop
`Pop
`Ret
`Put_out Endp
`
`dbg
`Mov
`Add
`Mov
`Mov
`Inc
`And
`Mov
`
`Put_in Proc
`
`Di
`
`Cx,oavail[si]
`Di,cx
`Cx
`Cx,bufmsk
`Cx,ofirst[si]
`Poerr
`Di,obuf[si]
`[di],al
`Oavail[si],cx
`I ' '
`1 0 1
`1 P 1
`Ah,O
`Short
`
`Po ret
`
`I
`
`put ptr
`
`bump
`
`overflow?
`yes, don't
`no
`put in buffer
`
`Ah, -1
`
`Di
`Cx
`
`Near
`Cx
`Di
`
`gets next character from output ring buffer
`
`get ptr
`put ptr
`
`empty
`
`get char
`
`bump ptr
`wrap
`
`Di,ofirst[si]
`Di,oavail[si]
`Ngoerr
`Ah,-1
`Short
`
`Go ret
`
`I ' '
`
`'g' I
`1 0 1
`Cx,di
`Di,obuf[si]
`Al, [di]
`Ah,O
`Cx
`Cx,bufmsk
`Ofirst[si],cx
`
`Di
`Cx
`
`Near
`
`puts the char from AL into input ring buffer
`
`Figure 6-1. Continued.
`
`(more)
`
`194
`
`The MS-DOS Encyclopedia
`
`HUAWEI EX. 1010 - 204/1582
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`J{!
`I
`I):
`
`Part B: Programming for MS-DOS
`
`This common code preserves all other registers used (lines 309 through 318), sets DS
`equal to CS (lines 319 and 320), retrieves the command-packet pointer saved by the Strat-:
`egy routine (line 321), uses the pointer to get the command code (line 323), uses the code
`to calculate an offsetinto a table of addresses Clines 324 through 326), and performs an in(cid:173)
`dexed jump (lines 322 and 327) by way of the dispatch table (lines 256 through 284) to the
`routine that executes the requested command (at line 336, 360, 389, 404, 414, 421, 441, 453,
`500, or 829).
`
`Although the device-driver specifications for MS-DOS version 3.2list command request
`codes ranging from 0 to 24, not all are used. Earlier versions of MS-DOS permitted only 0
`to 12 (versions 2.x) or 0 to 16 (versions 3.0 and 3.1) codes. In this driver, all24 codes are
`accounted for; those not implemented in this driver return a DONE and NO ERROR status
`to the caller. Because the Request routine i.s called only by MS-DOS itself, there is no check
`for invalid codes. Actually, because the header attribute bits are not set to specify that
`codes 13 through 24 are valid, the 24 bytes occupied by their table entries (lines 273
`through 284) could be saved by omitting the entries. They are included only to show
`how nonexistent commands can be accommodated.
`
`Immediately following the dispatch indexed jump, at lines 329 through 353 within the
`same PROC declaration, is the common code used by all Request routines to store status
`information in the command packet, restore the registers, and return to the caller. The
`alternative entry points for BUSY status (line 332), NO ERROR status (line 338), or an error
`code (in the AX register at entry to Exit, line 339) not only save several bytes of redundant
`code but also improve readability of the code by providing unique single labels for BUSY,
`NO ERROR, and ERROR return conditions.
`
`All of the Request routines, except for the /nit code at line 829, immediately follow the
`dispatching shell in lines 358 through 568. Each is simplified to perform just one task, such
`as read data in or write data out. The Read routine (lines 360 through 385) is typical: First,
`the requested byte count and user's buffer address are obtained from the command
`packet. Next, the pointer to the command packet is saved with a PUSH instruction, so that
`the ES and BX registers can be used for a pointer to the port's input buffer.
`
`Before the Get_ in routine that actually accesses the input buffer is called, the input status
`byte is checked (line 368). If an error condition is flagged, lines 370 through 373 clear the
`status flag, flush the saved pointers from the stack, and jump to the error-return exit from
`the driver. If no error exists, line 375 calls Get_ in to access the input buffer and lines 376
`and 377 determine whether a byte was obtained. If a byte is found, it is stored in the user's
`buffer by line 378, and line 379 loops back to get another byte until the requested count
`has been obtained or until no more bytes are available. In practice, the count is an upper
`limit and the loop is normally broken when data runs our.
`
`No matter how it happens, control eventually reaches the Got_ all routine and lines 381
`and 382, where the saved pointers to the command packet are restored from the stack.
`Lines 383 and 384 adjust the count value in the packet to reflect the actual n.umber of bytes
`obtained. Finally, line 385 jumps to the normal, no-error exit from the driver.
`
`202
`
`The MS-DOS Encyclopedia
`
`HUAWEI EX. 1010 - 212/1582
`
`
`
`
`
`Part B: Programming for MS-DOS
`
`buffer to be sent on to any program, although all patterns other than XOFF and XON are
`passed through by the driver. When flow control is disabled, the driver passes all patterns
`in both directions. For binary file transfer, flow control must be disabled.
`
`The transmit action is simple: The code merely calls the Start_ output procedure at line
`750. Start_ output is described in detail below.
`
`The receive action is almost as simple as transmit, except for the flow-control testing. First,
`the ISR takes the received byte from the DART (lines 758 and 759) to avoid any chance of
`an overrun error. The ISR then tests the input specifier (at line 760) to determine whether
`flow control is in effect. If it is not,. processing jumps directly to line 784 to store the
`received byte in the input buffer with Put_ in (line 785).
`
`If flow control is active, however, the received byte is compared with the XOFF character
`(lines 762 through 765). If the byte matches, output is disabled and the byte is ignored. If
`the byte is not XOFF, it is compared with XON (lines 766 through 768). If it is not XON
`either, control jumps to line 784. If the byte is XON, output is re-enabled if it was disabled.
`Regardless, the XON byte itself is ignored.
`
`When control reaches Stuff_ in at line 784, Put_ in is called to store the received byte in
`the input buffer. If there is no room for it, a lost -databit is set in the input status flags (line
`788); otherwise, the receive routine is finished.
`
`If the interrupt was a line-status action, the LSR is read Clines 776 through 779). If the input
`specifier so directs, the content is converted to an IBM PC extended graphics character by
`setting bit 7 to 1 and the character is stored in the input buffer as if it were a received byte ..
`Otherwise, the Line Status interrupt merely sets the generic Badlnp error bit in the input
`status flags, which can be read with the IOCTL Read function of the driver.
`
`When all ISR action is complete, lines 794 through 806 restore machine conditions to those
`existing at the time of the interrupt and return to the interrupted procedure.
`
`The Start_output routine
`Start_ output (lines 808 through 824) is a routine that, like the four buffer procedures, is
`used by both the Request routines and the ISR. Its purpose is to initiate transmission of a
`byte, provided that output is not blocked by flow control, the DART Transmit Holding
`Register is empty, and a byte to be transmitted exists in the output ring buffer. This routine
`uses the Get_ out buffer routine to access the buffer and determine whether a byte is avail(cid:173)
`able. If all conditions are met, the byte is sent to the DART holding register by lines 819
`and820.
`
`The Initialization Request routine
`The Initialization Request routine Clines 829 through 897) is critical to successful operation
`of the driver. This routine is placed last in the package so that it can be discarded as soon ·
`as it has served its purpose by installing the driver. It is essential to clear each register of
`the 8250 by reading its contents before enabling the interrupts and to loop through this
`
`204
`
`The MS-DOS Encyclopedia
`
`HUAWEI EX. 1010 - 214/1582
`
`
`
`
`
`Part B: Programming for MS-DOS
`
`One way to overcome this difficulty is to purchase costly debugging tools. An easier
`way is to bypass the problem: Instead of using MS-DOS functions to track program opera(cid:173)
`tion, write data directly to video RAM, as in the macro DBG (lines 10 through 32 of
`COMDVR.ASM).
`
`This macro is invoked with a three-character parameter string at each point in the pro(cid:173)
`gram a progress report is desired. Each invocation has its own unique three-character
`string so that the sequence of actions can be read from the screen. When invoked, DBG
`expands into code that saves all registers and then writes the three-character string to
`video RAM. Only the top 10 lines of the screen (800 characters, or 1600 bytes) are used:
`The macro uses a single far pointer to the area and treats the video RAM like a ring buffer.
`
`The pointer, Dbgptr (line 215), is set up for use with the monochrome adapter and points
`to location BOOO:OOOOH; to use a CGA or EGA (in CGA mode), the location should be
`changed to B800:0000H.
`
`Most of the frequently used Request routines, such as Read and Write, have calls to DBG
`as their first lines (for example, lines 361 and 422). As shown, these calls are commented
`out, but for debugging, the source file should be edited so that all the calls and the macro
`itself are enabled.
`
`With DBG active, the top 10 lines of the display are overwritten with a continual sequence
`of reports, such as RR Tx, put directly into video RAM. Because MS-DOS functions are not
`used, rio interference with the driver itself can occur.
`
`Although this technique prevents normal use of the system during debugging, it greatly
`simplifies the problem of knowing what is happening in time-critical areas, such as hard(cid:173)
`ware interrupt service. In addition, all invocations of DBG in the critical areas are in con(cid:173)
`ditional code that is executed only when the driver is working as it should.
`
`Failure to display the pi message, for instance, indicates that the received-data hardware
`interrupt is not being serviced, and absence of go after an Ix report shows that data is not
`being sent out as it should.
`
`Of course, once debugging is complete, the calls to DBG should be deleted or commented
`out. Such calls are usually edited out of the source code before release. In this case, they
`remain to demonstrate the technique and, most particularly, to show placement of the calls
`to provide maximum information with minimal clutter on the screen.
`A simple modem engine
`The second part of this package is the modem engine itself (ENGINE.ASM), shown in the
`listing in Figure 6-3. The main loop of this program consists of only a dozen lines of code
`Clines 9 through 20). Of these, five (lines 9 through 13) are devoted to establishing initial
`contact between the program and the serial-port driver and two (lines 19 and 20) are for
`returning to command level at the program's end.
`
`Thus, only five lines of code (lines 14