Author Topic: Outpost2app.h  (Read 1670 times)

Offline Hooman

  • Administrator
  • Hero Member
  • *****
  • Posts: 4954
Outpost2app.h
« on: September 06, 2007, 04:03:10 PM »
*Begin long [and slightly embelished] story*

I just realized some mistake I made years ago. Way back when we were getting the first working mission SDK built, we ripped the the exports from Outpost2.exe and made a header file for them. I had an automated tool that read all the exports, undecorated them into proper C++, cleaned it up slightly, sorted all the functions alphabetically to group related ones nicely, and then output a big header file. That header file was then further cleaned up by hand, organized a little, and many variable names were added so we could remember what the parameters to functions meant. That original header file was however split into two, one of which became Outpost2DLL.h which was the basis for the SDK, which was then later split into the many smaller header files in the current version.

The other header file was Outpost2App.h. I believe it was initially included with an early version of the SDK, but was left rather unnoticed, and was fairly quickly removed before anyone really started to download it. The main reason that it was split, and eventually removed was that it's contents had nothing to do with creating new levels, which the SDK was primarily concerned with. There were also some stability issues, in that we never really managed to use many of the classes without it crashing. [and maybe we thought it'd be kinda cool to keep this our little secret :P]

Aside from a little initial tinkering, it was mostly forgotten about for a long while. At least until Eddy came to us with a startling realization that Outpost2.exe contained more exports than we had in the SDK. Remembering about the "other" header file, we quickly sent it to him [to shut him up? :P], with the usual "yeah, we knew about it all along". Then after some more unsuccessful thinkering, it was largely forgotten about again. [Well, Maybe Eddy made some use of it, I don't really know, and Hacker does have some stuff for in game menus and such, which is somewhat related, although I don't know how strongly to the header file].

Anyways, I was reminded of this forgotten header file once again. [Largely stemming from McShay's request to know more about DescBlockEx, which lead me to some code that used what I soon found out was a GameStartInfo struct, which is passed around by a few functions by the classes in this other header file.] This time while digging around in some code, and tracking a few virtual function calls with the header file open for reference, a slow realization came to me about why we never got anything really working with those classes before.

When the compiler compiles a class with virtual functions, it adds them to the virtual function table in the order in which they appear. ... slowly remembering back to so many years ago, that header file was sorted alphabetically. The ordering of those functions in the virtual function table is not alphabetic. So when the compiler processed the header file, it's virtual function tables were different from those in Outpost2.exe. Thus any calls from our code to a virtual member function would go to the wrong function [using the wrong ordering from our compile, but the correct table from Outpost2.exe]. It never occured to me that it might matter back then, since the addresses of all those functions was exported by the exe, but as long as they were declared virtual in the class, all function calls had to go through the virtual function table. If the virtual modifier was removed, then it'd probably change the name decoration, and the code wouldn't link right due to missing symbols, but if otherwise corrected, would actually have gone to the correct address. Basically, it's all to do with inheritance, and making sure that any calls on that class, or a derived class, go to the member of the right class in that class hierarchy.


So, long story short, I went through the tables in the exe, and moved the declarations around to match up. Hopefully they're in the right order now. There are however 5 missing virtual functions on TFrame. They were pure virtual, and thus had no functions to export. Hence ripping the exports from the exe didn't pick up on these. I just left a note by that class, and marked where the 5 functions should go. Until someone fills those in, that class shouldn't really be used. [I might get around to it later, or I might just forget about the file for a few more years. :P]


Anyways, here's an updated copy of the "forgotten" header file attached.

[Feel free to add to, or correct the story. It's been many years and I've forgotten many details about the forgotten header while, which may have not been so forgotten to other forgotten, or not so forgotten people.]
 

Offline BlackBox

  • Administrator
  • Hero Member
  • *****
  • Posts: 3093
Outpost2app.h
« Reply #1 on: September 12, 2007, 11:40:52 PM »
As interesting as this might sound to someone, don't get your hopes up (yet). It's really not that usable at the moment. Most of those classes are pretty much unusable or useless on their own (IWnd and IDlgWnd are meant to be derived from, for example, and a lot of functions that are needed to really do much with the windows are not exported by the EXE).

About the only things that I can see as really useful would be the stream related functions in the ResManager, and the *Filter classes. (I do have documentation on the StreamIO object, enough to allow basic use of it for actually reading data, as well as the FilterNode and other objects).

I can't get to that data currently however since it's stored on a server about a 2 and a half hour drive away that isn't connected to the internet.

Furthermore, I think there will be some memory leakage issues if you try to call one of the functions that starts / stops a game in the TApp class. (I remember there being extra code that destroyed / created in game objects that wasn't related to that.. all those functions did was to mainly activate the UI, with the exception of the StartSingleGame and a couple others).

Offline Hooman

  • Administrator
  • Hero Member
  • *****
  • Posts: 4954
Outpost2app.h
« Reply #2 on: September 14, 2007, 07:12:34 PM »
Well, we still need to fill in the data members, so creating or deriving from those classes will still be a problem. I guess I can fill in a little more sometime. You don't really need to do much extra work to get something useful out of them though. You basically just have to provide your own WndProc. Once you do that, you can properly respond to events, and do the right painting.

I've looked at a number of the derived classes in Outpost2.exe. They didn't seem all that special. Things like a status window when connecting (mutiplayer), and simple menu windows like choosing which multiplayer game type. Many of the classes seem to be in OP2Shell.DLL though. I haven't really looked into any of those. But, if OP2Shell.DLL can do it, I don't see why we shouldn't be able to do it reasonably easy once we fill in the missing fields.