Restunts repository - Git mirror

[llm]

some notes:

Build-System:

the complexity of the build system is a tribute to the 16Bit/dosbox/win/linux base and testability (you will always inter-test different version builds
to check if the C port behaves identical and using makefiles makes it not super easy for starters but makes it a fully automatic process
to build all the variants), there are even pure C or SDL based builds possible - to manage that all with some batch-files or manually is not a good idea
- so just believe this all had its reasons, and makefiles are your daily business if working as a software developer with C/C++... code

IDA-DB/Scritps:

for users that own an IDA License analysing in IDA and using the scripts and functions lurking around are of big help - but its completely
unclear for non-IDA users why it is that good

the asm code is still not 100% analysed, it assembles but its not fully described - adding notes to the IDA database will automaticly
extend other parts of the code if IDA is able to detect dependencies - that is totaly missing when not using IDA, a C port on this level is nearly
impractiable reachable without having such a tool

for example: the porting overview html and the functions replace with Ported C code in the asm code is completely done on the fly using a IDA script - hard to
replace with something else - is just a huge recurrung process and also the making diassemblery build out of the box with TASM is done using IDA scripts - or
else these 2MB of asm would just spit out hundreds of errors

so the former life cycle was:

1. Analyse/Annotate in IDA
2. Run Scripts
3. Build
4. Port stuff to C or check behavior in Debugger to understand der Asm-Code better
5. back to 1.

that cycle is dead not using IDA - its ok, but not the best

so: there is much to see/understand in this repo - and its easy to not see what helps alot

Debug-Info:

Code Select Expand

ASM = tasmbox /m2 /s /zi

call tlinkbox /s /P- /v /js:\tools\lib\ @restunts.lnk

the /v parameter of tlink.exe is the counter-part to TASMs /zi - both are needed to get debug info

and please ALL: try Turbo Debugger - its way more easy then Dosbox Debugger etc.
don't throw that stuff away - its needed for easier development

try to add a DEBUG flag or something to have a DEBUG or RELEASE build - same like the /DTARGET=original feature

@Daniel3D
you need to stop calling it "Bits", ASAP - its "Bytes" - there is no need to go the Bit-Level (1 Byte = 8 Bits) for explain findings

@Cas

Like Daniël, I managed to compile all OBJ files out of the ASM files in the asmorig directory; however, I'm not certain on the best way to link this. I am trying to do the whole thing inside a single DOSBox, like I would do it in pure DOS, since outside, I have a GNU/Linux OS.

