Posted September 23, 2015
I have some programming experience, including tinkering with DOSBox and a number of computer game source ports, and I'm curious about SHLINK from this perspective. I did look at the source code, unfortunately its low level C and assembly is a bit beyond me.
The page claims this:
I started to code a loader to run SS natively under win32. It basically acts as some kind of layer between SS and Win32, in order to fool SS into thinking it's running under DOS. There is no emulation, game runs full speed.
This sounds like a clumsy way of explaining what an emulator is to a non-technical audience. But the page expressly says that it isn't an emulator. This explanation isn't satisfying to me. Making a DOS executable work on Windows is no trivial task that you can bypass by lying to the program about the OS version (this is how Windows Compatibility Mode often works, BTW). Memory management is totally different, hardware calls are direct, and the DOS API has zero compatibility with any 32-bit Windows API. This is why DOSBox rocks so much, and why we'd be nowhere without it.
I only comprehend two ways of getting a 16-bit DOS game to work on Windows; you can recode the engine and compile it to native 32-bit Windows assembly, or you can simulate a DOS environment, including legacy hardware like the Sound Blaster 16. The former approach is nearly impossible to do accurately without having the original source code, and the source for SHLINK doesn't look like it's doing that at all. The latter approach is, in my mind, emulation. I know there's some debate over what counts as emulation and what counts as virtualization, but I don't see a clear line between them, so I tend to group them all under 'emulation' if there's any debate.
The page claims this:
I started to code a loader to run SS natively under win32. It basically acts as some kind of layer between SS and Win32, in order to fool SS into thinking it's running under DOS. There is no emulation, game runs full speed.
This sounds like a clumsy way of explaining what an emulator is to a non-technical audience. But the page expressly says that it isn't an emulator. This explanation isn't satisfying to me. Making a DOS executable work on Windows is no trivial task that you can bypass by lying to the program about the OS version (this is how Windows Compatibility Mode often works, BTW). Memory management is totally different, hardware calls are direct, and the DOS API has zero compatibility with any 32-bit Windows API. This is why DOSBox rocks so much, and why we'd be nowhere without it.
I only comprehend two ways of getting a 16-bit DOS game to work on Windows; you can recode the engine and compile it to native 32-bit Windows assembly, or you can simulate a DOS environment, including legacy hardware like the Sound Blaster 16. The former approach is nearly impossible to do accurately without having the original source code, and the source for SHLINK doesn't look like it's doing that at all. The latter approach is, in my mind, emulation. I know there's some debate over what counts as emulation and what counts as virtualization, but I don't see a clear line between them, so I tend to group them all under 'emulation' if there's any debate.
This question / problem has been solved by Winterfury