be negative, no problem - the goal is different - we are foremost developers that like the challenge to get the game back into its source state - its interesting to see on an algorithmic level how the devs got it working at that time with all this hardcore constrains (It's like the joy of an archaeologist unearthing an old wooden tool.) - for many developers gaming was the startpoint of interest in software development, and reversing is the gold-class, all your life long expirience needs to be on point to be able to reach such a goal, maybe hard to understand for non-developers - and only a few people on the world are able to do that (even with LLMs) and developers praise these ones :)
its mostly the combined work of AJenbo, neuviemeporte and others - my part is very small, fixing some compilation problems with newer compilers and spreading the news
C source needs to get compiled on every platform reachable - that is a must :)
First step was the full reverse to assembler, second step is to convert the assembler to binary equal compiled C code, all this still on DOS until no assembler code is left, then the porting to Linux,Windows will start
Reversing tends to bring in new bugs and its not easy to find all bugs in such old and reversed code - but so far everything seems to work
try finding open bugs if you got version 451.03 of F-15 around combined with Dosbox or a real DOS
Tools:
IDA Pro 5 (Freeware) is the last Freeware version able to handle DOS executeables (official available by the ScummVM devs https://www.scummvm.org/news/20180331/) - IDA Pro still supports DOS-stuff with latest release - but not the freeware
or Ghidra - but the DOS/16bit support is sometimes lacky - but the decompiler is builtin
During the build, build.rs uses rustc_codegen_nvvm to compile the GPU kernel to PTX.
The resulting PTX is embedded into the CPU binary as static data.
The host code is compiled normally.
the .Net environment strongly depends on the runtime-ability of all .Net Languages - its feel like AOT (ahead-of-time/finaly compiled) but its not, so Rust woulnd fit good
so Spice86 helps in translating realmode 16bit DOS code into similar assembler looking like C# code - which got the exact same semantic and behavior but its pure C# - you can then use the normal Visual Studio debugger/IDE to port or extend the code - that is a huge benefit over beeing trapped using >30 years old DOS debuggers, compilers and IDEs for this already very hard work
its to ease the process of rewriting assembler code into high level code by having a highlevel-assembler-code in between
Spice86 is not intended for Binary exact reversing, like with https://www.scottsmitelli.com/projects/cosmore/ or Duke Nukem, ZZT or F15 Eeagle reversing project - these are using the same compiler and try to replicate every byte of the original exe - to prevent any reversing bugs at first - but this is the hardest form of reversing and takes easily years of hard work
-there is sometimes not a single statical exe (that means all code inside) but overlays(DOS like DLLs) or serveral other ways of loading code at runtime (example for sound/gfx-drivers) - DOS allows technicaly nearly everything so everything is done in games :)
-many game loaders combine code/data parts of a game in memory - for keeping floppy releases smaller
-self modifying code, also hard to disassemble statically with Gidrah/IDA
-good old segment/offset 16bit realmode games - a complete different beast compare to 32bit linear DOS games (Ghidra isn't very good at this, IDA is much much better)
some examples:
the Stunts loader combines several (in itself non valid) files in memory to create a exe (the single files are packed and the result in exe in memory is also packed) - not that easy to static disassemble something like that
Alpha Waves also got an loader and self modifying code that is not easy to reverse statical
its good to have the best disassemblers available and the best (or better dedicated) debuggers around to keep your reversing project shorter then decades :)