LowLevelMahn

no thats nearly impossible

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 :)

Playable DOS version available

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

find latest DOS release here: https://github.com/neuviemeporte/f15se2-re/releases

the f15_se2-*.zip file contains the replacement executables for the DOS game

The airforce needs YOU!

that is the inital post to explain what the link referes to...

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

here is a list of articles to read: https://forum.stunts.hu/index.php?topic=4287.0

the developer 'Wilczek' is posting the progress on his Railroad Tycoon reversing in this Vogons-Thread

the developer Alberto Marnetto is responsible for creating this crazy mod extending the sight of view in Stunts making it look like a different game

Blog: https://marnetto.net/2026/01/27/camel

Youtube: https://www.youtube.com/watch?v=AF3stJfcK8A

Forum-Announcement: https://forum.stunts.hu/index.php?topic=4404.msg100046#msg10...

former SuperSight Blogs:

Part 1: https://marnetto.net/2025/02/20/broderbund-stunts-1.html

Part 2: https://marnetto.net/2025/08/08/broderbund-stunts-2.html

Part 3: https://marnetto.net/2025/08/13/broderbund-stunts-3.html

this Rust demo also uses PTX directly

  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.

not using a union: https://ojdip.net/2013/10/implementing-a-variant-type-in-cpp... because the union can't be extended with variadic template types

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

rustc is written in Rust - for many years, start based on OCaml

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 are so many reasons for that

-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 :)

(found on vogons: https://www.vogons.org/viewtopic.php?p=1331177)

there is a team working on enhancing the original Syndicate Wars port (https://gynvael.coldwind.pl/?id=279) by Unavowed and Gynvael Coldwind

github: https://github.com/swfans/swars youtube: https://www.youtube.com/watch?v=eJOnGRdErpg

correct "16bit segment:offset" reversing is such a huge time consumer - linear 32bit DOS code is more or less easy in comparison

"with almost a decade of experience" isn't a senior at all with or without legacy projects :)

and nothing beats the legacyness of languages before the java/webtech times - and im not even talking about COBOL

sadly, correct reversing is such a huge time consumer - decades are easily reached and there are not that many developers who are passionated enough

its was partially ~40% ported (10 years ago) to C but still only running on DOS

the same guy that created (800% Detail: Tweaking Stunt Island’s 30-year-old 3D Engine): https://marnetto.net/2024/11/20/tweaking-stunt-island

developer Alberto Marnetto create a modification (based on Stunts reversing propject restunts) to increasing the field of view while driving

"near" like never :)

the globe is not a static image - can be rotated with the arrows in the lower left, and it rotates very slowly by itself

Thomas Fach-Pedersen aka madmoose from the "dune reborn" community - know for its early work on the reversing that let to the ScummVM/Blade-Runner port, pushed some of his current Dune1 reversings online

a Rust/WASM based viewer for Dune1 Rooms and a rotateable sandy Globe

Room-Viewer: https://thomas.fach-pedersen.net/dune/room/

Globe: https://thomas.fach-pedersen.net/dune/globe/

all very far from a playable game but having Blade Runner in ScummVM tooked also over a decade of reversing :)

they easily can :)

void test(int& y){}

int main() { int* x = nullptr; test(*x); }

porting over to recent platforms is for most reversing projects the main goal and there are no modern system changes that can harm such an small code base with so few dependecies :) mostly SDL fits all needs for all relevant platforms and i think he will keep DOS compilation ability even when ported to other systems

how?

Spice86 is some sort of tracking emulator like Dosbox giving you the ability to replace original code parts with C# - i don't think that Spice86 can emulate Win16 currently

thats why i love hackernews - always information that is briliant but never stumbled over it

wow 3dica is a cool tutorial - thanks for the link