NOTICE

The source code to DISASMBL was modified after the SESSION was prepared.
The .COM file was not changed so it would be as described in the SESSION.
The source code contains enhancements, so to get the benefit of them, you
should assemble, link and convert the source code to a .COM file before you
use DISASMBL for anything other than the tutorial.

HISTORY

ASMGEN version 2.01 was released into the public domain November 23, 1983.
When I downloaded it January 11, 1987 the files in the archive were dated
February 7, 1986. Since more than two years had elapsed since its release,
I assumed that no further development was contemplated by the original
authors, even though it had a bug and a couple of small errors in the
documentation.

I have used it extensively; perhaps you have seen some of the DOS 3.2 files
I disassembled and uploaded. Its shortcomings bothered me, I suppose
mostly because they are so trivial that I thought they could be easily
remedied. In June of 1988, I looked for other disassemblers on the boards
and found nothing, although I admit that my search was far from thorough.
Since my search came up empty, I decided to disassemble ASMGEN and correct
its shortcomings. Wow, did I find out how bad an assembly programmer I am!
I was able to correct three of the problems I had objections to, but much
of the code remains a mystery to me so the other corrections and
enhancements I had envisioned are not accomplished in this release.


STATEMENT OF POLICY

Since this isn't my program, since it is apparently abandoned by its
authors and since it was in the public domain in the first place, you may
do anything you please with it. However, if you improve on it, I ask you
to make it, INCLUDING THE SOURCE CODE, available to everyone and I ask that
you mail me the source code in 5 1/4 inch floppy format.


OK BRANDY, WHAT DID YOU CHANGE?

Version 2.01 would disassemble LES instructions using the wrong register so
that, for example, it disassembled "LES DI,Etc." as "LES BH,Etc."
because it checked the wrong operand when it decided what general purpose
register to use. Since the LES instruction demands a 16-bit register, this
caused an error at assembly time. It now works correctly, even though my
patch was a kludge.

I try to use descriptive labels and data names in my assembly source code
in order to make it more understandable. I also like source code formatted
according to strict conventions such as those used in COBOL and C, because
I find randomly formatted code hard to read and follow. One of the
formatting conventions I use is to place each label on its own line,
usually followed by a comment stating its function. DISASMBL now places
all labels which are terminated by a colon on a separate line.

Version 2.01 caused assembly errors if it found questionable code because
it placed question marks after such code but did not insert a semicolon
before the question marks. Since MASM considers question marks to be
special characters, this did not generate a simple "Extra characters on
line" warning. It caused "Symbol not defined" errors or "Illegal use of
undefined operand" errors. This prevented the object code from being
output. DISASMBL now places a semicolon before the question marks.

I added the "Z" switch, which causes a help file to be written which may
then be used to assist in the preparation of the .SEQ file. I have also
provided a BASIC program to remove the duplications in that file.


WHAT STILL NEEDS TO BE DONE?

Misleading or erroneous comments in the source code need to be corrected,
then the rest of the code should be fully commented and names substituted
for labels.

DISASMBL does not correctly disassemble CALL FAR PTR and JMP FAR PTR
instructions, causing and error at assembly time. It should be corrected
to overcome that shortcoming.

When data is referred to as both BYTE type and as WORD type, the data
should be redefined by DISASMBL and the code should be modified to select
the operand which is the correct size; it is frequently necessary to refer
to a pair of bytes as a WORD. This might be done with an additional
data-type command for the sequential file which would indicate that the
data is both WORD size and BYTE size.

My help file code is very amateurish. Because there is all that good
information in the reference table, it should be easy to create a much
better help file.

DISASMBL inserts "BYTE PTR" or "WORD PTR" in places where they are not
appropriate. Since this is a two pass disassembler, the data's size is (or
could be) known at the time the .ASM code is generated, so this shouldn't
be a big problem to correct.

When a reference to an offset which is outside the program's address limits
is made, it HAS to be an immediate item. In that case, DISASMBL should not
insert the "OFFSET L", nor should it create the EQUate. Instead, it should
use the immediate or constant form.

Labels and equates which are never used should not be included in the
source code, but they frequently are, particularly when a .COM file is
being disassembled in which case DISASMBL causes EQUates to be generated
from zero through FF. Again, since this is a two pass disassembler,
DISASMBL knows from the reference table in memory what EQUates or labels
are required and should include only those in the source code. I find
extraneous labels especially confusing when disassembling an .EXE file
because they are embedded in the code, leading me to think there may be
calls into the middle of a routine when there are not.

Some areas of the code are modified by the program during execution in
order for DISASMBL to correctly function. I strongly object to that, even
when the alternative is slower code or a bigger program. If program size
is a problem, DISASMBL could be an .EXE file, have a separate data segment
and thus recover 7215 bytes which is now code instead of data, and it could
also use the extra (ES) segment for the reference table, which would allow
a 64Kb reference table. The sequential file information and the .EXE
relocation entries could be in the data segment and thus be 64Kb, less the
size of the rest of the data. Everybody has at least 512Kb memory now.


A few data items are embedded in the code; the rest is all at the end. I
think all data belongs in the data segment or, in the case of a .COM file,
all in the same area, preferably at the beginning of the code. Placing the
data at the beginning of the code makes the job easier for MASM and results
in tighter code. We all like it tighter, right?

I am sometimes unable to get an instruction generated by DISASMBL to
assemble using the exact bytes involved in the original. For example,
CMP DX,0FFFF was 81 FA FF FF in the original program but it is
CMP DX,-1 (83 FA FF) when assembled and linked. This may be due to MASM
or to LINK, but it bothers me to do a file compare of my executable file
with the original file and to find a difference of this sort.

A thorough disassembler would include the ability to disassemble 80287 and
80387 instructions.


WHERE TO SEND YOUR IMPROVED SOURCE CODE

Brandy
132 Formac Avenue
Eugene, OR 97404-2606