The other way to detect DosBox is a one line Qbasic program PRINT VAL("5").
If it's a 64-bit build made using Visual Studio, you get 4.99999999999. Visual Studio doesn't support legacy 80-bit floating point math for that target. Visual Studio also does not support inline assembly to let you make use of the legacy 80-bit floating point instructions.
But if you set the CPU core to "Dynamic", then you get the proper value of "5". Or if you use the MingW builds, those also support 80-bit floating point math and give the correct value of "5".
It is quite embarrassing to ship a CPU emulator with broken floating point math as the default.
It never really occurred to me that you'd want to be able to detect if something is running in DOSBox, since I figured that the point was to be as compatible as possible with MS-DOS.
I guess it makes sense to try it anyway. Now I'm wondering how I'd be able to detect something like Concurrent DOS or REAL/32 or REAL/NG.
For me the opposite. I would have never though that there would be a point to trying to "detect" DOSBox since it would be trivial to do so. After all, DOSBox is not really designed to run MS-DOS, but its own DOS-like thing, and there must be a million small details that you can use to distinguish it from MS-DOS, if you really wanted to. I mean, the default filesystem is not even FAT...
_Even_ if you run the MS-DOS kernel in DOSBox, the builtin DOS literally leaks through in many places (e.g. many API services still available instead of crashing), with only some of the more recent forks even trying to hide it.
Testing if you're running under virtualization or emulation is a whole thing. We wrote virt-what to do this for virt and containers. It could do emulators as well if someone was motivated enough. It's basically a giant shell script. https://people.redhat.com/~rjones/virt-what/
There's also an adversarial aspect to this. Some emulators try to avoid detection and a lot of software tries to detect if it's running under virt for various reasons, eg. to stop cheating in games or stop reverse-engineering. (virt-what is deliberately not adversarial, it's very easy to "trick" it if you wanted to do that)
Neat! I’ve detected it with a simple (less reliable) way in the past for a demo (I forget why I needed to do that). It didn’t occur to me to inspect something like a built in command!
18 comments
If it's a 64-bit build made using Visual Studio, you get 4.99999999999. Visual Studio doesn't support legacy 80-bit floating point math for that target. Visual Studio also does not support inline assembly to let you make use of the legacy 80-bit floating point instructions.
But if you set the CPU core to "Dynamic", then you get the proper value of "5". Or if you use the MingW builds, those also support 80-bit floating point math and give the correct value of "5".
It is quite embarrassing to ship a CPU emulator with broken floating point math as the default.
> It is quite embarrassing to ship a CPU emulator with broken floating point math as the default.
It was also quite embarrassing to ship a real CPU with broken floating point math.
I guess it makes sense to try it anyway. Now I'm wondering how I'd be able to detect something like Concurrent DOS or REAL/32 or REAL/NG.
_Even_ if you run the MS-DOS kernel in DOSBox, the builtin DOS literally leaks through in many places (e.g. many API services still available instead of crashing), with only some of the more recent forks even trying to hide it.
There's also an adversarial aspect to this. Some emulators try to avoid detection and a lot of software tries to detect if it's running under virt for various reasons, eg. to stop cheating in games or stop reverse-engineering. (virt-what is deliberately not adversarial, it's very easy to "trick" it if you wanted to do that)