Forced Exports

[Arklon]

Hey, I actually got this method to work! I've committed the project to the SVN under /LevelsAndMods/trunk/API/ForcedExports-ExportInjectorDLL. I'm getting tired so I'm not going to write a practical thesis about it like I've been doing in a lot of my posts in here, but basically this method works just as if we had manually edited the exports table within Outpost2.exe, only with far less work involved, and without hacking away at the real file - this is all done at runtime. The downside? Well, when working on the project and adding new exported entries, you'll have to find and use the mangled names again. I can't think of any way of using the human-readable versions of the symbol names that doesn't involve really sick hacks as of yet. Also, the way it works right now, it breaks import by ordinal only. It also doesn't have support for dealing with forwarded exports yet. Neither of those problems are an issue for the case of injecting exports in Outpost2.exe, though.

Update: I added support for forwarded exports. Still need to figure out an efficient way of preserving the ordinals from the original exports table.

Update 2: Ordinals from the original exports table are now preserved.

Update 3: Seeing as a .exe file needs to get built in order to generate an import library file, I decided to make it of use. The "official" way to get the symbol name of something is from the assembler listing, which isn't a nice solution. Fortunately this exe contains all the relevant symbol names in its own exports table. So, it is now a simple application that saves all the symbol names (and their undecorated forms) to a .txt file, to make it easier to find these symbols for development. I also rearranged some of the project so that the app will be able to take into account exports that are already being injected by the DLL build when it generates its text file. I feel I made the organization a bit messier with all that, though, but I'm not entirely sure how I'd want to really organize it.
Another thing that would be nice is writing an app that scans the OllyDbg comment file for functions/data and outputs a text file filled with 'DefineExport(<ADDRESS>, "<NAME">);'. Of course, the generated code would be unusable as it is, since you need the symbol name in the name argument, not some arbitrary non-decorated name. But seeing as there are several thousands of things to export, that could help save a good bit of time with development.

[Arklon]

Doing a little bit of work... here's how the unit class hierarchy is looking to be (so far anyway, I need to check again more closely to see if there's any more base classes I missed, and some may need better names, such as Unit::Weapon, which really seems more like "'Gaia' units that interact with and/or are interacted with by player units, excluding disasters"). I extrapolated this info by a combination of looking at the class constructors and seeing which base class constructors were called or which base class vftables were assigned (optimizer inlining base class constructor?), and looking at functions being added/overridden between the different Unit vftables.

Update: There are no "Common" and "Rare" branches of Building::Mine; those have been removed. It's also fairly possibly PrettyArt derives from Unit::GaiaUnit.

I've been trying to figure out the UnitTypeInfo hierarchy as well. It's more of a pain as there aren't many clues you can get from looking at the constructors. The assembly of the constructors looks fairly weird, I'm thinking it could have come from some sort of library. It does, however, look to be a much more simple hierarchy. I'm thinking the trunk and branches look like: UnitTypeInfo, UnitTypeInfo::Vehicle, and UnitTypeInfo::Weapon. All the building leaves, as well as misc. things like starship modules/satellites, consumer goods, rockets, and arachnid 3-packs seem to just derive from UnitTypeInfo. Vehicles derive from UnitTypeInfo::Vehicle, as expected. All weapons, disasters, and beacons/fumaroles/magma vents/wreckage derive from UnitTypeInfo::Weapon.

Update 2: There is a Lab branch from Building, which all the labs and likely MaxObjectType (which previously wasn't on this list) apparently derive from.