Games are especially notorious for these assumptions and incompatible behaviors, both the ones written by professional software houses back in the 1980s and the ones you might write today.
Second, there are a lot of assumptions that DOS programs make (like, the fact that they are running directly on top of the hardware and can therefore interact with it however they want) that are incompatible with running in emulation on Windows. First and most significantly, 64-bit versions of Windows won't run 16-bit DOS applications at all, so this would only work on 32-bit versions of Windows. There are certain cases where you can run DOS applications under Windows, using the Virtual DOS Machine in a console environment, but there are some very significant limitations. This is why you need the DOSBox emulator: not to emulate so much as to run DOS, which your program then runs on top of. You are almost certainly invoking DOS APIs (via interrupts) and doing other platform-specific things. The part that doesn't work is the part of your program that expects to be running on top of DOS. In fact, they boot up as simply a (very) fast 8086. The new chips are nearly 100% backwards-compatible with the 8086. The problem is not the assembly language as much as it is the run-time environment.Ī modern x86 processor has absolutely no trouble running code written in 8086 assembly language.
0 kommentar(er)
