Reply 20 of 35, by Akuma
The most obvious issue is that INT 16 is not "unhooked" before the program terminates; but that would only causes a crash after termination when the program's memory block is released, leaving the INT 16 handler code likely to be overwritten by the next program executed.
So next program hangs because it cannot return ? Or next program hangs because it waits on the former iret ?
A more subtle issue is that INT 21/35 is changing the value of ES, and INT 21/4B uses ES:BX as a pointer to the child program's parameter block. So, you should have a PUSH CS / POP ES or so after the ES value has been stored in memory.
I will look into this 😁
Those are the issues that I notice at a glance, not necessarily the only issues.
BTW, when the subject matter is applicable to DOS programming in general and not just for DOSBox, such topics are best posted in Milliways. 😉
I have no problem if the thread gets moved to where it belongs, but I cant do this myself.
What about using one of those old DOS Game cheater programs that you load up before your game. Then you load the game and press a hotkey sequence and it drops to the game cheater and lets you edit memory values and then go back to the game.
Generally used for changing lives, ammo, etc, but I would think it would work for patching as well.
I think some of them might have let you save profiles.. don't remember though. I haven't used one in years.
I can make it work all sorts of ways, but I wanted to do this in assembly. Thanks though 😁