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 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)
Example: There is (was? I don't actively follow the community) a patch set for a particular piece of VM software that made it undetectable to anti-cheat in games.
While I don't use said software (I have a casual interest in it only...would be nice to get more games working on Linux), I have to disclose that I'm against anti-cheat mechanisms. I'm a software engineer, and I've worked on a few smaller games, and know the overall structure of bigger ones, and I don't think I've ever seen a game use good practices in multiplayer. Instead, they usually rely on client side code and lean on anti-cheat software to stop cheaters.
What's WGU in this context?
> which makes enough sense since if you're in a VM they can't see your full screen
Presumably they can't also see the screen of another device...
The virus writer Priest figured out he could detect being run under single-stepping, and manipulate the stack and trap flag to re-vector control from TBSCAN to a destructive routine that trash the user's hard disk (but otherwise just run normally when not in the presence of TBCLEAN).
He later used this idea as the basis for the "emulating tracer" (in Natas, for sure-- but I think present in some earlier code too-- I don't remember what, thought) using single-step interrupt calls to trace thru resident antivirus programs to find original BIOS and DOS interrupt vectors and "call past" them (to prevent detection and do stealth).
His tracer decoded the next instruction to detect every method by which the trap flag state could be leaked to or mutated bu the traced code. He would emulate and step over any of these "privileged" instructions", presenting a sanitized state to the code under trace. It wasn't a full x86 emulator and could not have handled code that used trap-based anti-debug. That would have required a full emulator (and that way lies madness).
When VMware virtualized x86 I thought about Priest's code. Defender and other AV running samples under emulation makes me think about it too. So does this article.
