The closest thing to a current programming language I have used is C++. Has anyone tried to decompile Gruntz.exe as a step toward extending the game engine? If so, are you working in a variant of C in your efforts? If so, you probably have a tool to disassemble Gruntz.exe into your preferred language. My effort to acquire a worthy tool to do the reverse engineering have been less than successful. So I am asking the young buckz for help in pursuing the task of taking Gruntz apart in order to put it back together again ... better. Perhaps GPFLith may be able to help, even if he no longer has access to the original source code.
First of all Gruntz was written in C++ and compiled using Vistual Studio C++ (version 6 or earlier) and many assembly structures are strictly related to VC++ constructs (calling conventions, exceptions, RTTI data, some compiler flags etc.). So there's no really "preferred language". There's only THE programming language and THE IDE. I can't imagine decompiling Gruntz to Delphi source code for example - that would be a legitimate nightmare trying to convert all these structures to a different language.
I'm using Ghidra (for static analysis) + IDA Freeware 7.0 (for debugging). Although Ghidra has a C++ decompiler on its own it still requires lots of user input (defining structures, class hierarchy, exceptions) and the code itself might be heavily unreadable and resembling more low-level C than C++. I've also been heavily exploiting Ghidra's scripting engine which automated at least some of the tasks for me that would be otherwise too cumbersome to complete by hand.
I'm afraid for anyone having no reversing knowledge whatsoever and expecting to find a ready-to-go decompiler getting the job done within a single push of a button ... reversing would quickly turn out to be a major let down.
=-.-= ToMaLlA - General Modder in games with QuaKe 3 and DooM III EnGiNes =-.-= datashenanigans.pl/
Ghidra user here, I was using that for another game made with Visual Studio C++ 6, but I have less experience than Tomalla. I've never used IDA, so I cannot say anything about it.
Ghidra have some problems when it comes to C++-specific structures, and sometimes decompilator output is completely wrong compared to deassembler one, so ability to at least partially read assembly is useful.
As Tomalla said, reverse engineering is a rather slow process, there's no one-button solution for decompilation, it can be speed up a little if you know more about the program you want to decompile (used VS version, if there was a version with debug symbols etc.) and can use/write scripts, but it still requires lots of manual work. Even if you could just pop in .exe and get C++ output, it would look horrible, all function and variable names would be autogenerated and it's up to user to rename FUN_0051ca70() to WinMain(); and sometimes aggressive optimization could change the code significantly, e.g. unwinding the loop into 10 statements or add GOTO here and there. So not only the code would look bad, you still wouldn't know what it does, or how to modify it.
With Ghidra it is possible to make a shared project where multiple people can work on one decompilation project and sync their changes to distribute work, but I've never used this option either.
From the two responses so far, it seems that I will be searching for Ghidra and applying it in test to something like a "Hello World" program in order to see what the output looks like, as opposed to what the output should be. Then it is a matter of applying a brain (mine) which has been out of programming for over twenty years to the task of renaming function names to something closer to what the original programmer would have used. I do not expect the effort will return me to competency, only to give me some idea of what a competent programmer would be capable of doing to expand the game engine into the early 21st century. From what I see in the Gruntz folder among .exe and .dll members, just determining all of the components that would need to be gathered together is a task all by itself.
In the 1990s I tried to port a program from the Amiga to the Intel based PC, but a 22Kb program expanded to over 2Mb ... and I had failed to even get the print (the desired output of the program) function to work. I was accustomed to a call invoking a single copy of the function on the Amiga, while on the PC each call invoked another copy of the function. So I would need to learn a lot more about the linking process. I feel as if after 38 years of programming that I am back to day one.
Pleasant surprise! Both Ghidra and IDA are available in free versions! I have downloaded both, and will begin working with them on Thursday (Sunday for me, today) when I return home from my regular match. Other domestic tasks have me busy Monday through Wednesday, so four days from now is the best I can hope for.