[Coco] decode beta release
Wayne Campbell
asa.rand at gmail.com
Fri Feb 24 22:01:37 EST 2012
As some of you may remember, I wrote a program called DCom back in the 90s that was designed to decompile a packed I-Code program and reconstruct the source code from it. Sadly, DCom never performed as it was supposed to. Since rejoining the community, I have been on-again off-again working on a new version of the program.
The new program, unpack, is designed to deal with merged module files. However, I had to work out the problems with decoding one procedure before I could worry about merged files. The result is decode.
decode does not check for validity of the file being decoded, so make sure it is a Basic09 I-Code module before you begin. You can specify a filepath, or a filename if in the current directory. The decode.os9 disk image includes all the files you need for decode to work. Its work files are kept in the DATA directory. The output file will go to the current directory, regardless of where the module being decoded is located. This means you can specify the current commands directory (i.e.. /DD/CMDS/myB09Prog) and (assuming /DD as current data directory) the output file (myB09Prog.B09) will be located in the root directory of /DD.
usage: decode <filespec>
decode with no parameter will report usage help
I have included the source files for decode and its associated modules, so if you want to take a look at how it works, feel free. The DOCS directory has the decode.DOC file, which is a revision history.
I also have finally gotten my ErrorCodes procedure to work properly. I have included the I-Code module, source and doc file for it as well. decode uses it to report errors, but if it is not found, decode will just print out the error number instead.
usage: errorcodes <errnum> [opt]
opt is 0 for brief error message, 1 for extended error message
errorcodes with no opt is the same as with the 0 option
errorcodes with no parameters reports usage help
I would appreciate any help with test running this beta version. The following are the only problems/errors I am encountering at this moment, and which I am working on finding a solution for:
1. a single instance where a record variable and field (rec.field) was supposed to be the first arg of LEFT$, but it was not put there.
2. a single instance where a field variable was misidentified as being a second entry of a different field in the dimension statements. The first was a integer, the second was a string. I know why, but I have not settled on the solution just yet.
3. Type statements and record variables may not always be correctly associated. This occurs when 2 variables are DIM'd to the same TYPE. I have not settled on a solution for this yet.
4. Unused variables and unused fields are not accounted for. They can be, but the TYPE data has been a problem for me to deal with all along, and I have not finished the data memory validation routine that would identify the remaining unused variables in a procedure due to the TYPE data problem.
I cannot stress enough that the dimension statements are still prone to being incorrect, especially where record variables and type statements are involved. What I am looking for from this effort is mistakes in the instruction statements. If you have the original source to a Basic09 module, compare the output of decode with the original source and note differences. Where dimension statements are concerned, the program variables other than records and fields should be correct. If you see something being misidentified in these variables, I would like to know. I will be working at trying to fix the dimension statement problems, but my first effort is to catch and fix all instruction statement errors.
Also, if there is any information you feel a need for that I have not included, please let me know and I will make available what I have to help with answering any questions.
Version 2 of decode will hopefully have all of these issues dealt with, but will have most of them dealt with at any rate.
The decode.os9 disk image can be downloaded here. My thanks go to Aaron for allowing me to use the cococoding site as a download location for my programs, as well as for all the help he has given me over the past few years.
Thanks to everyone who decides to participate. It is my hope to have unpack ready for unveiling at the CoCoFest this year, as I am preparing to attend.
Wayne
More information about the Coco
mailing list