The processor boots in real mode when we turn on the machine. There are other modes. In 32-bit mode it is switched to private for some security and then to long (64-bit).
Codeview was made for real mode, to work in ms-dos, this means 16 bits initially and a different command interpreter than cmd.exe; instead, command.com.
If you make a boot disk with the basics of ms-dos it will work if you put it on the floppy disk and change setup settings; or, if a cd-rom, if bootable, you can even copy a virtual mini disk if you can mount the system drive or perhaps in memory.
One problem that can happen with debuggers that use command.com interrupts (command interpreter) instead of cmd.exe (command interpreter) functions are the functions they offer. Addiction and monopoly rather than virtuosity.
The Operating System offers us (as programmers) functions, and at that time was done through interruptions. The ms-dos offered us the 21h interrupt, a conglomeration of instructions that made use of the bios functions or directly changing bios variables in memory, the initial machine, the base. The problem was that the interruptions (which certain hardware offered) from a programmer's point of view were not so widespread.
If you can reproduce virtually or really the past, the program will work; due to the fact that processor instruction compatibility may not be from bios.
It worked in dosbox because it offers ms-dos "functions", while cmd.exe does not, I mean, not interrupt.
One caveat, some programs use undocumented functions (interrupts). This was common at the time of word and excel as it was anti-monopoly. I've seen some programs only work on the microsoft virtual machine (int 2eh) and not others.
I know other modes of processor operation but unfortunately I forgot how to proceed.
Summary is; If you offer everything the program needs to work, it will work.
