Arrgh, Ghidra keeps creating thunk functions when there are none :/ This code is particularly Ghidra-unfriendly. I feel like I should switch to some old-school x86 disassembler instead of Ghidra T_T
That's it, I give up, yet another "D" press wiped half of the disassembly progress - somehow it just re-flows the program and decides that some of the calls never return, so it's okay to ignore my manually-set "this call returns, you just can't understand how" :/

@nina_kali_nina (For the future) In my limited-yet-diverse experience with ghidra, that behavior is usually because there's a function somewhere much deeper in the call chain that was incorrectly tagged as noreturn by the initial analysis pass and it's "helpfully" re-propagating that flag by re-establishing the flow overrides in the disassembled function. I've learned to not run the "non-returning functions" analyzer on older/embedded code due to that... (There's frequently a lot of "helpers" that don't match the standard ABI, which can confuse that analyzer pretty badly)

It could also help to identify the point where the problematic function does return and set a flow override there to "properly" tell the decompiler "yes, this function really does return to the caller here" even if it really wants to ignore the unset noreturn flag on the function.

@becomethewaifu thanks! This helps a lot :) I'm back to business after one hour of fiddling with settings here and there.
@nina_kali_nina oh fuckin no
@drj thanks to @becomethewaifu everything works now, we're back to business
@nina_kali_nina Probably a stupid question, but have you tried CTRL+Z to undo ?
@Guru_Meditation that'll just make it a background process (ha ha no, it just doesn't work)
@nina_kali_nina i've tried to like Ghidra but you'll pry my old version of IDA out of my cold dead hands
@gloriouscow Yeah :( but the learning curve T_T
@nina_kali_nina i've used objdump with "-D -b binary -mi386 -Maddr16,data16" to poke at x86 assembly stuff, also that old version of IDA that was freely shared at some point for a bios (it's meh)

if you're trying to figure out syscalls, debugging from an x86 emulator might be something with better yields, though i don't have a setup for that (yet)

@evv42 the code is a mighty beast, with over 1MB in overlays. So I keep interesting bits in Ghidra, find them in overlays, find overlays in RAM in Bochs, set breakpoints, and investigate. I've tried Qemu+GDB, it just doesn't cut if. Bochs' debugger is not awesome, but it might be the best thing available for my kind of project.

MAME is an option, but its debugger doesn't show stack frames. Marty PC is interesting, but it doesn't fit on my display.

@nina_kali_nina https://misc.tcp80.org/listing.zip <-- MASM 6.11 compatible syntax disassembly and xrefs of vision.exe and visionat.exe
(from http://toastytech.com/guis/visionzip.zip)

https://misc.tcp80.org/sourcer7.zip <-- Sourcer 7 for DOS
IIRC, it runs correctly but very slowly under dosbox. I just run it in PC-DOS 7 under qemu.

I personally can't imagine it'll have better output than Ghidra, but I never have been good at reverse engineering.
@nina_kali_nina Oh, and I've got Soft-Ice 2.8 for DOS lying around as well for live debugging. https://misc.tcp80.org/sidos-28.zip

Used to be very well regarded.
@be0ba yep, this is what I used for this project before I managed to cobble up a working Bochs install. For some reason VisiOn crashes under SoftIce, I think SoftIce might notn be catching all the required interrupts
@be0ba thanks a lot! I checked the listings, they're about the same as what Ghidra gives, of course. I will continue with Ghidra as it can decompile some of the C code and save me the trouble of unwinding the stack frame
@nina_kali_nina You're quite welcome. Sorry they weren't more useful, but it's hard for 1997 tech to beat a modern decompiler. :P
@nina_kali_nina new tools don't seem to play nice with old code. a lot of expectations seem to be violated by hand optimisations, so breakage is expected.