Restunts repository - Git mirror

[Daniel3D]

maybe its the debug information thats get added to the executable

As far a can tell that is the case.
The header is different, then the game file and then a lot of data that seems to be the original game file's (all of the them) and some text about included programs and makefile information.

How do I create a clean executable?

[llm]

I saw referenc to turboC. i assume that refers to Borland Turbo C.
and Tasm and BCC, (bcc is also borland i think) but that is as far as my info goes.

Borland (Turbo) C is the Development System from Borland (Borland in Product names sometimes refer to the Professional Version (with Lib sources etc) and Turbo in name refer to some sort of Semi-Professional)

Tasm ist the Turbo Assembler from Borland

and BCC.EXE is the Borland C Commandline compiler, BC.EXE is the Borland IDE

Future ideas: (if i remember correct)
-the TASM is still the 16bit version - that could be change to the 32bit TASMX (so no dosbox need) or its maybe possible to switch to UASM x64 or Microsoft MASM
-for the C part i would also like to switch to a more recent Compiler version - but it woul be great to have source debugging support

the Problem is: the tools are very old and there were several competing debugger standards around that time - so Microsoft ist using CodeView, the Borland tools got its own format, i think Watcom also uses CodeView

it would be great to have source-level debugging support for asm (and C) source - at best not in a 80x25 Textmode interface

but the damn Assembler code is 16bit Segment/Offset x86 code - so it can't be just translated to 32bit systems even we get rid of the hardware access

it would have been very easy if it was originaly developed for 32bit systems - like many other DOS games - then we could only replace the hardware access stuff and it would then run on windows/linux and we could have used todays development tools - but its just way too old

i still have not found the perfect environment for working on the code - and not suffering of 16bit area textmode debugger systems

my hope is that the Open Watcom v2 Project could be of help here - the github project is very vibrant - issues getting resolved very fast - but
for that the asm and C code needs to get ported (a little) to the Watcom environment

another big hope is the https://github.com/xor2003/masm2c project which could convert the asm source to C like source that could work on any 32bit/64bit system
- the conversions produces C code that behaves like the original - so one is able to just debug the "original" assembler code in a recent IDE - that eases porting/fixed adding code a lot - we can't get Stunts ported to 32/64Bit Windows/Linux without the C translation phase (using this tools or manual)

but all these steps are only doable by a experienced developer with time :/

[Daniel3D]

That would be make reengineering a lot easier indeed.

But for the time being, I would like to understand the setup as it is and learn to work with it.
I'm not doing very well at the moment. I followed the instructions and that seems to work. The errors I got earlier I could understand and troubleshoot.
Now I have a compiled and working executable without errors that is way to big. It seems to contain debug data, but I haven't the foggiest idea how to fix it 

How can i create a game executable like game.exe with asmorig?

-------
I am using the Restunts repository (local copy) to learn, test and modify the game code with the goal to make small changes (like described in small steps)
This is not aimed at reengineering. Is it wise to continue this in a new repository so they don't get mixed?

[llm]

That would be make reengineering a lot easier indeed.

even for the changes you want to make - assembler is a beast, even beastier without able to follow it in source (dosbox debugger is ok but not great for that)

But for the time being, I would like to understand the setup as it is and learn to work with it.
I'm not doing very well at the moment. I followed the instructions and that seems to work. The errors I got earlier I could understand and troubleshoot.
Now I have a compiled and working executable without errors that is way to big. It seems to contain debug data, but I haven't the foggiest idea how to fix it 

How can i create a game executable like game.exe with asmorig?

can't help currently - at least 10 years ago i did that

I am using the Restunts repository (local copy) to learn, test and modify the game code with the goal to make small changes (like described in small steps)
This is not aimed at reengineering. Is it wise to continue this in a new repository so they don't get mixed?

its a git repo - just add a local branch and commit to this - won't mixup with the gitlab repo - because you won't push it - and even if that happens it is seperated from the master using a branch (btw: GitExtensions or GitAHead are good client for Windows)

[Daniel3D]

its a git repo - just add a local branch and commit to this - won't mixup with the gitlab repo - because you won't push it - and even if that happens it is seperated from the master using a branch (btw: GitExtensions or GitAHead are good client for Windows)

