Bump. I'm having this problem too. 🙁 Using latest DOSBox (0.72) on WinXP, but 0.70 behaves the same way. I did a full install of the game and I'm basically 100% sure no files are corrupted, so this is definitely a DOSBox compatibility issue. I hear that on newer PCs, even running the game in real DOS causes a similar problem (system reboots when DOSBox would hang), FWIW.

The game consists of two executables, INTRO and HKY. INTRO runs fine and chains to HKY. HKY will always hang/reboot. If anyone needs a verified clean set of the files for testing purposes, PM me. I really would like to play this damned game again sooner or later without actually buying an old computer!

Strange problems like can sometimes be fixed with a different core=.... setting. Or using LOADFIX before running HKY.EXE. Or a low cycles=.... setting. Or by setting gus=false, sblaster=false, really disable all sound devices.

Thanks for the advice, but none of that helps. However, I did notice that with all sound devices off and changes to the setting for core, the DOSBox console threw out some error messages I hadn't seen before, immediately upon starting HKY.EXE. With the normal and simple cores, I get a "Exit to error: CPU:GRP5:Illegal Call 7". With the dyn core, I get "Exit to error: DynCore: illegal option in dyn_segprefix" most of the time (one time I got something along the lines of "error in opcode 0xFF parameter", but can't get it to happen again). With all of these errors, DOSBox terminates itself in a matter of seconds. Hopefully all this can at least help someone figure out what the problem is and whether this game will ever be playable in DOSBox.

It's a CPU problem - the protection on the hky.exe requires a 486 or earlier because of a prefetch queue trick. I'll see about making a patch for it so that people can play before the next DOSBox is released.

Thanks Peter! Figured it'd be something like that. As I recall, another Bethesda game from the exact same era (The Terminator) wouldn't run either in the previous versions of DOSBox for that exact reason, and was patched for 0.70 (works great since then). Glad to know we'll finally be able to get compatibility with the last remaining Bethesda game out of the way. 🤣

Next version has prefetch queue simulation.

Yes, but for impatient people who don't want to build from source, a patch is necessary.
And yes, Terminator Rampage used the same protection, and did not run by default for the same reason. I suppose that Bethesda paid a lot of money for that protection. Lots of anti-debugging techniques in there.

Impatient people can impatiently wait for the next version.

or get the cvs (build binaries for windows exist).
Anyway which debugger did you to pass through the anti-debugging maze ?

I used debug.exe that comes with DOS. :-)

The patch is now available from my site (pferrie.tripod.com).
The protection also doesn't like that int 2 and int 3 have the same segment in DOSBox. int 2 should have segment 0f000h. So the prefetch queue core in the next DOSBox might not work for this one.

The protection also doesn't like that int 2 and int 3 have the same segment in DOSBox.

I'd have assumed the opposite, as int3 is used by debuggers (so a simple check
for debugger presence would be to check if int3 was redirected).

Yes, I would have thought so, too, but SoftICE for DOS redirects int 2, so maybe that's what they had in mind.
I think that Terminator Rampage had no such restriction (and which would explain how the prefetch core alone works there), which suggests that this is a different version of the protection.