oh wow nice work, I didn't expect someone with knowledge like you to actually stumble upon this thread at this kind of date
what isn't all that unexpected is how the demo is missing a lot of features, I wonder how much there really is
As far as I can tell, this is probably a late alpha/early beta probably about six months from shipping. Internally, it looks like most of the functionality is there; most of the ship/planes/RV/train meta data is there though the grfcodec failed to pull the vehicle stats, likely due to the offsets just being different so I got garbage in the NRO file.
There are some interesting bits in the code; there is a fair bit of code to initialize and setup networking and serial ports for multiplayer, and it looks like the GUIs exist for creating and placing roads/ship depots/etc. I'm not sure there's any airport type beyond small though, though at least some definition data exists for things like the Boeing 727.
Interesting, there are some references to OS/2 in the code. It wasn't uncommon for developers to use OS/2 even for DOS games because it was possible to run a debugger inline with executable, and it was quite a bit more stable than Windows 3.1 in this role. I've unfortunately run into a bit of a headache though because DOSBox's debugger is annoyingly limited, and the memory map is wonky. Normally, data is basically loaded in a single segment in protected mode, but there appears to be multiple data segments so I can't get cross-references to line up properly.
Internally, it looks like there are two seperate applications which get loaded and unloaded. The first entry point loads TRTITLE.GRF and displays the opening titles, and then a second segment that has all the game data. This could also just be an artifact of linking depending how Chris laid things out in the assembler since hand-written assembler code can throw out most of the rules you get used to when debugging compiled binaries. I was only able to find the loader functions by finding the DPMI interrupts and tracing backwards.
EDIT: Well I slammed into a brick wall. I need a debugger better than the DOSBox monitor which is ... lacking at best in terms of functionality. I *did* manage to get OpenWatcom's debugger to attach to TRANS.EXE, and successfully read and dump memory. Added bonus is OW at least in theory knows about Phar Lap and knows how to interact it. Unfortunately, it looks like that support bitrotted out of OW2; the trap file is present but the debugger shims are missing. I filed a bug upstream, but I'm going to have to get creative if I want to look at this things guts more in-depth. It looks like the stubs are needed even if I ran the debugger on OS/2 which is unfortunate. I might be able to force a "trap to debugger" by hexediting in the int 3 call, but that will have to wait until I get home.