Article 152362 of comp.os.vms:
In article <4tqibe$du1@mtinsc01-mgt.ops.worldnet.att.net>, "EDWARD B. EVERHART" <EDHERE@postoffice.worldnet.att.net> writes:
>The DISM32 program will do an excellent job of disassembling VAX .EXE
>files back into MACRO32. Be aware, you need to run the thing, inspect
>the .SYM file it produces and the .MAR file, and readjust the symbol
>types for it to find the entire tree of instruction sequences. However
>it does a wonderful job in a relatively short time. (Once you edit
>the .SYM file, disassemble again to get a new pass. It is worth
>while to say "dism32/ascii/string" often instead of merely "dism32".

Yes, a wonderful job!  I've recently used DISM32 to determine the
existance of some code in some device drivers.  DISM32 does a real
nice job of it when the .EXE is a VAX device driver.  

It's even smart enought to reproduce DPTs, DDTs, etc. in their macro 
forms!  The FDT is displayed with the familiar FUNCTAB macro and the
function masks.  It's very impressive!  

One of the things it needs some help in is determining the start of
a code thread, especially, after a thread does something like return
to caller's caller -- for example, many FORKing routines will make 
the disassembler think it's at the end of a thread and the subsequent
code will appear as data and not dissassembled code.

When this happens, you need to become a skilled "byte" counter and
count the number of instruction bytes from the last known code ad-
dress to the non-disassembled part of the code.  Then, add a line
to the .SYM file to identify the address as code.  I've done this
as a type of 00000004(16) which is a JMP/BRB/BRW label.  Then, a
second pass and the dissassembler can pickup where it left off.

A few other things to point out that are not in the DISM32 doc.

After a pass, you may find the .SYM file will contain symbols that
have the bit 10000000(16) set.  This bit is not documented.  In the
source I found that it indicates that the disassembler was able to
determine the use of this section of the .EXE but that the symbol 
is not actually referenced.  Typical case in point: The DPTAB has
a symbol name of DPT$xxx but is usually not referenced in a driver.
DISM32 creates the symbol and then, sets the 10000000(16) bit on the
symbol.  Subsequent passes will cause this symbol to be discarded and
then, DISM32 uses the last known good symbol plus an offset to denote
the symbol.  I'd get out things like CLU$GL_CLUB+2146579560!  You may
(will) want to clear this bit before each subsequent pass.

Also, the DISM32 will, if the code you're disassembling is a device 
driver, make assumptions about certain addresses which have standard
driver function uses but have, over the years, been used by driver 
coders for other uses.  For example, the DPTAB argument VECTOR_AREA 
will cause DISM32 to assume a terminal driver vector table: 00080000(16) 
with attribute type 24.  This can completely confuse the rest of the 
disassembly.  I've found that you can go into the .SYM file and make
this a bound-label-value 00080000(16) attribute type 36, you'll have
much better results.

If you need any other pointers, drop me a line.

>You can find DISM32 on some recent VMS SIG tapes or at various VMS
>sites like ftp.decus.org, ftp.wku.edu, or others.
>There is another interactive disassembler, I forget the name, but it
>appeared on a sigtape a couple or three years ago.
>
>These are generally easier to use for bulk disassembly than patch or
>debug...

Far better because of things like its ability to replace data and code
it locates with the equivalent macros!

-- 
VAXman-

For without are dogs, and sorcerers, and whoremongers, and murderers,
and idolaters, and whosoever loveth and maketh a lie.    (Revelation)