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.
You're not really reverse engineering if you have the code and you're just trying to understand it. Sounds more like you're just doing "maintenance", but that aside.
Handling a legacy project involves lots of reading the code, working out what it is doing, making notes, and renaming stuff, until you can separate out the parts, be that UI/menu's, animation, AI, or whatever it is the game does.
For reverse engineering 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 because you know where in the game that is, you can single step through the code and see how the code is jumping around. You might notice some sub-function updating an animation, and you can name it that, and then find where that is called to get a 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.