Decompiled Format Overview
Posted: Thu Feb 11, 2010 3:23 am
The decompiler currently follows this naming scheme:
filename.class.file_type.ext
The reason I have for not making the file_type token the file-extension is pretty simple: usability. I would rather just have all plain text files saved with a .xml extension so that they can be easily viewed in a text-viewer by default (the data is xml anyways).
So currently I have two file-extensions in use: .xml and .bin.
The current file_type tokens that I use are tag_blocks (for meta), raw_blocks (for raw binary), and string_references (special Unicode file, decompiled from unic tags).
I will be storing no extra information in the decompiled state: filenames will be given by the folder hierarchy, and tag_block files are parsed such that their pointers are converted to local file-offsets, and their raw pointers are converted to a local offset in the matching raw_blocks file (or left as external pointers). Unicode tables are decompiled back into unic tags, with the Unicode data being stored in an xml file.
Every tag_blocks file will have a companion file that will list all SIDs and TIDs, as a new SID and TID table relative to that tag alone. What this means is that if you changed an existing filename in the decompiled map-form the compiler will have no idea that you changed this filename and will probably just null the TID. Whereas SIDs will just be built into a new SID table without problem.
filename.class.file_type.ext
The reason I have for not making the file_type token the file-extension is pretty simple: usability. I would rather just have all plain text files saved with a .xml extension so that they can be easily viewed in a text-viewer by default (the data is xml anyways).
So currently I have two file-extensions in use: .xml and .bin.
The current file_type tokens that I use are tag_blocks (for meta), raw_blocks (for raw binary), and string_references (special Unicode file, decompiled from unic tags).
I will be storing no extra information in the decompiled state: filenames will be given by the folder hierarchy, and tag_block files are parsed such that their pointers are converted to local file-offsets, and their raw pointers are converted to a local offset in the matching raw_blocks file (or left as external pointers). Unicode tables are decompiled back into unic tags, with the Unicode data being stored in an xml file.
Every tag_blocks file will have a companion file that will list all SIDs and TIDs, as a new SID and TID table relative to that tag alone. What this means is that if you changed an existing filename in the decompiled map-form the compiler will have no idea that you changed this filename and will probably just null the TID. Whereas SIDs will just be built into a new SID table without problem.