Messages

I have no idea what version you've got and how they were installed, based on what of your restrictions , with package manager, from source,pre builds from the qt guys ... so im just guessing

There a binary and developer packages, so there are several packages that are named qt* but most of them are not the one stressed needs

these are my current installed qt packages right after doing the VM/stressed build test (http://forum.stunts.hu/index.php?topic=3592.msg76041#msg76041)

linux@linux-virtual-machine:~$ apt list --installed "qt*"
Listing... Done
qt5-default/focal,now 5.12.8+dfsg-0ubuntu1 amd64 [installed]
qt5-gtk-platformtheme/focal,now 5.12.8+dfsg-0ubuntu1 amd64 [installed,automatic]
qt5-qmake-bin/focal,now 5.12.8+dfsg-0ubuntu1 amd64 [installed,automatic]
qt5-qmake/focal,now 5.12.8+dfsg-0ubuntu1 amd64 [installed,automatic]
qtbase5-dev-tools/focal,now 5.12.8+dfsg-0ubuntu1 amd64 [installed,automatic]
qtbase5-dev/focal,now 5.12.8+dfsg-0ubuntu1 amd64 [installed,automatic]
qtchooser/focal,now 66-2build1 amd64 [installed,automatic]
qttranslations5-l10n/focal,focal,now 5.12.8-0ubuntu1 all [installed,automatic]

i've read a post with installing libqt5-opengl-dev could help - but this packages is not part of my installation...

There is no brainstorming needed: we,ve got the full assembler code and the exe header tells the rest of the story - just one allocate all available conventional memory at start thats it, no EMS or XMS - i've wrote an emulator for the game and know all details 100%

just wow

>Since I don't have any problems with memory with the game.exe.

the "memory problems" are a missinterpretion(of you?) and come only from the buggy Microsoft ExePack packing of the original load.exe and
maybe also from the loader in memory combined game exectuable that is also ExePacked - has nothing to do with not enough free memory

1. load.exe gets loaded by DOS, decompress itself in memory using the ExePack code that is attached in the compressed load.exe
2. load.exe combines some files of the stunts folder into the real game code wich itself is ExePacked (same procedure as in 1)
3. real game code starts

ExePack is a Microsoft program to reduce executable sizes like UPX(https://upx.github.io/) today - its just buggy and some versions relies unnecessary
on very old Hardware behavior that is not given with todays still compatible hardware, it happens when the code is loaded too low, loadfix can sometimes prevent that - but its still a official known Microsoft Bug

game.exe is the original pure game executeable
its just step 3 without any unpacking/loading before

>Does game.exe still load in real mode memory? Or secretly in extended?

real mode memory is not a thing - its called conventional (640k) memory

stunts allocates all available conventional memory (no EMS/XMS is ever used) on start and does the
needed allocation while game runs with its own builtin memory manager

Stunts is itself not very memory demanding

but I was hoping it'd be possible to "automatically" convert assembly.

thats the only way it could be done without introducing to many errors
problem with that is: currently not every offset is a symbol - sometimes only ax+0834 or something, it could happen that
the different 32bit code size changes the offsets etc.

the rest is more or less the ideas that are aorund - but its just a spare time thing

Of course, all this work will fail if Stunts does any weird thing like writing on its own code.

as far is i know - no self modifying code in stunts

i've attached the lastest asm-source (that gets you to a nearly 100% identical version of the original exe) so you can have a look how complex/time consuming it could be
the big problem are also 16bit offsets as function parameters that then get combined with some segements to form a real address - hard to follow that automaticly without semantic knowledge

StuntsLegacy for the game - but only if it gets ready
StuntsLegacyEngine - project working name

Strange, stressed is a very clean, simple - minimal dependencies program

How can I find out what needs to be upgraded and do it selectively?  And once I get everything to run, is there a way I can make myself portable binaries?

you can build all libs statical - will get you a huge executable or hope that other system got the needed dependencies, its not that easy under Linux - and the huge mass of little differences between the distros, much more easy under windows

When I tried to make, a file requested by the source was not found so it failed.

Post the exact error message, its always the best you can do

HowTo:

• VM with fresh Ubuntu 20.04 LTS (Minimal Installation)
• sudo apt update
• sudo apt upgrade
• sudo apt install build-essential # for gcc
• sudo apt install mesa-common-dev # for opengl
• sudo apt install qt5-default
• sudo apt install git
• git clone https://github.com/dstien/gameformats.git
• cd gameformats/stunts/stressed
• qmake
• make
• ./src/app/stressed

worked on first try - ~30min

maybe u missed some packages?

Oh, then it's much more advanced than I thought!   One thing is coming to my mind.... What if the code were translated as-is to native assembly, plus C for modern systems?  That is, replacing DOS function calls with their "equivalents" for each system, and so on. This could be done pretty fast and would allow to compile and run the game immediately and then, continue analysing the code and turning assembly into C, but we wouldn't have to wait until it's fully completed to use it.

Stunts is 16 bit segment/offset real mode code that means you can only run in 16bit emulation mode under Windows - without ability to call even 32bit APIs, direct graphics and sound programming is also a big problem - most games that are reversed like that are already 32bit flat-mode code with dos-extender (for example Syndicate Wars) - converting the 2.5MB/~300KLOC 16bit asm to 32bit asm is nearly impossible and can't be done in small steps

i've always thought about converting the 16bit asm to functional equivalent C-code (like https://github.com/xor2003/masm2c does) but its still a huge challenge to come to the same behaving code, xor2003 startet to write a new asm parser/generator right now for stunts - but that will still take some time

another idea was to use DosBox as an environment like Bright-Eyes (https://github.com/Henne/Bright-Eyes, process-description: https://github.com/Henne/Bright-Eyes/issues/49) does intercept the function calling and routes that to real real C functions interacting with the emulated environment - thats why i played with some sort of emulation and changed the simple x86 emulator Fake86 to become a StuntsVM (which is only and direct capable to run stunts - also available here in the Forum) - but its all very time consuming

the current restunts function were ported under DOS with simple debuggers etc. very time consuming etc.

need to try it myself - but im familiar with all the needed tools

The last time I tried to use SDL, I remember there was some function that you had to run and it locked your program there. And then, with another task, you had to interact with the instance that had that blocked function. Maybe that's not the only way of doing it. If I can use SDL unlocked and without any OOP, I might consider it.

most frameworks do this "you-need-to-implement-this-function" beeing able to compensate the platform differences - you will come mostly to the exact same code when not using FreeBasic that wrapps that part of the code aways from you (but still not capable to do all needed needs for development in business - C is more complex - but mainly because of more needs)

And yeah, FreeBasic is not perfect either. It's super transparent, but it's got its shortcomings. I just haven't found any option that I feel more comfortable with. But many times, I think I should try to use GCC more often because it's a lot more broadly used and understood. And I'd like it to have some graphics system that were standard and simple, because SDL is too big a thing for simple programs.

you are just not used to other languages and never in a year long situation that third parties are a must - thats it

Well, yes, if you have a text file loading routine that's aware of different line endings, it will work, but most programs don't have that. This means that you have to make a binary parsing routine for text files if you want to make sure it'll support the files. For example, FreeBasic will write text files with different line endings depending on the platform, but when reading, it will assume the line ending for your OS, so if you're passed a file from another platform, it will not read it properly. This may have changed recently, but I don' t know, so I don't run the risk. Therefore, I create my own binary routines to read text files when I make multi-platform programs. Being able to ignore line endings makes everything pretty much simpler.

i work multiplatform on daily basis and never real got problems with that - but maybe im just pampered with enough helper code

Hey, I've been trying to build stressed from source and always have problems. Did you build it for GNU?  My problem is that it requires qmake and when I try to install Qt development, it turns out it's no simple task and I get lost. How did you get this done?  Or does your GNU distribution already have it installed?

its was my first time i build stressed at all, using VS2019 and Qt 5.15 (currently latest) under Win7/x64 - that needed changes to get it working - i think dstien uses the windows ports of gnu tools like mingw or something

i've installed VS2019 community (want to try the new compiler for fun), installed Qt 5.15 using the Qt maintainance tool (no interest in building Qt myself for hours), git clone the source, runned qmake in the folder, then nmake (fix some problems: https://github.com/dstien/gameformats/pull/1) all in all and around 20min later i was able to use a freshly build stressed

i think it works out of the box under linux (because its dstien default environement) - just install qt and build tools, git clone source, qmake - i think its stright forward - but never tested it

[About C/C++]

About C/C++
I don't like C++, but I do love C in many aspects. In general, I think OOP is a mistake. Many programmers, much more experienced than I agree with me on that.

OOP can be evil - a well known (in business) aspect of C++

But about C, there are only a few reasons why I prefer FreeBasic. Namely:

1 - C does not support graphics. You have to include a 3rd party library
2 - I dislike the concept of having to include a header file to be able to use a function that's already part of the language
3 - Different compilers have slightly different rules, so the code is not 100% transparent between platforms
4 - I don't like the way most C programmers code in C, like using dedicated types when a standard type could be used

my background is 30 years in C/C++/Scripting/Asm..., Multiplatform delevopment (Windows,Linux,Embedded/VxWorks,...), Backend/2D/partialy 3D/Reverse Engineering and Project managment in 500k-2Mio Lines of code projects, with 5-30 Team members, working with +10-20 third parties, using different make tools and different development environments, using several different compilers

i understand your 4 statements (deep in my heart), but none of them had any relevants in my daily business - because you can't have always the best solution integrated - the market is too fast moving, too feature demanding - that can't be integrated into a single language - that is the reason
the world outside your lone-wolf-styled isn't that evil - third parties are a need and will be forever - and they mostly do not complicate projects - its just a part of the whole and i've never got problems with most of the third parties, build Qt or some compilers yourself or look at the 30GBs!!! of C/C++ Libs of the Amazon AWS and you will see that your concerns are just 0,00067% of my problems - the third parties are a thing at starting the project but becoming irrelevant if it reaches the multi-thousand lines of code stage

most C/C++ compilers are nowerdays on par - the difference are much much smaller then 5 years before, SDL is a pure C style api and useable per DOS-Extender under DOS

[First:]

It'd be great if that were fully solved and we were all just using the simplified version. So that's the idea behind Restunts, ha, ha.

Restunts is splitted in three parts:

First: the delevopment of tools that remove cracking or any dynamic loading to ease it for reengineering tools: DONE around 2009: so working for the last 11 years
--> that is the game.exe i attached here for Daniel3D

Second: Reverse the game to assembler that assembles to the very same (100%) original exe: DONE around late 2009: so also for the last 11 years
--> that was the first restunts.exe that is sometimes attached in forum post around the "Reverse Engineering" Topic

Third: Porting function by function to C code and link that to the remaining assembler code (producing the restunts.exe): the creation/function overloading is fully scripted and working for the last 11 years - but the function porting (~800 Functions, 2.5MB of assembler) is not easy an takes much much time - maybe 50-60% done in 2009-2012... i think
--> that are restunts.exe that is are attached in following forum post around the "Reverse Engineering" Topic
--> also the rpldump tool is based on that code

there are no technical obstacles - just much much of manual asm to c porting work and much much reverse engineering understanding of the asm code
everything is public available, buildable from source and nearly working right out of the box

I've built stressed.exe from source and extracted some car models
The models seem to have holes, is that a problem - i thought that models should be closed to ease rendering?