3

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?

Michel Thomas
  • 143
  • 1
  • 10
  • 5
    DOSBox more or less emulates a 32-bit 386 CPU. The CPU has a 16-bit real mode (the default when the emulator when it boots) which DOS uses. It can be switched into 16 or 32-bit protected mode if software needs to run 16-bit and 32-bit protected mode code. Just like 16-bit code on a real 386 CPU there is the ability to use 32-bit addressing in 16-bit real mode. The size of a short, int, long (I assume you are talking about C/C++) are dependent on the tool being used to compile. – Michael Petch Aug 01 '19 at 04:12
  • You mentioned "Just like 16-bit code on a real 386 CPU there is the ability to use 32-bit addressing in 16-bit real mode",could you please explain this? – Michel Thomas Aug 01 '19 at 05:53
  • 1
    The grandfather of all x86, the 8086, has an address bus of 20 bits, but only 16 bit registers. So they invented "segmented" addressing that, in example, combines two registers to make up a 20 bit value. For this the value of one of the "segment registers" like DS is shifted 4 bits left, and then the value of another register is added to this, giving 20 bits of address. The newer 386 has most registers and the address bus all 32 bits wide. These could be used even in "real mode". – the busybee Aug 01 '19 at 06:10
  • 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? – Michel Thomas Aug 01 '19 at 07:40
  • 1
    Is there such a thing as a 32-bit DOS `.exe`? I thought a DOS `.exe` always started in 16-bit mode and had to implement switching to protected mode itself. Classic DOS is a 16-bit OS. – Peter Cordes Aug 02 '19 at 01:38
  • 3
    @Peter Cordes: DPMI provides a standard interface for (usually 32-bit) PM DOS programs. They still need a stub loader that runs in real/V 86 mode that initialises the DPMI part, though. – ecm Aug 02 '19 at 11:38
  • 2
    @PeterCordes : There is no 32-bit DOS EXE format. DOS Programs can enter protected mode (or use a DOS/Extender, VCPI, DPMI) to switch the processor into protected mode and run their code there. As ecm points out DOS extenders provide a stub program to switch into protected mode. Usually they are referred to as 32-bit DOS programs. Some people say 32-bit DOS EXE when in fact the EXE format is 16-bit but eventually it runs code in protected mode. DJGPP is a GCC variant that produced 32-bit DOS programs and it relies on DPMI (by default though CWSDPMI). – Michael Petch Aug 02 '19 at 13:07
  • 1
    For the most part the way DPMI works is that your code runs in protected mode. If you have to make a call to DOS service DPMI has a mechanism to switch back to real mode (or execute the code in a v8086 task) to make the call and then it switches back. DPMI can also be used to create 16-bit protected mode programs if the DPMI host supports that feature. – Michael Petch Aug 02 '19 at 13:16

2 Answers2

4

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, i.e. 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.

Ped7g
  • 16,236
  • 3
  • 26
  • 63
  • 2
    "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, i.e. his focus was to make sure the old SW works as indented," The DOSBox authors actually care only about old **games** running fine. They don't care about other software (such as debuggers). – ecm Aug 02 '19 at 11:43
  • 3
    DosBox supports Unreal mode as it properly handles (emulates) the fields in the descriptor cache registers. Without it running things like HIMEM.SYS would be impossible. – Michael Petch Aug 02 '19 at 11:45
3

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).

Wyzard
  • 33,849
  • 3
  • 67
  • 87