|
|
THE ASSEMBLY LANGUAGE "MAGAZINE" VOL 1 NUMBER 4 December 1989
go to English version
translate
THE ASSEMBLY LANGUAGE "MAGAZINE" VOL 1 NUMBER 4
December 1989
## #### #### ####### ## ## ###### #### ## ##
#### ## ## ## ## ## # ### ### ## ## ## ## ##
#### ## ## ## #### ## ## ## #### #######
## #### ### ## ## ## ## ## #### ## ## ## #
## ## ## #### ## ## ## ## ## ## ## ## #
## ## ## ## #### ## ## ## ## ## ## ####
## # ###### ## ### ## ### ## ## ###### ## ### ## #
## ## ## ## ## ## ## ## ## ## ## ## ## ## ## #
####### ## ## ## ## ##### ###### ## ## ##### #######
Written by and for assembly language programmers.
Table of Contents
Editorial.......................................2
Policy and Guide Lines..........................3
Beginners' Corner...............................5
Structure, Speed and Size
By Thomas J. Keller........................7
Editorial Rebuttal........................11
Accessing the Command Line Arguments
By Thomas J. Keller.......................13
Original Vector Locator
by Rick Engle.............................15
How to call DOS from within a TSR
by David O'Riva...........................22
Environment Variable Processor
by David O'Riva...........................26
Program Reviews................................35
Multi-Edit ver 4.00a .....................35
SHEZ......................................36
4DOS......................................36
Book Reviews...................................37
Assembly Language Quick Reference
Reviewed by George A. Stanislav......37
GPFILT.ASM.....................................39
;Page 1
Editorial
It has been much too long since the last issue of the Magazine was
published. Much of this time was due to the lack of submissions but
there has been enough to assemble since early November. I hope that
it will not be as long till the next one is ready for distribution.
You can help make that possible by writing up and sending in an
article.
I'm trying out a new editor for this issue. That makes it four
editors for 4 issues. There is a review of it in the review section.
There is a continueing and probably insoluable problem in
formatting the 'Magazine'. The readability of the text portions is
enhanced with wider margins and is more easily bound with a wide
left margin. The difficulty arises when source code is included. 80
columns is little enough in which to fit the code and comments,
allowing nothing for margins. So this time we'll try a 5 space
margin on the left for the text portion. Further offset should
be done with your printer.
A couple of quick notes here as I don't know where else to put
them.
For the assembly programmer the principle difference in writing
for DOS4+ is that there is a possible disk structure using 32 bit
FAT entries. This of course has no effect as long as you use only
the DOS calls for disk access, but if you are going to do direct
disk editing this must be checked for.
The occasional ~ is for the use of my spelling checker.
;Page 2
Policy and Guide Lines
The Assembly Language 'Magazine' is edited by Patrick and David
O'Riva. We also operate the AsmLang and CFS BBS to distribute the
'Magazine' and to make available as much information as possible to
the assembly language programmer. On FidoNet the address is
1:143/37. Address:
2726 Hostetter Rd
San Jose, CA 95132
408-259-2223
Most Shareware mentioned is available on the AsmLang board if local
sources cannot be found
Name and address must be included with all articles and files.
Executable file size and percent of assembly code (when available)
should be included when a program is mentioned and is required from
an author or publisher. Any article of interest to Assembly
language programmers will be considered for inclusion. Quality of
writing will not be a factor, but I reserve the right to try and
correct spelling errors and minor mistakes in grammar, and to remove
sections.
Non-exclusive copyright must be given. No monetary
compensation will be made.
Outlines of projects that might be undertaken jointly are
welcome. For example: One person who is capable with hardware
needs support from a user friendly programmer and a math whiz.
Advertisements as such are not acceptable. Authors and
publishers wishing to contribute reviews of their own products will
be considered and included as space and time permit. These must
include executable file size, percent of assembly code and time
comparisons.
Your editor would like information on math libraries, and
reviews of such.
Articles must be submitted in pclone readable format or sent
E-mail.
Money: Your editor has none. Therefore no compensation can be
made for articles included. Subscription fees obviously don't
exist. Publication costs I expect to be nil (NUL). Small
contributions will be accepted to support the BBS where back issues
are available as well as files and programs mentioned in articles(if
PD or Shareware ONLY).
Shareware-- Many of the programs mentioned in the "Magazine"
are Shareware. Most of the readers are prospective authors of
programs that can be successfully marketed as Shareware. If you
make significant use of these programs the author is entitled to his
registration fee or donation. Please help Shareware to continue to
;Page 3
be a viable marketing method for all of us by urging everyone to
register and by helping to distribute quality programs.
;Page 4
Beginners' Corner
I finished up the last column by saying I would discuss more
techniques this time. I have entirely forgotten what they were. So
without dwelling on that we will just move on the means of getting
your program ready to run. The two formats (.com and .exe) are very
different and so will be discussed separately.
COM Programs
On Entry all of your segment registers are set to the same
value, that of the start of the PSP. Your stack pointer is set to
the top of the segment, and your instruction pointer is set to 100h.
You need to make a generous estimate of the maximum amount of stack
that your program can use (or count it exactly) Each level of Call
uses 2 bytes (for the address of the next instruction). An INT uses
6 bytes. (2 for the IP, 2 for the CS, and 2 for the Flags). Each push
of course uses 2. So if your subroutines can go 4 levels deep and
contain 7 pushes (without intervening pops) and the deepest contains
an INT21h, then you would need at least 28 bytes of stack. But
stack space is cheap, and you might need to change things. So use a
nice round number of 128 bytes. BIOS also uses YOUR stack in the
earlier versions of DOS, and the guideline for that is at least 128
bytes. Result: 256 bytes is safe for a modest program. To implement
this the following lines of code could be used at the start of the
program: ~
org 100h
jmp main
defstack db 32 dup('stack ')
stacktop label byte
;other data
main:
cli
mov sp,offset stacktop
sti
~
The db statement is 32 times the string of 8 characters
totaling 256 bytes. It could just all well be db 256, but it is
kind of nice when looking at it with a debugger to see the stack
area and how much has been used all nicely labeled. The cli and
sti aren't really necessary here because it is only one instruction,
but you are dealing with the stack, and it's well to remember that.
At the end of your program you need a label e.g.
~
progend label byte
Then following your stack adjustment above:
mov bx,offset progend
mov cl,4
shr bx,cl
inc bx
~
;Page 5
These instructions change the offset value into a number of
paragraphs (16 bytes) and to the end of the last paragraph. This is
the total number of paragraphs that will be occupied by your
program. Then it is necessary to inform DOS of this information:
~
mov ah,4ah
int 21h
~
4a is the DOS function to modify allocated memory. It needs the
new number of paragraphs in BX (which is where it was put)
At this point, your program is in an orderly condition. Your
data as well as that in the PSP is available with the DS and ES
registers, The stack is large enough and well mannered, and all
surplus memory is available to you or other programs.
;Page 6
Structure, Speed and Size
as
Elements of Programming Style
By Thomas J. Keller
P.O. Box 14069
Santa Rosa, CA, 95402
Let us examine the reasons for choosing to implement a given
program in assembly language as opposed to some high level language.
The reasons most commonly given are execution speed and memory image
size.
Execution speed, except in certain highly critical realtime
applications, or certain high resolution graphics applications, is
probably not a realistic reason to opt for assembly language. For
example, a good C compiler with optimization (which precludes use of
Turbo or Quick C) produces code which only suffers a 10-15% speed
penalty, over typical hand crafted assembly language code. It is
possible to write assembly language code which will run faster than
this, but few programmers have the requisite skills.
In most applications, a 10-15% speed penalty is simply
irrelevant. It is unlikely that the typical user would even notice
such a difference. In particular, programs which are highly
interactive, and thus spend far and away the greatest amount of time
waiting for user input are highly insensitive to such speed
penalties. Many people don't realize that even assuming that the
user is typing at a rate of 100 wpm (approximately 500
keystrokes/minute), the CPU is still spending the bulk of its time
idling, waiting for the next keystroke.
There are, of course, always exceptions to virtually any rule,
and there are most certainly exceptions to this rule. Word
processors, for example, while actually accepting text input, are
not speed critical. When performing global search and replace, or
spell checking, for example, even a 10% penalty can become expensive
on large documents. So there is a tradeoff to be made.
Assembly language programs cost considerably more than 10-15%
more to develop than high level programs. The minutiae involved in
managing a massive assembly language programming effort are
overwhelming. Assembly language programs take MUCH longer to
complete, in almost all cases, than high level programs do, a major
contributory factor in the overall cost of development. Finally,
projects developed in high level programming languages are much more
likely to be easily ported to platforms based on processors other
than the platform on which the project is developed, and very
important consideration for a major project. The ability to port a
project easily to other platforms increases the market for a
product, thereby not only increasing the profitability of the
product, but also helping to reduce the sale price of the product
(larger market generally translates to lower per unit cost).
;Page 7
So the vendor or developer must analyze the relative impact of a
small improvement in execution speed vs a large increase in
development time and cost, which consequently translates to higher
selling prices, thereby reducing the anticipated market for their
product. In many cases, the tradeoffs do not merit choosing
assembly language.
Let us turn now to binary image size (memory size). The
advantages of small programs are clear, when examining programs
which are, in the DOS world, TSRs (The MAC and AMIGA worlds have
similar cases, though I am not sufficiently familiar with them to
know what they are called). These programs are loaded into memory,
and remain there until explicitly removed, which means that the
memory they use is NOT available for other uses. Device drivers
similarly use memory, precluding its use for other programs, and
therefore also clearly benefit from small size. In the
multi-tasking world (DeskView or PC/MOS, in the PC clone market),
small executables also have an advantage, permitting more programs
to be run "simultaneously" in a given memory configuration, though
running multi-taskers in severely restricted memory configurations
probably qualifies as a technical error.
What of normal, single tasking, single user environments (such as
DOS, the MAC and AMIGA environments)? Besides the ego boost of
creating a very small, very tight utility or application, what benefit
is there in generating very small programs?
They take less disk space to store, but realistically, at least
under DOS, lots of very small utilities may actually not achieve a
significant savings in disk space, due to granularity of storage
allocation. They load a little faster, in most cases.
But once again, the economics of the issue comes back to haunt us.
It is not clear that the effort and expense of writing most
applications in assembly language due to size considerations is an
economically rational decision. The same economic pressures and
considerations apply as do to the execution speed issue discussed
above.
On to structure. I must take issue with Patrick O'Riva regarding
their purpose and nature of "structured programming." While much of
his definition is true, it is incomplete, and appears to reflect a
misunderstanding of certain aspects of the structured approach to
programming.
Firstly, it is entirely possible (and not altogether a rare
occurrence) to write thoroughly unstructured code in PASCAL or C. One
must take care to recognize the difference between references to a
"block structured" language, as PASCAL and C both are, and "structured
programming," which is really a totally separate issue.
Structured programming is an approach to programming that is
thoroughly applicable to whatever language a project is being
implemented in. It implies firstly a step-wise refinement approach
to defining the solution to a problem which the program is to address
(in other words, determining the nature of the desired goal, and an
at least rational approach to reaching said goal). Secondly, it
;Page 8
involves determining, to the extent possible, the nature and structure
of the data that is to be processed by the program. Finally, it
involves a top-down approach to the actual coding process.
Just what is a top-down approach? Essentially, this means that we
code the high level functionality of the program first, programming
simple "do nothing" stubs for the lower levels of the program. As
necessary to test the high level code, we implement lower level
functions, again, if needed, programming still lower level stubs.
Assuming that the structured design approach of step-wise refinement
was used to begin with, the actual coding should really amount to
translating the logic flow diagrams, or pseudo-code, or whatever means
of recording the refinement process was used, into actual program
code. In the ideal situation, the program almost literally codes
itself at this point.
There is a myth that "structured programming" means "goto-less"
programming. In fact, this is not the case. This myth came into
being through misunderstanding of the rather harsh criticism of the
"go to" which occurred in the computer science journals beginning in
approximate the mid to late sixties. This criticism was based
primarily upon the typically excessive use of the "go to" in FORTRAN
and BASIC programming at the time. Such indiscriminate use of "goto"
led to what has been called "spaghetti" code, code which is virtually
impossible to trace or analyze.
In fact, there are many cases in programming where the goto is most
structured solution available. Structured coding techniques are
intended to clarify and make easier the process of analysis, design
and implementation of computer programs, not to define rigid, strictly
enforced rules in the face of all reason.
Structured programming is ALWAYS the best approach to ANY computer
program. If the internal requirements of the program, as regards
speed or memory utilization, dictate the use of goto's, then use them.
A properly documented GOTO can be far more "structured" than an
undocumented string of modular function calls.
So, back to assembly language programming. When is it appropriate
to choose assembly language to implement a program? First, and most
obviously, when the speed or memory utilization requirements of the
application demand the capabilities that well crafted assembly
language offers. Second, perhaps not so obviously, when it is
necessary to work at the hardware level a great deal. High level
languages, even C, do not generally manipulate hardware registers
efficiently. So, if your program makes frequent or widespread use of
direct hardware manipulation, it is a likely candidate for assembly
language.
Finally, and probably the most gratifying reason of all to choose
assembly language, is when you want the satisfaction of having tackled
a project in assembly and pushed the bits around to suit your purpose.
There is little I can imagine that is more satisfying than to reach
down into the microprocessor chip and twiddle those bits. Just be
sure that you don't let your ego cloud your judgment, when the
economics of the project are important (e.g., when a project is to be
distributed commercially, or there is an urgent need for speedy
;Page 9
completion).
I believe that all PROGRAMMERS (as opposed to casual computer
users) should learn the assembly language for the machines on which
they work. Besides offering the flexibility of shifting to assembly
to meet a specific goal, learning assembly intimately familiarizes the
programmer with the hardware on which s/he is working. The more you
know about your hardware environment, the better off you are.
;Page 10
Editorial Rebuttal
I thank Mr. Keller very much for his article and agree with
many of the points he has made. However I must still argue the
points of size and speed and justification.
Whenever a program is user limited and will not be used in a
multi-tasking environment as is often the case with a word processor
and certain drawing programs, there may be little to be gained in
assembly programming. Also there are programs which are DOS limited
and little speed increase is possible.
Mr. Keller uses a figure of 10 to 15 percent speed penalty. My
experience indicates a value closer to 300 to 400 percent though
direct comparisons are difficult to make because the same programs
are usually not written in both assembly and in C. The size
difference seems to be a factor of 5 to 10. The two prime examples
I can offer are both by Microsoft, and it can be assumed they make
use of an optimizing compiler. Their assembler is approximately 110k
in size. A86 while not compatible in syntax has comparable features.
It's size is 22k and assembles code in about one eighth the time.
Microsoft's programmers' editor is vaguely 250k. Qedit is
about 50k and is a mix of high level and assembly. You can grow gray
hairs waiting for the MS editor to do a search and replace, but if
you blink you'll miss it with Qedit. A fully capable full screen
editor without the extras that make it a pleasure to use can easily
be written in less that 5k. Give another 5k for features. What has
MS gained with the extra 240k of code?
David has recently completed (though they are still adding
modules) a database and accounting program for a multi-office
company. A much abbreviated version was threatening to overflow their
384k limit. Investigation of a Dbase implementation indicated in
excess of 500k. Data base sorts used to take 10 hours. They now take
20 minutes. Savings in processing time and entry time plus increased
functionality suggest a savings of $5000 to $10,000 per month PER
OFFICE. Code size? 35k. Are they unhappy about the $15,000 they've
been charged for a program that will get lost in a single floppy
disk?
Given the above examples, I must maintain that the use of high
level language, when there is significant processing to be done, and
when it will be used on a regular and continuing basis, benefits
only the software corporation, and is detrimental to the end user.
On Structured Programming I fully agree with Mr. Keller and
hope that he clarified any misconceptions I left you with. I prefer
a bottom up construction, but that is only preference and has no
effect on the end product.
Dave's notes: Mr. Keller mentions that it is possible to get
great size/speed reductions, but that few programmers have the requisite
skills. But to a large extent, it isn't the skill that makes the
program, it's the toolbox. The C language is extremely close to
assembly - MSC does a very good job of optimizing - and it takes care of
the minutiae for you. The problem with this is that the libraries
;Page 11
supplied with the compilers were written to handle very general cases.
The printf() function is an extreme example, but it typifies the
problem: If you use printf once in your program to print "Hello", it
adds 30K of code!
Another concern is that many high-level-language programmers
don't even realize that with a tweak here, using putc instead
of printf there, they can get much(!) better performance from their
programs. Familiarity with the quirks of the compiler being used is a
necessity... And even that isn't enough to get good performance out of a
large program. AND, it decreases portability. So you're right back
into the twiddling usually associated only with assembly.
I've found that if I use C for anything except flow control and
one-shot tools, my programs start to get huge and slow, relative to
anything that I've banged out in assembly. The database is a great
example - it's a very complicated application, with a completely
separated data engine & OS interface. If it had been written in C, it
would be working in multiple code segments on a 286 with 4 megs and
STILL take hours to run a balance, instead of 35K of code on an XT
network terminal with half-hour runs.
The database was indeed a massive effort, but at this point it
would be possible to strip out the engine and write with ease (and
macros - lots of macros) anything that could be done in C or Dbase, and
do it much better. And average runtime is cut at least in half, size by
50-90%. With a reasonably solid and application-specific toolbox, the
advantages TO THE CUSTOMER of assembly programming completely eclipse
those of any other language and the disadvantages of assembly itself.
Portability is another issue entirely. If you NEED
portability and fast development, and IF run time and general
productivity are not a concern, then C probably makes more sense.
There's this nagging feeling, though, that if the UNIX OS core had been
written in assembly by a reasonably good programmer, and been ported to
new systems in kind, that the university systems would be clipping
instead of slogging.
As far as structured programming goes, I usually design as I go
along, and end up with a functional (even rational) structure. Call it
"random-access programming." This is probably because I find it
difficult to call a routine until I've laid out the calling conventions
for it, and while I'm doing that I'll remember another routine that
should be written for another module... This is not the generally
recommended method, I gather.
;Page 12
Accessing the Command Line Arguments
in Assembly Language Programs
By Thomas J. Keller
P.O. Box 14069
Santa Rosa, CA, 95402
If you're like me, you program in several languages, under
several different operating systems. Under DOS, one very useful
feature is the capability to pass arguments to a program as part of
the invocation command line. The use of command line arguments
significantly increases the power and flexibility of your programs,
as well as improving the "professional look." Many languages
support this capability with intrinsic or library routines which
facilitate access to these command line arguments. Assembly
language, of course, does not. What is a programmer to do?
As it turns out, it is quite simple to access the command line
arguments under DOS. DOS places the so-called "command tail" (the
command line less the actual program name) into a buffer area
reserved in the PSP (Program Segment Prefix). This buffer area is
known as the DTA (Disk Transfer Area).
It is extremely important that you parse the command tail, if you
plan to do so at all, immediately upon entering your program. DOS
does some particularly obscure and insidious things with this DTA
buffer, which will destroy the command tail information.
In a .COM format program, the PSP is the first 100h (256) bytes
of the program memory image, making access quite straightforward.
How do we locate the PSP in a .EXE format program, however?
Fortunately, DOS sets the ES segment register to point to the
beginning of the PSP under both .COM and .EXE programs. It happens
to be the case that DOS also sets all other segment registers to the
same location for a .COM program, simply because .COM programs
reside in one and only one segment. In an .EXE invocation, the DS
and ES registers are set to point to the segment in which the PSP
resides as the first 100h bytes. This is the default data segment
as well.
The DTA begins at offset 80h (128d) from the beginning of the
PSP. When it contains a command tail, the byte at 80h contains the
count of the number of bytes actually in the command tail, and the
command tail string begins at offset 81h (129d) from the beginning
of the PSP. The first byte of this string is always a blank (20h),
and the string is terminated with a (0dh).
The exact means you use to parse the command line arguments is,
of course, up to you. One possible approach is as follows:
1) Use the data definition directives to set aside any memory you
will need to store information about command line arguments
(e.g., buffers for file names, byte or word values for flags and
numeric arguments, etc.).
2) Design a routine that starts scanning the command tail string for
;Page 13
arguments. a 'first fit' (the shortest match possible) scheme is
easiest to program. As each item is located and identified as to
type and purpose, store the appropriate information in the data
areas you have already set aside.
3) Have a "usage" message defined, and a small routine to print it
to the screen (a good idea is to print it to STDERR). Invoke
this routine when the first argument on the command line is a
'?,' or, if the program requires arguments, when it is invoked
without them.
4) You now have the switches, filenames, and other command line
arguments available. Write your program to use them
appropriately.
Included in this issue of Assembly Language Magazine is an source
listing which is a sample template GPFILT.ASM for a general purpose
assembly language filter. This program provides an excellent sample
of command line argument parsing and one way of using these
arguments (though the method used here is not the same as the one
described above).
;Page 14
Original Vector Locator
by Rick Engle
November, 1989
INTTEST is a small assembly program which attempts to find the
original address of the INT 21h function handler. This is valuable
if you need to be able to make calls to the original INT 21h
function even if a TSR or other program has that interrupt hooked or
trapped. This gives your program secure control over the interrupt
regardless of who is using it.
I did this prototype in an attempt to make certain programs
somewhat immune to the effects of destructive viruses that may
intercept INT 21h and use it for their own use. This technique
could be used to find the original address of other MS-DOS
interrupts. I wrote test programs to dump out the address of MS-DOS
interrupts (such as INT 21h) and then disassembled portions of
MS-DOS at those addresses to identify a stable signature of the
interrupt. Then by following the chain to MS-DOS through the PSP
(Program Segment Prefix) at offset 5h, I was able to find the
segment:offset of the address of the handler for old CP/M calls.
This pointed to the correct segment in memory of MS-DOS and
from there, after moving my offset backwards about 100h in memory, I
scanned for my interrupt signature. Once I got a hit, I calculated
the address of the interrupt and then could make calls to INT 21h at
the segment:offset found. This program is a "brute-force" method of
finding the original address. If anyone finds or has a better way,
I'd be very interested in hearing about it.
NOTE: I have tested this program successfully on MS-DOS
2.11, 3.20, and 3.30.
~
; -----------------------------------------------------------------------
; INTTEST.ASM November, 1989 Rick Engle
;
; Finds the address of the INT 21h function dispatcher to
; allow the user to make INT 21h calls to the original
; interrupt regardless of who or what has INT 21h hooked.
;
; -----------------------------------------------------------------------
;
print macro print_parm
push ax
push dx
mov ah,9
mov dx,offset print_parm
int 21h
pop dx
pop ax
endm
; -----------------------------------------------------------------------
; - Start of program -
; -----------------------------------------------------------------------
;Page 15
cseg segment para public 'code'
assume cs:cseg,ds:cseg
org 100h
int_test proc far
print reboot_first
print int_address
mov cl,21h
mov ah,35h ; get interupt vector
mov al,cl ; for interupt in cl
int 21h ; do it
mov ax,es ; lets display the es
push cs ; set es = cs so that
pop es ; the stosb works
mov di,offset out_byte
call conv_word
print out_byte
print colon
mov ax,bx ; lets display the bx
mov di,offset out_byte
call conv_word
print out_byte
print crlf
print display_header2
mov ah,byte ptr cs:[05h] ; Get info from the PSP
mov al,byte ptr cs:[06h] ;
push cs ; set es = cs so that
pop es ; the stosb works
mov di,offset out_byte
call conv_word
print out_byte
print dash
mov ah,byte ptr cs:[07h] ;
mov al,byte ptr cs:[08h] ;
mov di,offset out_byte
call conv_word
print out_byte
print dash
mov ah,byte ptr cs:[09h] ;
mov al,byte ptr cs:[0ah] ;
mov di,offset out_byte
call conv_word
print out_byte
print crlf
print display_header
mov ah,byte ptr cs:[50h] ; Addess if INT 21 op code
mov al,byte ptr cs:[51h] ; in the PSP
;Page 16
push cs ; set es = cs so that
pop es ; the stosb works
mov di,offset out_byte
call conv_word
print out_byte
print dash
mov ah,byte ptr cs:[52h] ;
mov al,byte ptr cs:[53h] ;
mov di,offset out_byte
call conv_word
print out_byte
print dash
mov ah,byte ptr cs:[54h] ;
mov al,byte ptr cs:[55h] ;
mov di,offset out_byte
call conv_word
print out_byte
print crlf
print far_address
mov ax,word ptr cs:[08h] ;
mov segm,ax
push cs ; set es = cs
pop es ;
mov di,offset out_byte
call conv_word
print out_byte
print colon
mov ax,word ptr cs:[06h] ;
mov off,ax
push cs ; set es = cs so that
pop es ; the stosb works
mov di,offset out_byte
call conv_word
print out_byte
print crlf
mov ax,segm
mov es,ax
mov di,off
inc di
print function_jmp
mov ax,word ptr es:[di+2] ;
mov segm2,ax
push cs ; set es = cs so that
pop es ; the stosb works
mov di,offset out_byte
call conv_word
print out_byte
print colon
mov ax,segm
mov es,ax
mov di,off
;Page 17
inc di
mov ax,word ptr es:[di] ;
mov off,ax ; save found offset of int 21h
push cs ; set es = cs so that
pop es ; the stosb works
mov di,offset out_byte
call conv_word
print out_byte
print crlf
;-----------------------------------------------------------------
;si = string di = string size es:bx = pointer to buffer to search
;ax = number of bytes in buffer to search. Zero flag set if found
;-----------------------------------------------------------------
mov ax,segm2
mov es,ax ;segment
mov bx,off ;offset
sub bx,0100h ;backup a bit to catch DOS
mov si,offset dos_sig ;start at modified byte
mov di,dos_sig_len ;enough of a match
mov ax,0300h ;# of bytes to search
call search ;use our search
jnz sig_not_found ;didn't find int 21h signature
mov START_SEGMENT,es ;set page
mov START_OFFSET,ax ;address of found string
print good_address
mov ax,START_SEGMENT ;
push cs ; set es = cs so that
pop es ; the stosb works
mov di,offset out_byte
call conv_word
print out_byte
print colon
mov ax,START_OFFSET ;
mov off,ax ; save found offset of int 21h
push cs ; set es = cs so that
pop es ; the stosb works
mov di,offset out_byte
call conv_word
print out_byte
print crlf
push cs ; set es = cs
pop es
mov bx,START_OFFSET
mov ax,START_SEGMENT
mov word ptr [OLDINT21], bx
mov word ptr [OLDINT21+2],ax
mov dx,offset test_message
mov ah,9
call dos_function
jmp terminate
sig_not_found:
;Page 18
print no_int21_found
terminate: mov ax,4c00h ; terminate process
int 21h ; and return to DOS
out_byte db 'XXXX'
db '$'
colon db ':$'
dash db '-$'
crlf db 10,13,'$'
reboot_first db 13,10,'INTTEST 1.0',13,10
db 'Reboot before running this, or',13,10
db 'make sure INT 21h is not hooked',13,10,13,10,'$'
display_header db 'HEX data at PSP address 50h is : $'
display_header2 db 'HEX data at PSP address 05h is : $'
int_address db 'Original INT 21h address is : $'
function_jmp db 'Jump address at DOS dispatcher : $'
far_address db 'Far address of DOS dispatcher : $'
good_address db 'Good INT 21h address found at : $'
test_message db 13,10,10,'This message is being printed using the INT '
db '21h Interrupt',13,10
db 'Found by Brute Force!!!!',13,10,10,'$'
no_int21_found db 13,10,'Int 21h address not found!$'
segm dw 0
segm2 dw 0
off dw 0
START_OFFSET dw 0 ;top addr shown on screen
START_SEGMENT dw 0
;dos_sig db 08Ah, 0E1h, 0EBh ; mov ah,cl
; ; jmp short label
dos_sig db 080h, 0FCh, 0F8h ; cmp ah,0F8h
dos_sig_len equ $ - dos_sig
OLDINT21 dd ? ; Old DOS function interrupt vector
int_test endp
; -----------------------------------------------------------------------
; - -
; - Subroutine to convert a word or byte to hex ASCII -
; - -
; - call with AX = binary value -
; - DI = address to store string -
; - -
; -----------------------------------------------------------------------
conv_word proc near
push ax
mov al,ah
call conv_byte ; convert upper byte
pop ax
call conv_byte ; convert lower byte
ret ; and return
conv_word endp
conv_byte proc near
push cx ; save cx
;Page 19
sub ah,ah ; clear upper byte
mov cl,16
div cl ; divide binary data by 16
call conv_ascii ; the quotient becomes the
stosb ; ASCII character
mov al,ah
call conv_ascii ; the remainder becomes the
stosb ; second ASCII character
pop cx ; restore cx
ret
conv_byte endp
conv_ascii proc near ; convert value 0-0Fh in al
add al,'0' ; into a "hex ascii" character
cmp al,'9'
jle conv_ascii_2 ; jump if in range 0-9
add al,'A'-'9'-1 ; offset it to range A-F
conv_ascii_2: ret ; return ASCII character in al
conv_ascii endp
;-----------------------------------------------------------------------
; This routine does a dos function by calling the old interrupt vector
;-----------------------------------------------------------------------
assume ds:nothing, es:nothing
dos_function proc
; mov cl,ah ;move our function # into cl
pushf ;These instructions simulate
;an interrupt
cli ;turn off interrupts
call CS:OLDINT21 ;Do the DOS function
sti ;enable interrupts
push cs
pop ds
push cs
pop es
ret
dos_function endp
;-----------------------------------------------------------------
;si = string di = string size es:bx = pointer to buffer to search
;ax = number of bytes in buffer to search. Zero flag set if found
;-----------------------------------------------------------------
SEARCH PROC NEAR ;si points at string
PUSH BX
PUSH DI
PUSH SI
XCHG BX,DI ;string size, ptr to data area
MOV CX,AX ;# chars in segment to search
BYTE_ADD:
LODSB ;char for first part of search
NEXT_SRCH:
REPNZ SCASB ;is first char in string in buffer
JNZ NOT_FOUND ;if not, no match
PUSH DI ;save against cmpsb
;Page 20
PUSH SI
PUSH CX
LEA CX,[BX-1] ;# chars in string - 1
JCXZ ONE_CHAR ;if one char search, we have found it
REP CMPSB ;otherwise compare rest of string
ONE_CHAR:
POP CX ;restore for next cmpsb
POP SI
POP DI
JNZ NEXT_SRCH ;if zr = 0 then string not found
NOT_FOUND:
LEA AX,[DI-1] ;ptr to last first character found
POP SI
POP DI
POP BX
RET ;that's all
SEARCH ENDP
cseg ends
end int_test
;Page 21
~
How to call DOS from within a TSR
by David O'Riva
Just a few ramblings on interactions between TSRs & DOS.
Cardinal rule: DON'T CALL DOS UNLESS YOU'RE SURE OF THE
MACHINE STATE!!!
There are a few interrupt calls and memory locations you can
play with to get this information. A list & explanation of sorts is
below. The reason you don't call DOS if you've interrupted the
machine in the middle of DOS is that:
1. The stack is unstable as far as DOS is concerned, and
you'll probably end up overwriting DOS data or going
into the weeds.
2. DOS only keeps one copy of certain crucial information
as it processes a disk-related request. i.e. BPB's,
current sectors, FAT memory images, fun stuff like that.
If you interrupt it in the middle, ask for something
different, then go back, you will probably destroy your
disk, possibly beyond recall.
3. DOS simply was not designed to be re-entrant. The first
9 or 10 function calls are cool most of the time, the
rest are strictly single-processing-stream functions.
However, there is hope. And, (extra bonus) it happens to be
compatible with most true MS-DOS releases, and many, many brand-name
DOSes. As well as most clones.
What you need to do is after determining that the user wants to
pop your program up, you set a few flags. One of them prevents your
program from being popped up AGAIN while the current DOS call is
completing, and the other tells a timer trap routine to start
looking for DOS to finish it's current process (usually a matter of
split seconds). When the timer routine detects that DOS is no
longer active, it grabs control of the system and runs your TSR.
At this point, all DOS calls are as safe as they are for a
normal application.
What follows is an outline of the code necessary to activate a
TSR that uses DOS calls. Depending on the TSR, other things may
need to be done in these routines as well. Definitely make sure you
understand the interactions of the various routines before TSRing
your background disk formatter.
Okay, nitty-gritty time...
;Page 22
You need 5 main chunks of code to do this right:
a) a bit of extra initialization code
b) your TSR's main program
c) activation request server (usually a keypress
trap)
d) timer tick inDOS monitor
e) DOS busy loop monitor
And here's what they do:
a) asks DOS for the location of the inDOS flag, and stores
that away.
b) does whatever you want it to.
c) when the activation requirement is sensed (the user
pressed the hot-key, the print buffer is empty, the modem
is sending another packet, whatever) the following steps
need to be taken: 1. have we already tried to activate,
and are waiting for DOS to finish? if so, then
ignore the activation request.
2. check the inDOS flag. if we're not in DOS, then
activate as usual.
3. set a flag indicating that the TSR wants to
activate, but can't right now
4. return to DOS
d) this is linked in AFTER interrupt 08 - that is, when this
interrupt happens, call the original INT 08 handler, then
run your checking code:
1. does the TSR want to run? if not, return from the
interrupt.
2. check the inDOS flag. If it's out of DOS, then
run your code as normal
3. return from the interrupt
* * NOTE: This code has to run FAST. If it's poorly coded,
you may very well see downgraded performance of the
entire system.
e) link in to the DOS keyboard busy loop - INT 28. This
interrupt is called when DOS is waiting for a
keystroke via functions 1,3,7,8,0A, and 0C. If the TSR
takes control from this loop, then DOS functions ABOVE 0C
are safe to use. Functions 0 - 0C are NOT safe to use.
;Page 23
1. Does the TSR want to run? if not, continue down
the interrupt chain.
2. run the TSR as usual
3. continue down the interrupt chain.
NOTES: The first action your main TSR code should take is to
clear the flag that indicates the TSR is trying to run. If
this is not done, your TSR will re-enter itself at least
18.2 times per second... i.e. a MESS.
The last action your main TSR code should take before
leaving is to RESET the flags that prevent the TSR from
being activated. If you forget to do this, your TSR will
run once, then never again... I know from personal
experience that this is frustrating to a dangerous degree.
Some of this code is really complicated, so don't get
discouraged if it takes a few days of tweaking and
hair-pulling to get it right.
All numbers in this text are in hex.
The timer tick routine is really touchy, at least the way I
wrote it. Be very sure yours is reliable if you distribute
a program with this structure.
The reason that functions 0-0C are separated from the rest
of the DOS calls as far as re-entrancy is concerned is that
they use an entirely separate stack frame. I believe this
must have been done specifically for the purpose of helping
TSR writers.
Does anyone know why the hell Microsoft built these neat
functions into DOS and then refused to acknowledge their
existence?
INTERRUPT & FUNCTION CALLS
INT 08
Timer tick interrupt. Called 18.2 times a second on IRQ 0.
The interrupt is triggered by timer 0.
INT 21, FUNCTION 34
inDOS flag address request. This function returns the
address of the "inDOS flag" as a 32 bit pointer in ES:BX.
The inDOS flag is a byte that is zero when DOS is not
processing a function request, and is non-zero when DOS is
in a function.
;Page 24
NOTE: This function is officially specified as RESERVED.
It's use could change in future versions of DOS, and it can
only be guaranteed to work in straight IBM PC-DOS or MS-DOS
versions 2.0 to 3.30. Use at your own risk.
INT 28
DOS keyboard busy loop. This interrupt is called when DOS is
waiting for a keystroke in the console input functions.
When this interrupt is issued, it is safe to use any DOS
call ABOVE 0C. Calls to DOS functions 0 - 0C will trash the
stack and do nasty things.
NOTE: This function is officially RESERVED. See the note
for function 34 above.
AUTHOR'S NOTE:
First, the references I listed are really great. They've
helped me out a lot over the past few years. Second, if your
hard disk gets munched by your TSR, read the disclaimer.
! ! ! ! ! ! C A V E A T P R O G R A M M E R ! ! ! ! ! !
& Disclaimer
The techniques described in here are, for the most part,
UNDOCUMENTED by Microsoft or IBM. This means that you CAN NOT BE
SURE that they will work on all IBM clones, and could even cause
crashes on some! The timer tick interrupt provides some essential
system services, and messing with it incautiously can wreak havoc.
The program outlines presented here are what worked for me on
my system, and what should work on about 90% of the clones out
there. However, I still suggest that you find a reference for all
of the interrupts and functions described here. This file is meant
to be a guideline and aid only.
REFERENCES:
DOS Programmer's Reference, by Terry R. Dettmann.
$22.95, QUE Corporation
IBM DOS Technical Reference, version 3.30
$(?), International Business Machines Corp.
I can't remember how much it cost...
;Page 25
Environment Variable Processor
by David O'Riva
~
PAGE 60,132
TITLE Q43.ASM - editor prelude & display manager
;
;
COMMENT~***********************************************************************
* ---===> All code in this file is copyright 1989 by David O'Riva <===--- *
*******************************************************************************
* *
* The above line is there only to prevent people (or COMPANIIES) from *
* claiming original authorship of this code and suing me for using it. *
* You're welcome to use it anyhow you care to. *
* *
*
* Environment Variable Finder & Processor - *
* *
* The "get_environment_variable" routine is complete in itself, and can *
* be extracted and used in anything else that needs one. Just copy the entire
* routine, from the header to the endp (don't forget the RADIX and DW).
* Theroutine currently uses 315 (decimal) bytes.
*
*
* This program's purposeis to invoke an editor (or any program, really,
* with a specific machine state depending on environment variables. (Yeah!!!)
* Currently it is set up to change my screen to one of various modes, with
* the variable ED_SCRMODE being set to:
* 100/75 = 100 columns by 75 lines
* 132/44 = 132 by 44
* 80/44 = 80 by 44
* ...and then to EXEC my editor (qedit) with that mode set. You could
* set the screen back to the standard 80x25 after the EXEC returns.
*
* Note: The 80/44 set code should work on most (ar all?) EGAs. The
* other two high-res text modes use built-in extended BIOS modes in my
* Everex EV-657 EGA card (the 800x600 version) w/multisync monitor. If you've
* got one of those, you're in luck - no mods needed. It will also work on the
* EV-673 EVGA card w/appropriate monitor.
*
*
* Note to BEGINNERS: This is not an example of "good" asm code. This
* file is an example of what happens when you're up at 1:00am with too much
* coffee and a utility that needs to be fixed.
*
*
*
* This is a COM program, not an EXE. Remember to use EXE2BIN.
*
*
*
******************************************************************************~
; ; TRUE EQU 0FFH FALSE EQU 0 ;
;******************************************************************************
; CODE SEGMENT PARA PUBLIC 'CODE' ASSUME
CS:CODE,DS:CODE,ES:CODE,SS:CODE ; MAIN PROC NEAR
;Page 26
ORG 100H
entry:
;------------------------------------------------------------------------------
; set the screen to the correct mode
;------------------------------------------------------------------------------
call set_screen_mode
;------------------------------------------------------------------------------
; check for pathname change in environment
;------------------------------------------------------------------------------
call set_exec_name
;------------------------------------------------------------------------------
; setup memory and run the program
;------------------------------------------------------------------------------
MOV BX,OFFSET ENDRESIDENT ;deallocate unnecessary memory
MOV CL,4
SHR BX,CL
INC BX
MOV AH,04AH
INT 021H
MOV AX,CS ;exec the program
MOV INSERT_CS1,AX
MOV INSERT_CS2,AX
MOV INSERT_CS3,AX
MOV AX,04B00H
MOV BX,OFFSET EXECPARMS
MOV DX,OFFSET PROGNAME
INT 021H
;------------------------------------------------------------------------------
; clean up and leave
;------------------------------------------------------------------------------
MOV AH,04DH ;get return code from program
INT 021H
MOV AH,04CH ;leave
INT 021H
;
;******************************************************************************
;
; data
;
PROGNAME DB 'F:\UTILITY\MISC\Q.EXE',0
db 100 dup(' ')
EXECPARMS DW 0 ;use current environment
DW 080H ;use current command tail
INSERT_CS1 DW ?
DW 05CH ;use current FCB's
INSERT_CS2 DW ?
DW 06CH
INSERT_CS3 DW ?
;Page 27
ENDRESIDENT:
;******************************************************************************
; more data - used only for setup & checks
;
valid_modes db '80/44 '
db '132/44'
db '100/75'
screen_mode db ' '
mode_jump dw goto_43
dw goto_132
dw goto_100
ev_mode db 'ED_SCRMODE',0
ev_pathname db 'ED_PATH',0
PAGE
;******************************************************************************
; set_screen_mode -
;
;
; ENTRY:
;
; EXIT:
;
; DESTROYED:
;
;------------------------------------------------------------------------------
set_screen_mode:
MOV AH,012H ;check for presence of EGA/VGA
MOV BL,010H
INT 010H
CMP BL,010H ;BL changed? (should have # of
; bytes of EGA memory)
JE ssm_no_ega ;This is no EGA!
;------------------------------------------------------------------------------
; check environment for correct mode set -
; don't set mode if none specified
;------------------------------------------------------------------------------
mov si,offset ev_mode
mov di,offset screen_mode
mov cx,6 ;accept 6 chars
mov ax,4 ;get fixed-length string
call get_environment_variable
and ax,0feh
jne ssm_no_env_mode
;------------------------------------------------------------------------------
; look up the variable's value in my mode table
;------------------------------------------------------------------------------
mov bx,0
mov di,offset valid_modes
;Page 28
ssm_check_mode: mov dx,di
mov si,offset screen_mode
mov cx,6
repe cmpsb
je ssm_found_mode
mov di,dx
add di,6
inc bx
cmp bx,3
jne ssm_check_mode
jmp ssm_bad_mode
;------------------------------------------------------------------------------
; set the correct screen mode
;------------------------------------------------------------------------------
ssm_found_mode: shl bx,1
jmp mode_jump[bx]
goto_100: mov ax,0070h
mov bx,8
int 010h
jmp ssm_leave
goto_132: mov ax,0070h
mov bx,0bh
int 010h
jmp ssm_leave
goto_43: MOV AX,3
INT 010H
MOV AX,01112H ;set to 8x8 chars (43/50 lines)
MOV BL,0
INT 010H
ssm_no_env_mode:
ssm_bad_mode:
ssm_no_ega:
ssm_leave:
ret
PAGE
;******************************************************************************
; set_exec_name -
;
;
; ENTRY:
;
; EXIT:
;
; DESTROYED:
;
;------------------------------------------------------------------------------
set_exec_name:
;
; If you want, write a chunk here that will read an alternate pathname
; for the editor to be executed from a different variable (like ED_PATH)
;Page 29
; I was going to do it, but ran out of time and need. (My editor never wanders
; around!)
;
ret
PAGE
;******************************************************************************
; Get_environment_variable -
;
;
;
;
; ENTRY: ds:[si] -> ASCIIZ environment variable name
; ds:[di] -> (up to) 129 byte buffer for string
; es = segment of program's PSP
; cx = maximum # of characters to accept
; al = variable return format
; 0 - return string in ASCIIZ format
; xxxxx 0 ........
;
; 1 - return string in DOS string ('$' terminated) format
; xxxxxxxx $ ........
;
; 2 - return string in DOS input buffer format
; maxchrs,numchrs,xxxxxxxx CR ............
;
; 3 - return string in command tail format
; numchrs,xxxxxxxxxxx CR ..........
;
; 4 - return string in fixed-length (CX chars) format
; xxxxxx
;
; EXIT: al = return codes:
; bit 0 - if set, string was longer than max, truncated
; 1 - if set, string did not exist
; 2 - if set, invalid return format requested
;
; DESTROYED: ah is undefined
;
;------------------------------------------------------------------------------
.RADIX 010h
gev_flags dw ?
Get_environment_variable:
push bx
push cx
push dx
push si
;Page 30
push di
push es
mov cs:gev_flags,ax
mov es,es:[02c] ;es -> program's environment
;------------------------------------------------------------------------------
; make sure the environment has at least one variable in it
;------------------------------------------------------------------------------
mov ax,es:[0]
cmp ax,0
jne gev_exists
mov ax,2
jmp gev_leave
;------------------------------------------------------------------------------
; find length of search string
;------------------------------------------------------------------------------
gev_exists: push cx
push di
mov di,si
mov cx,0ffff
gev_sourcelen:
inc cx
mov al,[di]
inc di
cmp al,0
jne gev_sourcelen
cmp cx,0
jne gev_startfind
pop di
pop cx
mov ax,2
jmp gev_leave
;------------------------------------------------------------------------------
; find string
;------------------------------------------------------------------------------
gev_startfind: mov bx,cx
mov dx,si
mov di,0
gev_checknext:
mov cx,bx
mov si,dx
repe cmpsb
je gev_found?
gev_tonextvar: mov cx,0ffff
mov al,0
repne scasb
cmp es:[di],al
jne gev_checknext
mov ax,2
pop di
pop cx
jmp gev_leave
;Page 31
gev_found?: cmp byte ptr es:[di],'='
jne gev_tonextvar
;------------------------------------------------------------------------------
; found the string in the environment
;------------------------------------------------------------------------------
gev_found: inc di
mov si,di
pop di
pop cx
cmp cs:gev_flags,1
ja gev_ibufform
;------------------------------------------------------------------------------
; move normal string with 0 or $ terminator
;------------------------------------------------------------------------------
gev_nextchar0: mov al,es:[si]
cmp al,0
je gev_setterm0
mov ds:[di],al
inc si
inc di
dec cx
jne gev_nextchar0
mov al,es:[si]
cmp al,0
je gev_setterm0
mov al,1
gev_setterm0: cmp cs:gev_flags,0
jne gev_setterm1
mov byte ptr ds:[di],0 ;ASCIIZ string
jmp gev_leave
gev_setterm1: mov byte ptr ds:[di],'$' ;DOS string
jmp gev_leave
;------------------------------------------------------------------------------
; move string into DOS input buffer format (int 21 function 0A)
;------------------------------------------------------------------------------
gev_ibufform: cmp cs:gev_flags,2
jne gev_ctailform
mov ds:[di],cl ;set max length
inc di
mov bx,di
inc di
mov dx,0
gev_nextchar2: mov al,es:[si]
cmp al,0
je gev_setterm2
mov ds:[di],al
inc si
inc di
inc dx
dec cx
jne gev_nextchar2
mov al,es:[si]
cmp al,0
;Page 32
je gev_setterm2
mov al,1
gev_setterm2: mov byte ptr ds:[di],0d ;add carriage return
mov ds:[bx],dl ;set actual # of chars
jmp gev_leave
;------------------------------------------------------------------------------
; move string into command tail format
;------------------------------------------------------------------------------
gev_ctailform: cmp cs:gev_flags,3
jne gev_fixedform
mov bx,di
inc di
mov dx,0
gev_nextchar3: mov al,es:[si]
cmp al,0
je gev_setterm3
mov ds:[di],al
inc si
inc di
inc dx
dec cx
jne gev_nextchar3
mov al,es:[si]
cmp al,0
je gev_setterm3
mov al,1
gev_setterm3: mov byte ptr ds:[di],0d ;set carriage return
mov ds:[bx],dl ;set # of bytes
jmp gev_leave
;------------------------------------------------------------------------------
; move string into fixed-length area (pad it out with spaces)
;------------------------------------------------------------------------------
gev_fixedform: cmp cs:gev_flags,4
jne gev_badform
gev_nextchar4: mov al,es:[si]
cmp al,0
je gev_padout4
mov ds:[di],al
inc si
inc di
dec cx
jne gev_nextchar4
mov al,es:[si]
cmp al,0
je gev_setterm4
mov al,1
jmp gev_setterm4
gev_padout4: mov byte ptr ds:[di],' '
inc di
dec cx
jne gev_padout4
;Page 33
mov al,0
gev_setterm4: jmp gev_leave
gev_badform: mov ax,4
gev_leave: pop es
pop di
pop si
pop dx
pop cx
pop bx
ret
.RADIX 00ah
MAIN ENDP
;
;******************************************************************************
;
CODE ENDS
;
;******************************************************************************
;
END ENTRY
~
;Page 34
Program Reviews
Multi-Edit ver 4.00a (demo version): Reviewed by Patrick O'Riva.
Multi-Edit is a high feature text editor with many word
processor features. The demo version is completely functional though
some of the reference material is not supplied and there are
advertising screens. I consider this fully acceptable as shareware.
The complete version with the macro reference library is available
for 79.95 and an expanded version with a spelling checker,
integrated Communication terminal and phone book is $179.95.
I couldn't list all of its features here, but in addition to
everything you have come to expect in a quality programming editor
(multi meg files, programmable keyboard etc.) there are a number of
powerful additions you might not expect. The word processor
functions rival most of the specialty ones that I've tried. It
won't compete with the major names for those of you who are addicted
to them, but it does offer full printer support, preview file, table
of contents generation, and extension keyed formatting. It will
right or left justify, and supports headers and footers, and auto
pagination.
It contains a calculator and an Ascii table
Saving the best for last: The language support is very strong.
It has built in templates for many common constructs, and the
assembler/compiler is invoked from within the editor with a single
key. It will read the error table generated by a variety of software
and with successive key presses move you to each line where an error
was found.
Something which I found unique is Multi-Edit's help system. It
is a hypertext system, and is wonderfully context sensitive most
everywhere in the system. From the Help menu it has a complete table
of contents and index. It is also fully user extendible. I have
integrated a database I have documenting the full set of interrupts
that totals about 400k and the documentation on my spelling checker
as well (which integrated into Multi-Edit almost seamlessly).
In many ways this is the best editor I've ever used, but it
does have a few faults, some of which are very subtle and may not
even be problems to most users. It is a 'tad' slower that what I'm
used to with Qedit. This is seldom noticed except in the execution
of complex macros. It is quite slow in paging through long files.
There are some true bugs in this version such as a crash of the
program (but not the data or the system) when large deletes from
large files are made. Multi-edit's treatment of file windows while
very versatile is slightly different and may take some time to get
used to.
For all of its advantages, until putting this Magazine
together, I still found myself reverting to Qedit for the speed and
ease of use. It is the first software that has made this anything
other than an exercise in frustration.
;Page 35
SHEZ
Just a quick mention because it isn't programming related.
Shez is a compression shell along the lines of ArcMaster and Qfiler.
It is a fine and versatile piece of programming, supporting all
common compression types. The more recent versions have virus
detection when used with the SCANV programs by John McAfee.
4DOS
This is a program that is an absolute joy to use. It is a
complete and virtually 100% compatible replacement for Command.com.
The code size is just slightly larger than MSDOS 3.3 command.com but
the added and enhanced functions save many times that amount in
TSR's you no longer need to install. Just to mention a few features:
An alias command whereby you can assign whatever mnemonic you
wish to a command or string of commands. Select is a screen
interface that allows you to mark files for use with a command.
Except will execute a command for a set of files excluding one or
more. There is an environment editor, built in Help, command
and filename completion, Global that will execute through the
directory tree, A Timer to keep track of elapsed time, as well as
many enhanced batch file commands. Additional features are too
numerous to mention. The current version is 4.23 and is available as
Shareware, but you should register after your first 10 minutes of
use. You will be hooked forever.
The above 3 programs should all be available on your local BBS's.
Please be sure and register programs you use.
;Page 36
Book Reviews
Assembly Language Quick Reference
by Allen L. Wyatt, Sr.
Reviewed by George A. Stanislav
This 1989 book published by QUE is a nice and handy reference for
assembly language programmers.
Instruction sets for six microprocessors and numeric coprocessors
are listed:
8086/8088 8087
80286 80287
80386 80387
I could find no reference to the 80186 microprocessor, not even a
suggestion that it uses the 80286 instruction set but does not
multitask. Because the 80186 was the brain of Tandy 2000, quite a
popular computer in its own time, its omission from the book is
surprising.
There is no division into chapters. This makes it somewhat hard to
figure out where the instruction sets of individual processors
start. Each higher processor set contains only the list of
instructions that are new for the processor or that changed
somewhat.
After a brief introduction, the book starts by listing,
alphabetically, all 8086/8088 instructions. The listing itself is
very well done. Each instruction stands out graphically from the
rest of the text. For every code there is some classification, e.g.
arithmetic, bit manipulation, data-transfer.
This is followed by a very brief description ended with a colon.
Next, a more detailed explanation gives sufficient information to
any assembly language programmer what the instruction does.
If applicable, the book lists flags affected by the instruction.
Most instructions also contain some coding examples.
The 8086/8088 instruction set is followed by the 80286 set, or
rather subset as it only contains the instructions new to this
microprocessor. Similarly, the 80386 section contains only those
instructions not found in the 8086/8088 and 80286 sections as well
as those that changed somewhat.
I find it puzzling that among those instructions considered changed
in the 80386 microprocessor we can find AND, NEG, POP - because they
can be used as 32-bit instructions in addition to their original
usage - but cannot find JE, JNE, and all other conditional jumps.
These did indeed change in the 80386 processor inasmuch they can be
used either as SHORT or as NEAR while on the older microprocessors
they could only jump within the SHORT range.
;Page 37
The rest of the book contains instructions for the math
coprocessors, the 8087, 80287 and 80387. This section is divided in
the same way as the microprocessor part, i.e. describing first the
8087 set, then the one new instruction for the 80286, followed by
the new 80387 instructions.
There are several possibilities of improvement QUE might consider
for future editions of this book:
o Make it easier to find the start of each section by color
coding the side of the paper;
o Include references to the instructions of the older
processors within the listing for the new processors.
Small print of the instruction with the page number where
a more detailed description can be found would be a nice
enhancement;
o At least a brief mention of the 80186 microprocessor and
perhaps the V-20 and V-30 would be useful.
Despite the possibility of improvement, this is an excellent
reference for any assembly language programmer. Its small size makes
it very handy to keep it next to the computer as well as to take it
along when travelling.
The book costs $6.95 in USA and $8.95 in Canada.
;Page 38
GPFILT.ASM
~
page ,132
TITLE GPFILT
subttl General Purpose Filter Template
;
; GPFILT.ASM
; This file contains a template for a general-purpose assembly language
; filter program.
;
; Fill in the blanks for what you wish to do. The program is set up to
; accept a command line in the form:
; COMMAND [{-|/}options] [infile [outfile]]
;
; If infile is not specified, stdin is used.
; If outfile is not specified, stdout is used.
;
; To compile and link:
; MASM GPFILT ;
; LINK GPFILT ;
; EXE2BIN GPFILT GPFILT.COM
;
; Standard routines supplied in the general shell are:
;
; get_arg - returns the address of the next command line argument in
; DX. Since this is a .COM file, the routine assumes DS will
; be the same as the command line segment.
; The routine will return with Carry set when it reaches the end
; of the command line.
;
; err_msg - displays an ASCIIZ string on the STDERR device. Call with the
; address of the string in ES:DX.
;
; do_usage- displays the usage message on the STDERR device and exits
; with an error condition (errorlevel 1). This routine will
; never return.
;
; getch - returns the next character from the input stream in AL.
; It will return with carry set if an error occurs during read.
; It will return with the ZF set at end of file.
;
; putch - writes a character from AL to the output stream. Returns with
; carry set if a write error occurs.
;
cseg segment
assume cs:cseg, ds:cseg, es:cseg, ss:cseg
org 0100h ;for .COM files
start: jmp main ;jump around data area
;
; Equates and global data area.
;
; The following equates and data areas are required by the general filter
; routines. User data area follows.
;
;Page 39
STDIN equ 0
STDOUT equ 1
STDERR equ 2
STDPRN equ 3
cr equ 0dh
lf equ 0ah
space equ 32
tab equ 9
infile dw STDIN ;default input file is stdin
outfile dw STDOUT ;default output file is stdout
errfile dw STDERR ;default error file is stderr
prnfile dw STDPRN ;default print file is stdprn
cmd_ptr dw 0081h ;address of first byte of command tail
PSP_ENV equ 002ch ;The segment address of the environment
;block is stored here.
infile_err db cr, lf, 'Error opening input file', 0
outfile_err db cr, lf, 'Error opening output file', 0
aborted db 07, cr, lf, 'Program aborted', 0
usage db cr, lf, 'Usage: ', 0
crlf db cr, lf, 0
;************************************************************************
;* *
;* Buffer sizes for input and output files. The buffers need not be *
;* the same size. For example, a program that removes tabs from a text *
;* file will output more characters than it reads. Therefore, the *
;* output buffer should be slightly larger than the input buffer. In *
;* general, the larger the buffer, the faster the program will run. *
;* *
;* The only restriction here is that the combined size of the buffers *
;* plus the program code and data size cannot exceed 64K. *
;* *
;* The easiest way to determine maximum available buffer memory is to *
;* assemble the program with minimum buffer sizes and examine the value *
;* of the endcode variable at the end of the program. Subtracting this *
;* value from 65,536 will give you the total buffer memory available. *
;* *
;************************************************************************
;
INNBUF_SIZE equ 31 ;size of input buffer (in K)
OUTBUF_SIZE equ 31 ;size of output buffer (in K)
;
;************************************************************************
;* *
;* Data definitions for input and output buffers. DO NOT modify these *
;* definitions unless you know exactly what it is you're doing! *
;* *
;************************************************************************
;
; Input buffer
ibfsz equ 1024*INNBUF_SIZE ;input buffer size in bytes
inbuf equ endcode ;input buffer
ibfend equ inbuf + ibfsz ;end of input buffer
;
;Page 40
; ibfptr is initialized to point past end of input buffer so that the first
; call to getch will result in a read from the file.
;
ibfptr dw inbuf+ibfsz
; output buffer
obfsz equ 1024*OUTBUF_SIZE ;output buffer size in bytes
outbuf equ ibfend ;output buffer
obfend equ outbuf + obfsz ;end of output buffer
obfptr dw outbuf ;start at beginning of buffer
;************************************************************************
;* *
;* USER DATA AREA *
;* *
;* Insert any data declarations specific to your program here. *
;* *
;* NOTE: The prog_name, use_msg, and use_msg1 variables MUST be *
;* defined. *
;* *
;************************************************************************
;
; This is the program name. Under DOS 3.x, this is not used because we
; can get the program name from the environment. Prior to 3.0, this
; information is not supplied by the OS.
;
prog_name db 'GPFILT', 0
;
; This is the usage message. The first two lines are required.
; The first line is the programs title line.
; Make sure to include the 0 at the end of the first line!!
; The second line shows the syntax of the program.
; Following lines (which are optional), are discussion of options, features,
; etc...
; The message MUST be terminated by a 0.
;
use_msg db ' - General Purpose FILTer program.', cr, lf, 0
use_msg1 label byte
db '[{-|/}options] [infile [outfile]]', cr, lf
db cr, lf
db 'If infile is not specified, STDIN is used', cr, lf
db 'If outfile is not specified, STDOUT is used', cr, lf
db 0
;
;************************************************************************
;* *
;* The main routine parses the command line arguments, opens files, and *
;* does other initialization tasks before calling the filter procedure *
;* to do the actual work. *
;* For a large number of filter programs, this routine will not need to *
;* be modified. Options are parsed in the get_options proc., and the *
;* filter proc. does all of the 'filter' work. *
;* *
;************************************************************************
;
main: cld
call get_options ;process options
;Page 41
jc gofilter ;carry indicates end of arg list
mov ah,3dh ;open file
mov al,0 ;read access
int 21h ;open the file
mov word ptr ds:[infile], ax ;save file handle
jnc main1 ;carry clear indicates success
mov dx,offset infile_err
jmp short err_exit
main1: call get_arg ;get cmd line arg in DX
jc gofilter ;carry indicates end of arg list
mov ah,3ch ;create file
mov cx,0 ;normal file
int 21h ;open the file
mov word ptr ds:[outfile],ax ;save file handle
jnc gofilter ;carry clear indicates success
mov dx,offset outfile_err
jmp short err_exit
gofilter:
call filter ;do the work
jc err_exit ;exit immediately on error
mov ah,3eh
mov bx,word ptr [infile]
int 21h ;close input file
mov ah,3eh
mov bx,word ptr [outfile]
int 21h ;close output file
mov ax,4c00h
int 21h ;exit with no error
err_exit:
call err_msg ;output error message
mov dx,offset aborted
call err_msg
mov ax,4c01h
int 21h ;and exit with error
;
;************************************************************************
;* *
;* get_options processes any command line options. Options are *
;* preceeded by either - or /. There is a lot of flexibility here. *
;* Options can be specified separately, or as a group. For example, *
;* the command "GPFILT -x -y -z" is equivalent to "GPFILT -xyz". *
;* *
;* This routine MUST return the address of the next argument in DX or *
;* carry flag set if there are no more options. In other words, return *
;* what was returned by the last call to get_arg. *
;* *
;************************************************************************
;
get_options proc
call get_arg ;get command line arg
jnc opt1
; If at least one argument is required, use this line
; call do_usage ;displays usage msg and exits
; If there are no required args, use this line
ret ;if no args, just return
opt1: mov di, dx
mov al,byte ptr ds:[di]
;Page 42
cmp al,'-' ;if first character of arg is '-'
jz opt_parse
cmp al,'/' ;or '/', then get options
jz opt_parse
ret ;otherwise exit
opt_parse:
inc di
mov al,byte ptr ds:[di]
or al,al ;if end of options string
jz nxt_opt ;get cmd. line arg
cmp al,'?' ;question means show usage info
jz do_usage
;
;************************************************************************
;* *
;* Code for processing other options goes here. The current option *
;* character is in AL, and the remainder of the option string is pointed*
;* to by DS:DI. *
;* *
;************************************************************************
;
jmp short opt_parse
nxt_opt:
call get_arg ;get next command line arg
jnc opt1 ;if carry
vld_args: ;then validate arguments
;
;************************************************************************
;* *
;* Validate arguments. If some options are mutually exclusive/dependent*
;* use this area to validate them. Whatever the case, if you must *
;* abort the program, call the do_usage procedure to display the usage *
;* message and exit the program. *
;* *
;************************************************************************
;
ret ; no more options
;
;************************************************************************
;* *
;* Filter does all the work. Modify this routine to do what it is you *
;* need done. *
;* *
;************************************************************************
;
filter proc
call getch ;get a character from input into AL
jbe filt_done ;exit on error or EOF
and al, 7fh ;strip the high bit
call putch ;and output it
jc filt_ret ;exit on error
jmp short filter
filt_done:
jc filt_ret ;carry set is error
call write_buffer ;output what remains of the buffer
filt_ret:
;Page 43
ret
filter endp
;
;************************************************************************
;* *
;* Put any program-specific routines here *
;* *
;************************************************************************
;
;************************************************************************
;* *
;* For most programs, nothing beyond here should require modification. *
;* The routines that follow are standard routines used by almost every *
;* filter program. *
;* *
;************************************************************************
;
;************************************************************************
;* *
;* This routine outputs the usage message to the STDERR device and *
;* aborts the program with an error code. A little processing is done *
;* here to get the program name and format the output. *
;* *
;************************************************************************
;
do_usage:
mov dx, offset crlf
call err_msg ;output newline
mov ah,30h ;get DOS version number
int 21h
sub al,3 ;check for version 3.x
jc lt3 ;if carry, earlier than 3.0
;
; For DOS 3.0 and later the full pathname of the file used to load this
; program is stored at the end of the environment block. We first scan
; all of the environment strings in order to find the end of the env, then
; scan the load pathname looking for the file name.
;
push es
mov ax, word ptr ds:[PSP_ENV]
mov es, ax ;ES is environment segment address
mov di, 0
mov cx, 0ffffh ;this ought to be enuf
xor ax, ax
getvar: scasb ;get char
jz end_env ;end of environment
gv1: repnz scasb ;look for end of variable
jmp short getvar ;and loop 'till end of environment
end_env:
inc di
inc di ;bump past word count
;
; ES:DI is now pointing to the beginning of the pathname used to load the
; program. We will now scan the filename looking for the last path specifier
; and use THAT address to output the program name. The program name is
; output WITHOUT the extension.
;Page 44
;
mov dx, di
fnloop: mov al, byte ptr es:[di]
or al, al ;if end of name
jz do30 ;then output it
inc di
cmp al, '\' ;if path specifier
jz updp ;then update path pointer
cmp al, '.' ;if '.'
jnz fnloop
mov byte ptr es:[di-1], 0 ;then place a 0 so we don't get ext
jmp short fnloop ; when outputting prog name
updp: mov dx, di ;store
jmp short fnloop
;
; ES:DX now points to the filename of the program loaded (without extension).
; Output the program name and then go on with rest of usage message.
;
do30: call err_msg ;output program name
pop es ;restore
jmp short gopt3
;
; We arrive here if the current DOS version is earlier than 3.0. Since the
; loaded program name is not available from the OS, we'll output the name
; entered in the 'prog_name' field above.
;
lt3: mov dx, offset prog_name
call err_msg ;output the program name
;
; After outputting program name, we arrive here to output the rest of the
; usage message. This code assumes that the usage message has been
; written as specified in the data area.
;
gopt3: mov dx, offset use_msg
call err_msg ;output the message
mov dx, offset usage
call err_msg
mov dx, offset use_msg1
call err_msg
mov ax,4c01h
int 21h ;and exit with error
get_options endp
;
;************************************************************************
;* *
;* Output a message (ASCIIZ string) to the standard error device. *
;* Call with address of error message in ES:DX. *
;* *
;************************************************************************
;
err_msg proc
cld
mov di,dx ;string address in di
mov cx,0ffffh
xor ax,ax
repnz scasb ;find end of string
;Page 45
xor cx,0ffffh
dec cx ;CX is string length
push ds
mov ax,es
mov ds,ax ;DS is segment address
mov ah,40h
mov bx,word ptr cs:[errfile]
int 21h ;output message
pop ds
ret
err_msg endp
;
;************************************************************************
;* *
;* getch returns the next character from the file in AL. *
;* Returns carry = 1 on error *
;* ZF = 1 on EOF *
;* Upon exit, if either Carry or ZF is set, the contents of AL is *
;* undefined. *
;* *
;************************************************************************
;
; Local variables used by the getch proc.
eof db 0 ;set to 1 when EOF reached in read
last_ch dw ibfend ;pointer to last char in buffer
getch proc
mov si,word ptr ds:[ibfptr] ;get input buffer pointer
cmp si,word ptr ds:[last_ch];if not at end of buffer
jz getch_eob
getch1: lodsb ;character in AL
mov word ptr ds:[ibfptr],si ;save buffer pointer
or ah,1 ;will clear Z flag
ret ;and done
getch_eob: ;end of buffer processing
cmp byte ptr ds:[eof], 1 ;end of file?
jnz getch_read ;nope, read file into buffer
getch_eof:
xor ax, ax ;set Z to indicate EOF
ret ;and return
getch_read: ; Read the next buffer full from the file.
mov ah,3fh ;read file function
mov bx,word ptr ds:[infile] ;input file handle
mov cx,ibfsz ;#characters to read
mov dx,offset inbuf ;read into here
int 21h ;DOS'll do it for us
jc read_err ;Carry means error
or ax,ax ;If AX is zero,
jz getch_eof ;we've reached end-of-file
add ax,offset inbuf
mov word ptr ds:[last_ch],ax;and save it
mov si,offset inbuf
jmp short getch1 ;and finish processing character
;Page 46
read_err: ;return with error and...
mov dx,offset read_err_msg ; DX pointing to error message string
ret
read_err_msg db 'Read error', cr, lf, 0
getch endp
;
;************************************************************************
;* *
;* putch writes the character passed in AL to the output file. *
;* Returns carry set on error. The character in AL is retained. *
;* *
;************************************************************************
;
putch proc
mov di,word ptr ds:[obfptr] ;get output buffer pointer
stosb ;save the character
mov word ptr ds:[obfptr],di ;and update buffer pointer
cmp di,offset obfend ;if buffer pointer == buff end
clc
jnz putch_ret
push ax
call write_buffer ;then we've got to write the buffer
pop ax
putch_ret:
ret
putch endp
;
;************************************************************************
;* *
;* write_buffer writes the output buffer to the output file. *
;* This routine should not be called except by the putch proc. and at *
;* the end of all processing (as demonstrated in the filter proc). *
;* *
;************************************************************************
;
write_buffer proc ;write buffer to output file
mov ah, 40h ;write to file function
mov bx, word ptr ds:[outfile];output file handle
mov cx, word ptr ds:[obfptr]
sub cx, offset outbuf ;compute #bytes to write
mov dx, offset outbuf ;from this buffer
int 21h ;DOS'll do it
jc write_err ;carry is error
or ax,ax ;return value of zero
jz putch_full ;indicates disk full
mov word ptr ds:[obfptr],offset outbuf
clc
ret
putch_full: ;disk is full
mov dx,offset disk_full
stc ;exit with error
ret
write_err: ;error occured during write
;Page 47
mov dx,offset write_err_msg
stc ;return with error
ret
write_err_msg db 'Write error', cr, lf, 0
disk_full db 'Disk full', cr, lf, 0
write_buffer endp
;
;************************************************************************
;* *
;* get_arg - Returns the address of the next command line argument in *
;* DX. The argument is in the form of an ASCIIZ string. *
;* Returns Carry = 1 if no more command line arguments. *
;* Upon exit, if Carry is set, the contents of DX is undefined. *
;* *
;************************************************************************
;
get_arg proc
mov si,word ptr [cmd_ptr]
skip_space: ;scan over leading spaces and commas
lodsb
cmp al,0 ;if we get a null
jz sk0
cmp al,cr ;or a CR,
jnz sk1
sk0: stc ;set carry to indicate failure
ret ;and exit
sk1: cmp al,space
jz skip_space ;loop until no more spaces
cmp al,','
jz skip_space ;or commas
cmp al,tab
jz skip_space ;or tabs
mov dx,si ;start of argument
dec dx
get_arg1:
lodsb ;get next character
cmp al,cr ;argument seperators are CR,
jz get_arg2
cmp al,space ;space,
jz get_arg2
cmp al,',' ;comma,
jz get_arg2
cmp al,tab ;and tab
jnz get_arg1
get_arg2:
mov byte ptr ds:[si-1], 0 ;delimit argument with 0
cmp al, cr ;if char is CR then we've reached
jnz ga2 ; the end of the argument list
dec si
ga2: mov word ptr ds:[cmd_ptr], si ;save for next time 'round
ret ;and return
get_arg endp
;Page 48
endcode equ $
cseg ends
end start
~
;Page 49
|