you need to replace the tasmbox.bat and tlinkbox.bat files with direct calls to these tools (the batch files are only creating a dosbox-config on the fly, run the dos executable with the give parameter - thats it

speed and platforms is another reason for me wanting to switch to newer (or multi-platform) assembler/linkers

but the automatic IDA output needs TASM/MASM style and the linking for some of the builds are a little obscure (overwriting standard libs etc.) so not every normal tool can do it - best would be UASM or WASM (both Linux/Win x64) and WLINK (also Win/Linux,x64)- nasm would be great but the TASM/MASM like source is completely incompatible, but it will also currently not build with UASM/WASM or MASM due to minor syntax differences

the only real options are: using the current tools - to also get Turbo Debugger compatiblity or later use Open Watcom v2 to build on Win/Linux and use the CodeView debugger under DOS, or else your sitting in front of 2MB ~230.000lines of code and can't even set a breakpoint or watch a variable

So is there no entry point in any of the ASM files in asmorig?  In other words, can I not just link from the ASM and get a running executable?  I understand from this thread that the resulting binary, if I did that, would not work because it would still be needing to be combined with the graphics. Am I right?

no, restunts is the reversed version of the complete, combined, unpacked MCGA game exe - to have that statical game exe for disassembling was the first big part of the restunts project

there is another link script
due to the fact that the asm orig stuff is differently linked then the C+asm restunts (the complete c-standard library code in asm is then ignored and linked with the original Microsoft C 1.5 libs)

[Daniel3D]

@Daniel3D
you need to stop calling it "Bits", ASAP - its "Bytes" - there is no need to go the Bit-Level (1 Byte = 8 Bits) for explain findings

Haha, I wasn't sure if I was looking at bit or byte level. That was pure sleep deprivation because it it was bit level I would have seen only 1or 0.   
I'll edit the post.

[Daniel3D]

try to add a DEBUG flag or something to have a DEBUG or RELEASE build - same like the /DTARGET=original feature

I wanted to know how to make without debug info.
To know if it works.
When we change something full debugging is very useful. Just trying to learn as much as possible.

[llm]

and i would also replace the bin dosbox.exe with a recent dosbox-staging - it seems faster for file operations

sadly tasm32 is just the 32bit version of 16bit tasm with same feature-set, but tlink32 can only produce 32bit exes, the 16bit tlink.exe also dos executables :/
and you need both from borland or else there will be no turbo debugger compatible debug info

its a mess that all the tools of that types only support their very own debuggers

[Daniel3D]

Well, I use tasm32 and that saves a lot of time.
Tlink is only one DOSBox execute (and not over 40 time's opening and closing DOSBox like tasmbox does)
So, I'm content with the setup.

[llm]

Well, I use tasm32 and that saves a lot of time.
Tlink is only one DOSBox execute (and not over 40 time's opening and closing DOSBox like tasmbox does)
So, I'm content with the setup.

Sounds good

@Cas

You can also use tasm32 from within dosbox for speedup but it think there is a 32RTM.exe missing for doing that in the bin folder, this is not needed if tasm32 gets directly called from win 32/64 bit, i,ve got this file somewhere in my borland compiler installs, you should also use recent dosbox staging build for better filesystem speed

@All

Another idea is to use a small 32bit (not 64 bit) virtual machine windows, like XP or Win7 32bit, this way it should be possible to directly call the 16bit tlink and even the turbo debugger could work without using dosbox

[Daniel3D]

Advising CAS to use Windows...  .   
But doing it all within DOSBox sounds reasonable.

Any ideas about using bare metal DOS or freeDOS?

I tried calling tlink from within DOS and using make but both didn't seem to work that way.

[llm]

Advising CAS to use Windows...  .   
But doing it all within DOSBox sounds reasonable.

Any ideas about using bare metal DOS or freeDOS?

I tried calling tlink from within DOS and using make but both didn't seem to work that way.

Some of the tools are 16bit, like tlink and tasm that should work under DOS,FreeDos
Tasm32 could work but 32rtm.exe is missing, make.exe also needs 32rtm.exe
its a wild mixture of old and semi new tools that are needed

The only question for projects like these are "what is the most productive combination that fullfill the technical needs" because reversing or writing 16bit asm and debugging is already hard enough

And it makes no sense for nostalgic reasons to use these tools under dos, the original devlopment mostly used microsoft c 5.1, at a time when borland was the evil competitor

[Daniel3D]

I am pretty sure Stunts was compiled with Microsoft. Scrolling through the binary I read "MS run-time library - copyright (C) 1988, Microsoft corp"

[llm]

I am pretty sure Stunts was compiled with Microsoft. Scrolling through the binary I read "MS run-time library - copyright (C) 1988, Microsoft corp"

No need to be just sure - it is a prooved fact because all the old microsoft compilers leave a signature in the exe, stunts got the signature of microsoft c 5.1, and the memory model is "small" because the standard c library that is linked is the one for the small memory model (binary exact)
that is also the reason for microsoft c 5.1 libs and includes in the tools folder, the c based port gets linked to this c lib, that removes the burdens to port any of the standard lib functions

[Cas]

Thanks. I'll be trying to get it to link and see what works faster here. And yeah, ha, ha... whenever I can avoid using Windows, I do, even if it takes twice as long. On the other hand, I do agree completely that Borland and MS were very much the same kind back then. I tend to see the binary code that comes with Stunts as one thing, like, we know it works that way, so try to change as little as possible, but it's not because of love or hate, or nostalgia, at all. If Stunts were to be made from scratch now, I would of course favour free software platforms instead.

Some modding of Stunts surely is pretty feasible. Other things would be super hard without truly understanding most of the code in it. If we have to comprehensively analyse everything, like getting it all completely to C, that would take years. But well, many things can be done without that, so I'll try to find those.

[Daniel3D]

O I love cherry picking.

I've been reading the make files. Looks kinda like a batch file. Could you do the same thing with a batch file in DOS?

[llm]

O I love cherry picking.

I've been reading the make files. Looks kinda like a batch file. Could you do the same thing with a batch file in DOS?

More or less yes, but makefiles are the standard for this at least for the last 30 years
they are some sort of declarative description with some batching features
today i would use cmake or meson for easily being multi compiler/platform able

The makefile just calls tasm to assemble the segment files all with the same parameter but different files, switching some directories and then calling tlink, doable with DOS batch, but one prevent to retype the parameters etc. 40 times or so, these param can change over development and the makefile keeps it simple, nowerdays make variants even better

[Daniel3D]

Make works fine for me.
But for CAS t doesn't. But he can easily write a batch version of it and modify if needed. (Assumption)
Tasm and tlink work in dos so the whole thing be done in DOS.

[llm]

Make works fine for me.
But for CAS t doesn't. But he can easily write a batch version of it and modify if needed. (Assumption)
Tasm and tlink work in dos so the whole thing be done in DOS.

make can run in DOS, what makes you think it doesn't, there is only 32RTM.exe missing i think, this borland make was part of the compiler suite for ages, it must work under dos, maybe not this version but at least the 16bit version