Does Dosbox emulate a 32bit enviroment or a 16bit environment?

Question

Wiki says it's an x86 emulator. So, if DosBox is indeed an emulator for 32 bit applications, inorder for it to support 16 bit apps it must have another emulator in it right? for it to run in 16 bit mode?(isn't that how regular Operating Systems(not emulators) work?) So basically I had this argument with someone, he said that when turbo cpp compiles it generates 16 bit code, but when you run it on dosbox it behaves like a 32 bit application, is that true? and how does the size of an int variable change? is it fixed? like 2 bytes for 16 bit and 4 bytes for 32bit?

Answer 1

So, if DosBox is indeed an emulator for 32 bit applications

That's quite imprecise. It's DOS emulator, and DOS (its interface part and services (implementation in dosbox is often on the host side, not running in the emulated HW at all)) are on the 16-bit real mode side. But it emulates 80386 HW (actually it does emulate also some parts of 80486 and 80586, but the 80386 is as close to "complete" as it's practical). So any DOS application (starting in the real-mode) can switch the CPU into protected mode, and that's what many DOS application did, often using some kind of common extender like DOS4GW, etc... dosbox does emulate enough of the machine to make most of the classic SW work, but if you are mean, you can easily create DOS application which would work on real HW but fail in dosbox, due to some missing feature in emulation.

So it emulates both real-mode and protected mode of 80386 (and by the way how you switch the 80386 between modes you may get less common configurations, sometimes called "unreal mode"/etc... and I can't tell from my head, if those are accurately emulated in dosbox, but I think most of it works "good enough" to run old DOS SW).

So basically I had this argument with someone, he said that when turbo cpp compiles it generates 16 bit code, but when you run it on dosbox it behaves like a 32 bit application, is that true?

No, the Borland's Turbo C did produce only 16bit real-mode machine code, and executables produced by it were running in real-mode (unless somebody went great lengths by implementing switch into protected mode and use that for parts of their app code, but such code would have to be compiled by different compiler, or written in assembly, as Turbo C didn't have native support for 32bit protected mode - at least not in the versions I am aware of).

and how does the size of an int variable change?

That's compile time thing and depends on the compiler.

Although, if you run by accident 16b real-mode machine code in 32b protected mode, the most trivial pieces of code like xor ax,ax will actually work in 32b mode as xor eax,eax , and vice versa ( xor eax,eax compiled for real mode, if accidentally run in protected mode, will end operating as xor ax,ax ). So in this regard the code may due to confusion do some 16b operations instead of 32b operation, but for any non-trivial code it will very likely in few instructions hit some more major difference, which will probably make it crash it lot more hilarious way.

The bonus about dosbox: the dosbox author did multiple times refuse to make the emulation more accurate, stating his goal was to make dosbox perfect for the SW from the era, ie his focus was to make sure the old SW works as indented, even going intentionally for small imperfections or gaps in the emulation. That's the reason why it is "easy" to create new DOS SW which will not work in dosbox correctly. There are multiple forks of original dosbox projects, which care rather about HW emulation accuracy than about old SW being usable (sometimes improving the emulation accuracy may break old SW, if the emulation is still not fully perfect, but now it has different flaws...).

(from comments) So basically if I were to execute a 16 bit exe file in DosBox, it would run as though it were on a 16 bit environment and a 32 bit exe as though it were on a 32 bit environment right?

There is no such thing as 32 bit DOS exe. Games like for example DOOM did indeed run in 32b mode, but the exe starts in 16bit mode, and then it does handle the switch itself (for example DOOM did use the DOS4GW extender, as many other games of that era, which usually signaled that the main code of app was written in C, and compiled with Watcom compiler). I can understand why somebody would call such executables "32 bit", if you know they are switching to protected mode and using it, but technically the first instructions of the executable are starting in 16 bit real mode, as every DOS executable.

Answer 2

Dosbox emulates a 32-bit x86 CPU. That CPU, both the real kind and the emulated one, is capable of running 16-bit code, for backward compatibility with earlier 16-bit CPUs in the same family. Running a 16-bit game in Dosbox is essentially the same as running it on a real 80386 PC (which is also a 32-bit machine).