That is true.
But then I will only add relevant or promising stuff to the branch. (I'm afraid it will explode with useless data otherwise)

For research purposes, I also want [try] to disassemble Stunts 1.0 as suggested and the PC-98 version.
To compare certain parts, like grip and steering(left corner bias) in 1.0 and the menu structure and replay saving in the PC-98 version.

No idea yet what I will understand of it. Or if it is doable at all. I'll document this in a separate topic.

[llm]

But then I will only add relevant or promising stuff to the branch. (I'm afraid it will explode with useless data otherwise)

you create as much branches as neeed - you can't harm anyone or anything - and you are not able to push that stuff out-of-the box to gitlab (you need write access for that) - there is no need to commit only relevant or promissing stuff - just create two braches: wild_ideas_stuff and the_good_ones

For research purposes, I also want [try] to disassemble Stunts 1.0 as suggested and the PC-98 version.

you won't get far if it also uses a load.exe - the parts that gets combined in memory using a different packing as 1.1 (according to dstien)
so the 1.1 way of just using the exe_combiner will not work - unclear if its is only the missing unpacker and the tool could then work

there is no game-code to reverse if you not unpack/exe_combine the code fragments - you will only see the load.exe code
(but mayber load.exe of 1.1 is compatible with 1.0? - also a interresting test)

[Daniel3D]

there is no game-code to reverse if you not unpack/exe_combine the code fragments - you will only see the load.exe code
(but mayber load.exe of 1.1 is compatible with 1.0? - also a interresting test)

In that case I'll start that.
And if it doesn't work with disassembly of load.exe 1.0, 1.1 and the one from 4D boxing.
Who knows.

[Add]
Maybe the differences in the load.exe programs can give info to get it to work on stunts 1.0 and patch the exe combiner

[llm]

there is no game-code to reverse if you not unpack/exe_combine the code fragments - you will only see the load.exe code
(but mayber load.exe of 1.1 is compatible with 1.0? - also a interresting test)

In that case I'll start that.
And if it doesn't work with disassembly of load.exe 1.0, 1.1 and the one from 4D boxing.
Who knows.

you don't need a disassembly of load.exe just the exe itself

[llm]

just to make it clear: the exe_combiner tool was developed for one reason: for beeing able to disassemble the game code - its impossible without (no disassembler can disassemble runtime loaded code)

[Daniel3D]

ehm, that kind of makes sense.

(I may be completely wrong here)..I thought..
Stunts.com - reads setup.dat and starts load exe with the instruction of the right graphics and sound.
Load.exe contains the game code and combines it with the graphics files. (and sound setup parameters)

Or is the graphical part of the game written and translated to the different graphics modes and stored separately, and they need to be merged to one to make a coherent piece of code?

In simple terms (as i understand). If game code is G and graphics is V (visuals)
I thought it was like  GGGGGGVVVVV
But now it think its build more like GGVGGVGVGVGG 

Like I said many times, I know very little about this stuff. But I want to understand.

[llm]

Load.exe contains the game code and combines it with the graphics files. (and sound setup parameters)

load.exe does not contain any game, graphics or sound code - its only the runtime-combiner which create the full game exe in memory (which then gets just execute like every other ordinary executable under dos) -> at this point the game exe start what directly results in a exepack uncompressed of the game further in memory and then the real game code takes over and starts to load the sound drivers given as command line parameter

you will not find any code of load.exe in skimcga.exe and the others full-blown-game-executables

[Daniel3D]

I'll reread the bypassing load.exe topic. That probably will make more sense now.

About the pc-98 version. That was not written for DOS. But doesn't use load.exe either.
So I hope it can still be disassembled into ASM.
(But maybe I am saying something stupid again  )
The game engine code should still be similar in regard to menu's right?

[dreadnaut]

But then I will only add relevant or promising stuff to the branch. (I'm afraid it will explode with useless data otherwise)

Remember that any investigation notes are useful, even those about dead ends! Documentation helps going in the right direction, but also avoiding the same mistakes.

If you think having a separate fork is a chore, I could add you to the GitHub repository, and you can push extra branches directly there.

[Daniel3D]

If you think having a separate fork is a chore,

I honestly don't know how to do such thing

I could add you to the GitHub repository, and you can push extra branches directly there.

I'd be honoured.
Especially because half the time I barely know what I'm doing and the other half I talk nonsense.

[Daniel3D]

just to make it clear: the exe_combiner tool was developed for one reason: for beeing able to disassemble the game code - its impossible without (no disassembler can disassemble runtime loaded code)

Lightbulb
For game.exe and the separate executables for the new mod 1.0.
Did you just use execombiner to create those?