I have an application written in QuickBasic (a game). I own the rights to it, but didn't write the original code. I have the source code in front of me, but I'm banging my head a bit in trying to make sense of it all. Are there any ways to make reverse engineer easier? Right now I'm using FbEdit and just trying to pull the application apart into its various component parts.
-
1I hope it's not one of **MY** games. :-) While they were written in the early 1990's, and I *know* I'm a better programmer now... I would hope to think that it wasn't that bad. – Andy Finkenstadt Apr 23 '11 at 03:12
1 Answers
Your not really reverse-engineering if you have the code and your just trying to understand it. Sounds more like your just doing "maintenance", but that aside.
Handling a legacy project involves lots of reading the code, working out what it doing, making notes, and renaming stuff, until you can separate out the parts, be that UI/menu's, animation, AI, or what ever it is the game does.
For reverse engineer dos games (in assembly) I tend to:
Find area's of the code that call graphics interrupts, and start naming those graphics_N, and the same for file handling, or sound, etc. Then you may notice where text/menu's are, and you know where in game that is, so you can single step though the code and see the how the code is jumping around. You might notice some sub-functions updates an animation, and you can name it that, and then find where that's called else were to get better understanding of how and where it's used.
With access to the code, I'd be shocked if the variables, functions and structures had meaningless names. But QB was easier with small names...
I've not used FBEdit, but Visual Studio does an ok job of reading QB code (it thinks it's VB6/VB.Net) but from there you can rewrite it pretty quickly into C#. I've done this for some of my older QB code. You just need to write some helper functions that do classic QB functions, until you remove those basic abstractions.

- 22,906
- 3
- 32
- 45