Confirmed with ykhwong's 14/02/06 build w/ HOTU version.
Also, sound only seems to work with GUS, and not SB16. If you use GUS, the exit error is just "FATAL MIDAS uninitialization failure:". Either way, when reloading the game it freezes at the screen asking you if you want to restore the pre-crash savegame, whether you answer Yes or No.

Apart from all that, the game does seem to work ok.

Edit: Disregard bit about error message difference - seems to depend on something else, maybe the cpu core.

They're using a zero-segment in one of their list operations when
exiting the game, which'll make them test the int3-offset for zero
(which it is in the CVS but not in 0.63).

Their "most advanced artificial intelligence gamesave program ever created" as they call it is not intelligent enough to work with DOSBox correctly. If you end the game by closing DOSBox in any version, you will later get that restore screen without possibility to continue in the game. It can be a problem in case of unexpected PC turn off etc. Is there a way to disable/bypass this autosave feature or make it working with DOSBox?

Yet i don't know if it's a game bug (checks the int3 offset on a real
pc as well but ofs(int3)!=0 there) or if they get the segment wrong
(zero) for some reason.
There's a 1-byte file in the savegame directory, you can use a
text editor to turn the 1 in there into a 0. This is not a practical
solution though 😉

wd wrote:

There's a 1-byte file in the savegame directory, you can use a
text editor to turn the 1 in there into a 0.

Yes, it works. 😀

wd wrote:

This is not a practical solution though 😉

Well, I agree. 😉

Got the same error under msdos as well, they're really using
a zero-segment where they shouldn't (that zero terminates
some table but they don't check for it).
The int3-handler will be moved a bit to work around this odd game bug,
so it should work fine again then.