VOGONS

Common searches


First post, by Dr Elliott

User metadata

I remember how there used to be idiot pseudoprogrammers thinking that using anti-debugging tricks, their own encryptions, anti memory-freezers etc., in games somehow made them "uberk00l"... while all they did was making sure that a few years later newer processors, such as 486 or Pentium, could not run these "protected" executables because of various non-standard, undocumented tricks, procedures and so on - they would now hang or crash or freeze on a new system. Some games like these were for example In Extremis or the installer for Bethesda's Terminator 2029 or Future Shock. They wouldn't run on a Pentium. Surprisingly enough, now that I tried them in Dosbox, the SAME thing happens - they freeze and I have to shut D. down. Do you think it would be possible to get Dosbox to somehow handle such situations, bypass such stupid "protective measures", or whatnot, to make such executables runnable...?

Reply 1 of 4, by ux-3

User metadata
Rank Oldbie
Rank
Oldbie

As I said in another article below, I have build a physical dosbox for my old gems. I was not aware that some games carry such massive protections (against what). While I am not interested in the game, I do wonder if it will run on my physical dosbox. I report back when I know.

I got all my games to run, which was difficult enough, but perhaps there are games, which you mention, that wound NOT run on a P1 period?

Edit: Just checked inextremis on my physical Dosbox. I got to start a new game and fire a weapon, is this a good sign or does the trouble only start later. (There was fm-sound, didn't hear music.)

Reply 2 of 4, by tonyi

User metadata
Rank Newbie
Rank
Newbie

Some of the old stuff could rely on self modifying code in certain ways that tricked the prefetch queue into executing code in the queue rather than what was in ram at the time (this defeats single stepping by debuggers). In the vast majority of cases the prefetch queue manages to catch the mod and execute the altered instruction in ram, but I recall there being a few cases where it could fail and be used for such tricks.

I suspect an emulator that worked at the internal CPU register/queue level would be unusably slow...

Another possibility on 386 targeted code, was reliance on "real big" mode. An undocumented way to trick the CPU into allow "flat" style large memory access while staying in faster real mode. Neat trick, but it didn't keep working on some subsequent CPU's (or even some mutations of the 386)

Can't fix the thing if you don't have the shit. If you don't have the shit, you can't fix the thing.

Reply 3 of 4, by jal

User metadata
Rank Oldbie
Rank
Oldbie
tonyi wrote:

Some of the old stuff could rely on self modifying code in certain ways that tricked the prefetch queue into executing code in the queue rather than what was in ram at the time

That might have been the case, but on a 8086 the prefetch queue is 4 bytes, and there's no cache, so it would have to predate at least that. Don't know about the cache (if any) of a 286 though.

tonyi wrote:

Another possibility on 386 targeted code, was reliance on "real big" mode. An undocumented way to trick the CPU into allow "flat" style large memory access while staying in faster real mode. Neat trick, but it didn't keep working on some subsequent CPU's (or even some mutations of the 386)

Untrue. The flat real mode as it is more commonly know is still possible to accomplish on a modern P4, and afaik this has always been the case on all Intel and AMD's 386 and up. Don't know about Cyrix and the lot.

JAL

Reply 4 of 4, by Guest

User metadata

Hmm, I did manage to run In Extremis now, with 0.61 - it didn't work in 0.60 - but I can't do a thing with it when I get to the menu. The RUN option blinks, but the game doesn't react to any key, mouse movement, or joystick (I do have a real one 😀 - there's just this constantly blinking RUN.