Learn Microsoft Assembler in a Day

[ Pobierz całość w formacie PDF ]

DOS prompt by entering the SET command.
Example:
From a DOS command prompt, you enter the following line:
MODE CO80,43
DOS then tries to execute MODE.COM and passes the following ASCII data
string in the PSP data area at DS:81H (note that the first character will be a
space):
CO80,43
with the value 9 at 80H
DOS Calling
Most DOS calls are made through the INT 21H function calls. With a standard
DOS function call, you preset register AH with a DOS function code value and
the other registers with the necessary data for the called function. Then you
execute an INT 21H instruction to pass control of the CPU to DOS until it
finishes the task and returns to your program. In general, if it returns with the
carry bit set in the Flag register, then the function failed.
A main function of the DOS is to assist in handling files. When an application
program calls the DOS to open or create a file, the DOS returns a file handle to
the program. This is a 16-bit data word that the program needs to keep track
of. When the application tries to access an open file, DOS will require the file
handle to reference the correct file. The basic file functions are:
Create
On entry, AH=3CH, CX=file attributes, DS:DX index ASCIIZ string.
The file attribute information is defined as:
bit 0 - file is read only if set,
bit 1 - hidden file if set,
bit 2 - system file if set,
bit 3 - volume label entry if set, only valid in root directory,
bit 4 - subdirectory entry if set.
On exit, if no carry, then AX=file handle data else if carry, then there is
an error code in AX: 3 path not found, 4 too many files open, 5 access
denied.
Open
On entry, AH=3DH, AL=access code, DS:DX index ASCIIZ string. The
access code is defined as: 0 to open for reading, 1 to open for writing, 2
to open for both reading and writing.
On exit, if no carry then AX=file handle else if carry then there is an
error code in AX: 2 file not found, 4 there are too many files open, 5
access denied, 12 invalid access code.
Write
On entry, AH=40H, BX=file handle, CX=count of number of bytes to
write, DS:DX file buffer index.
On exit, if no carry then AX has count of writing else if carry then there
is an error code in AX: 5 invalid handle, 6 access denied.
Read
On entry, AH=3FH, BX=file handle, CX=count, DS:DX=file buffer
index.
On exit, if no carry then AX has count of number of bytes read else if
carry then there is an error code in AX: 5 invalid handle, 6 access
denied.
Close
On entry, AH=3EH, BX=file handle.
On exit, if no carry then function OK else if carry then there is an error
code in AX: 6 invalid handle.
Seek
On entry, AH=42H, AL=move type, BX=file handle, CX:DX=move
distance. Move type: 0 move from the start of the file, 1 move from the
current file position, 2 move from the end of file. Move type 2 can be
used to find the end of the file for appending data or to find the file size.
On exit, if no carry then DX:AX=new position else if carry then there is
an error code in AX: 1 invalid function, 6 invalid handle.
Table of Contents
Products | Contact Us | About Us | Privacy | Ad Info | Home
Use of this site is subject to certain Terms & Conditions, Copyright � 1996-2000 EarthWeb Inc.
All rights reserved. Reproduction whole or in part in any form or medium without express written permission of EarthWeb is
prohibited. Read EarthWeb's privacy statement.
To access the contents, click the chapter and section titles.
Learn Microsoft Assembler in a Day
(Publisher: Wordware Publishing, Inc.)
Author(s):
Go!
ISBN: 1556223315
Publication Date: 05/01/93
Keyword
Brief Full
Advanced
Search this book:
Search
Search Tips
Go!
Table of Contents
-----------
Appendix H
DEBUGGING A COMPUTER
PROGRAM
A good programmer should be able to find any software bug that exists in a
computer program without the aid of a debugging software tool by analyzing
the program listing. A good programmer will also note that a software
debugging tool can sometimes speed up finding the location of a problem.
When tracing down a bug, one of the primary objectives is to attempt to locate
the defective segment of code as quickly as possible. Many times, this can be
accomplished by just knowing what the user was doing with the program when
the problem occurred. For instance, was the user saving a file, loading a new
file, making changes to certain program features, etc.? Sometimes, this does
not work because a bug can be initiated by one code segment but is not visible
to the user until later on during program execution in another code segment. If
a good examination of the current code listings do not produce a solution, then
it may be time to use a software debugging tool.
One of the most common problems with Assembly language coding is
indexing the wrong data cell with a pointer and letting a pointer move out of
the defined data area for it. With the segment registers of the 80X86 language
adding to addressing complexities, it is very easy to find yourself pointing to
the wrong place.
The primary goal is to define and isolate the problem. Try searching the source
code for key areas and write special debug code at key points. This will
normally be just a message displayed to the standard output device that
identifies the code segment that is being debugged. Then recompile and link
the source with the debug code. Run the debug version and make note of the
debug statements executed before the error condition occurs. You may have to
repeat this process more than once to isolate and find a bad code segment, but
you can usually narrow the search for a bad code segment very quickly with
this method. The drawback with this method is that the code may have to be
recompiled many times to find the problem. Sometimes, recompiling is very
difficult and may take hours. If this is the case, then another method may be
more useful.
There is a generalized logical approach to debugging almost any code. This
simple method can be used to debug programs when you do not have access to
the source code or can be used very efficiently with the source code. In almost
all cases, a computer program will have subroutine calls of some kind or
another. For this discussion, consider each subroutine call to be nested under
the layer of the code that calls it. The concept and study of these layers can be
a useful tool in debugging unknown code. In most systems, you can execute a
debugger and have it load and make a program ready for execution. You
should be able to single step through the program and take note of all the
computer instructions executed. In this layered approach, you follow the top
level of code until the error condition is noted.
To follow the top level, simply single step through the code and test for the
error condition after each instruction at the current layer. While single stepping
through the code, each time a subroutine is called, skip over the instruction
that calls or invokes the subroutine, but make a note that the last instruction
was a subroutine call and note the location of it. This means that you should
not single step into the subroutine code but have the debugger execute it and
return to the single step state when the subroutine is finished. At some point in
the debugging process, the error condition will be noted. If the error condition
is noted after a standard instruction, then the last instruction caused the error
condition and should be studied for a possible correction. If the last instruction
was a subroutine call, then it is very likely that the subroutine was responsible
for the error condition and should be investigated. Execute the program again
up to the point where the subroutine procedure was called that caused the error
condition to be noted. Then, single step into the subroutine and start searching [ Pobierz całość w formacie PDF ]

Tematy