mor@datlog.co.uk ( Mike O'Reilly ) (11/23/89)
I have posted a uuencoded binary file DX.EXE to comp.os.os2. DX is a programmer's tool, described below, which can be very useful for observing unfamiliar EXE and DLL files on OS/2. The binary is now in the PUBLIC DOMAIN. The DX.EXE file size is approx 22Kb and runs only in protected mode. The USENET posting containing the uuencoded file is approx 30Kb or 494 lines. To get the executable, save the posting, strip off the email header then uudecode the file to produce DX.EXE. The rest of this note describes DX ; this information is also available by typing dx -help . DX.EXE shows makeup and dependency information about OS/2 EXE & DLL modules. It is a programmer's tool which complements Microsoft's EXEHDR.EXE program. You can use it for simple analysis of unfamiliar packages on OS/2. Dx displays a re-constructed DEF file (module definition file) for each argument module, showing the IMPORT and EXPORT lists as well as other standard DEF file information. Here is a explanation of the IMPORT and EXPORT information from DX. A module can EXPORT functions by NAME and/or by ORDINAL, for example: EXPORTS KBDCHARIN ; export by name (ordinal not specified) KBDCHARIN @4 ; export by ordinal KBDCHARIN @4 RESIDENTNAME ; export by ordinal AND by name DX always shows the export ordinal, so it appends "RESIDENTNAME" if the function has also been exported by name. A module can IMPORT functions by NAME or by ORDINAL, for example: IMPORTS KBDCALLS.KBDCHARIN ; import by name KBDCHARIN = KBDCALLS.4 ; import by ordinal DX uses both of the above IMPORT formats, depending on whether the function is imported by ordinal or by name. If it is imported by name, DX adds the ordinal number as a comment. Thus, DX shows you the name, DLL and ordinal for each function imported by the argument module. DX generates names for code and data segments because it works at executable level rather than at object code level. We are working on enhancements to DX to show the stack parameter for exported IOPL functions and a module patching facility. We will release these when time allows. ------------------------------------------------------------------------- -- -mike (mor@datlog.co.uk). DISCLAIMER: I speak for myself, not my employer.