DCU2INT_GUI

The DCU32INT utility by Alexei Hmelnov. Version 1.10.0 ---------------------------------------------------------------------------- E-Mail: alex@icc.ru http://hmelnov.icc.ru/DCU/ ---------------------------------------------------------------------------- Purpose. -------- Parse Delphi 2.0-8.0, 2005(.net and WIN32), 2006(WIN32 only), Kylix 1.0-3.0 units (DCU) and convert their information into the close to Pascal form. DCU32INT stands for DCU32 INTerface, because this program can't extract the complete Pascal source, but the extracted unit interface is almost correct (see Compiler Information Loss Limitations section for exceptions). This program is a by-product of the FlexT project (see http://hmelnov.icc.ru/FlexT/ for details), but I have done my best to make it useful. Changes from the version 1.0. ----------------------------- Version 1.10.0: 1. Units of Delphi 2006 (WIN32) were parsed successfully. Version 1.9.0: 1. Units of Delphi 2005 (WIN32, .net) were parsed successfully. Version 1.8.0: 1. The generic disassembler was implemented. It is now possible to register a new disassemblers using the call SetDisassembler(ReadCommand, ShowCommand,CheckCommandRefs) 2. The MSIL (MicroSoft Intermediate Layer) disassembler for .net code was implemented. 3. Units of Delphi 8.0 were parsed successfully. Version 1.7.4: 1. Some control flow analysis was implemented for disassembler (the -AC program option). Version 1.7.3: 1. Units of Delphi 7.0 were parsed successfully. Version 1.7.2: 1. Units of open Kylix 3.0 were parsed successfully. Version 1.7.1: 1. Units of open Kylix 3.0 were parsed successfully. Version 1.7.0: 1. Some units of trial Delphi 7.0 were parsed successfully. Version 1.6.4: 1. A problem was fixed with resourcestring sections inside procedures. Version 1.6.3: 1. Some tricky Kylix header fields prevented from processing some files. This problem was fixed, but only for the examples of Kylix DCUs, which I have. Please, send me DCUs, which still can't be parsed. Version 1.6.2: 1. Kylix 2.0 units are supported. In fact, only the file signature change was detected. Version 1.6.1: 1. The DCU32INT sources can now be compiled under Kylix. 2. User units compiled under Kylix have another header structure, than that of Kylix LIB units, on which DCU32INT was originally tested. The program was fixed to take it into account. Version 1.6.: 1. Delphi 6.0 and Kylix 1.0 units are supported now. Note, this feature is new and it was tested almost only on the .\LIB\*.dcu files (see Validity), so bug reports are welcome with the units, which were not parsed correctly, applied. Please send them to alex@icc.ru. 2. When analyzing Delphi 6 and Kylix DCU format, the data types of some fields were clarified. In particular, some byte fields become indices, because additional bits of their values were used. I believe, that the fields were indices in all the previous Delphi versions too, but I had not enough information to detect it. So I hope, that the new DCU specification become more precise. But, if somebody will encounter units of previous Delphi versions, which DCU32INT can't parse now, please, send them to me. 3. Some additional tables in the tail of DCU, which were ignored by version 1.0, are processed now. In particular, the program reports line numbers in the disassembled code, if the line numbers information is present. Usage. ------ DCU32INT <Source file name> <Switches> [<Destination file name>] Destination file may contain * to be replaced by the unit name or name and extension. If * is the last char in the name, it will be replaced by <Unit name>.int, else - by <Unit name>. Destination file = "-" => write to stdout. -S<show flag>* - Show flags (-S - show all), default: (+) - on, (-) - off A(-) - show Address table C(-) - don't resolve Constant values D(-) - show Data block d(-) - show dot types F(-) - show Fixups I(+) - show Imported names L(-) - show table of Local variables M(-) - don't resolve class Methods O(-) - show file Offsets T(-) - show Type table U(-) - show Units of imported names V(-) - show auxiliary Values v(-) - show VMT -O<option>* - code generation options, default: (+) - on, (-) - off V(-) - typed constants as variables -I - interface part only -U<paths> - Unit directories -P<paths> - Pascal source directories (just "-P" means: "seek for *.pas in the unit directory"). Without this parameter src lines won't be reported -R<Alias>=<unit>[;<Alias>=<unit>]* - set unit aliases -N<Prefix> - No Name Prefix ("%" - Scope char) -D<Prefix> - Dot Name Prefix ("%" - Scope char) -A<Mode> - disAssembler mode S(+) - simple Sequential (all memory is a sequence of ops) C(-) - control flow Call the program with -? or -h parameters for help on usage. The Scope char symbol will be replaced in the name by "T" for types "C" for constants and so on (see source for details). In general, there are two main ways to run the program: - without the -S switch - to produce the most close to the original Pascal source output without superfluous details; - with the -S switch to see a lot of additional information, which reflects the internal structure of the DCU file, e.g. the values of some fields of unknown purpose (You can try to guess what they mean), the data structures representing the VMT of classes, RTTI of data types or the table of addresses. Of course, You can always select only a subset of additional information using the -S<flags>. Validity. --------- The DCU32INT utility have passed successfully the "parse all .\LIB" test for all the supported by it Delphi and Kylix versions, i.e. it have parsed all units in the <DELPHI LOCATION>\LIB directory with no errors reported. See alllib<N>.bat files for examples of running the DCU32INT to parse all .\LIB. This success doesn't mean, however, that the underlying DCU specification is absolutely correct. So, please, send me your bug reports (see the section "Home page" for details). History. -------- In 1996 I first saw Delphi (1.0 and 2.0). Before that time, in the beginning of 1994 I had a successful experience of reconstructing the structure of TPU files. I was interested in the methods used by Borland to effectively compile Pascal programs (much more effective in the speed of compilation, than C compilers do). The conclusion I have made then was that it is possible to reconstruct an unknown file structure when you have at hand a generator of these files (a compiler for the case of the Pascal units). The structure of 16-bit DCU for Delphi 1.0 is similar (with minor changes) to the structure of TPU files, so I have easily extended the TPU viewer program to include the DCU files. But the structure of 32-bit DCU was completely different, it gave a reason to believe in the rumors that Borlands have bought somebody's else technology to compile 32-bit code, and my first impression was that it would be almost impossible to restore the structure of the 32-bit units. But I haven't had the FlexT system then. Using FlexT it becomes very easy to experiment with the DCU32 format specification. All I need to check the existence and correctness of some data structure is to specify it in FlexT and to parse the test files. No programming of reading and print procedures and recompiling of the parse program is required. So I started from the obvious from a cursory examination of the DCU32 files fact: the file begins with some header and then follows a list of tagged records of different formats, the structure of which depend on the tag. To analyze the structure of the record for some particular tag we can always ask the compiler to ge