LowLevelMahn

There is a discord chat (by the author) for technical discussion: https://discord.com/channels/819897993624682516/115556447082...

IDA Pro disassembler fully supports 16Bit DOS executables (they only removed the support from the recent free versions - thats why most using IDA Pro Free 5.0) but Hexrays the decompiler does sadly not support 16bit code (intentionaly) but i think the Hexrays guys could do wonders here (in comparison what Ghidra is able to do)

Spice86 is currently not a real decompiler - but its more and more becoming one

im not the author of these blogs but love to read his tales of reconstructing the C code part by part using IDA/Ghidra and some of his own tools - maybe others are interested in reading too :)

read from bottom up

someone gets it build and running

https://www.youtube.com/watch?v=gqXTzlDZmhU

see comments on youtube

are there any files in the source release that can also be found the in the CD release - are they 100% equal or do we maybe got sources of a pre 1.0 or post 1.0 version?

sorry this is Bens Branch: https://github.com/benstone/Microsoft-3D-Movie-Maker/commits...

Ben Stone is also working on it - maybe join forces :)

https://github.com/benstone/Microsoft-3D-Movie-Maker

there are a few that started to port: https://github.com/microsoft/Microsoft-3D-Movie-Maker/networ...

he should just use the original system - porting to newer system always happen AFTER getting it to build on the original platform

builds for me under fresh XP with VC++ 2.0 until some globutil.obj file could not be build by nmake

maybe a step by step upgrade from 2.x->4.x->5.x->6.x needed

there are subtile changes between the very early studio versions but when reaching VS2005/2008 everything is fine for upgrade

im also shocked :)

i would use a real Win95,98,XP in virtualization, there could be many micro flaws using Wine with this old stuff :)

Visual C++ 2.x can be downloaded here: https://winworldpc.com/product/visual-c/2x

hope they will every release the good old Basic Compiler bascom/basrun stuff

i've finished my project: alpha_waves_loader

a executable extractor and starter for the DOS game Alpha Waves

about the game:

Moby: https://www.mobygames.com/game/dos/continuum

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

my project:

github: https://github.com/LowLevelMahn/alpha_waves_loader

release of the tools: https://github.com/LowLevelMahn/alpha_waves_l … g/Release-0.0.3 (the zip file)

benefits:

-for gamers: near to null (the game runs flawless in dosbox)

-for developers: a nice technical journey (see github history) for developers about reversing a dos game loader (disassembling, analysis, porting, etc.)

-for reversers: the game executables now getting uncompressed and the starting of the game is well documented

- its the perfect start if one ever wanted to reverse engineer the game code itself

if you want to try:

1. download: https://github.com/LowLevelMahn/alpha_waves_l … lease-0.0.3.zip

2. extract the (32bit windows) extractor.exe and (16bit dos) starter.exe into the Alpha Waves gaming folder

3. run extract.exe with the path to progs.cc1 as first parameter "extractor.exe c:\games\alpha"

4. run starter.exe under real DOS/32bit Windows or Dosbox with "starter.exe vga adlib"

refresh your childhood memories

fixed ONLY the compilation (still crashes) for gcc 11.2.0 under Ubnutu 21.10 https://filetransfer.io/data-package/Xp1NUg99#link (that should still build/run on your debian 3)

there is a string struct with this inner char s is super-evil

in kernel.h

    /\* all strings on the stack will have this format. */
    typedef struct {
     unsigned int l; /* length of string */
     char s;  /* string itself \*/ 
            // the rest of the string data
    } string;

string get allocated by malloc(sizeof(string)+stringlen+1) and member char s is then used as the first char + the rest chars from the attached memory

the memory managment is overall a little dirty and i think it will take some time for a experienced C developer to get that clean and running with todays compiler/checks etc.

how far can you go up from Debian 3, build the code and it runs fine?

Debian 3, 3.1, 4, 5?

  In general, long compilation times are mostly attributed by 
  the complexity of things (algorithms) that compilers are 
  trying to do for you in order to produce machine code and 
  not because there's a lack of standardized build system (a 
  bad idea) nor because of existence of headers.

that is not true - most of the project i worked for suffered from header parsing a lot - sometimes more then 50%, in 100k-1MioK lines of code projects many C++ developer tend to think that the code generation is the time consuming part but that is less true - you will see if you start benchmarking the compilation with todays tools available in Clang and VS2019+

Reverse engineered and C ported MT15.DRV (MT32-Sound-Driver) of the 1990 DOS game Stunts (https://www.mobygames.com/game/stunts) 1.0 and 1.1 in one source

Why:

Stunts 1.0 MT15.DRV seems to sound better than the 1.1 version (some strange slowdowns happens with 1.1) i want to understand what the differences are and how to port that stuff to C

Features:

Assembler source can be rebuild to 100% binary exact version of the original game drivers

Assembler can be partially mixed with C ported functions or all functions can be replaced by C code

It was a fun project with near to non relevance for anyone :)