Are there tools for translating DOS machine-code to Windows environment?

Normally when you run DOS-programs in a Windows environment you use a DOS emulator. However, this is a slow and CPU-greedy solution, with many limitations. The idea has struck me; wouldn't it be more CPU-efficient to simply translate/adapt machine-code intended to run in DOS, so that it will run in Windows? Are there any tools to do this job, as to your knowledge?

It would even be possible to create exe-files, that can run in DOS as well as Windows. This is possible thanks to the fact that all Windows exe-files of PE-format contains an initial DOS-header followed by DOS-code, which instructs the computer to show an error message if the file is run in DOS. The DOS-code is then followed by other PE-headers and then the Windows-compatible code. It would be possible to replace the DOS-code showing an error message with real code from a DOS-program, then in the Windows-compatible code, which follows after the PE-headers, you can place a translator, which translates the DOS-code and then transfers execution to it.

The reverse, although more difficult, would also be possible. You simply take a windows program, and replace the error-displaying dos-code with code that translates/adapts the Windows-compatible code to DOS-environment and then transfers execution to it.

Answers


In theory it is possible. In practice, I think, I've only seen the opposite: DOS Extenders emulating a subset of Win32 API and allowing simple Windows apps to run in DOS.

There are two problems with DOS:

  1. everything is accessible (privileged instructions, all/most of hardware)
  2. it runs in the real addressing mode from part of the time to most of the time

So, if you want to still access everything, you need to emulate or virtualize a lot of stuff (CPU, memory, interrupts, various devices). Otherwise it won't be able to coexist peacefully with anything else. DOSBox does most of this for you already.

x86 systems go 64-bit. This comes with a CPU design shortcoming. Once the CPU is in 64-bit (AKA long) mode, it can no longer execute 16-bit code in either real addressing mode or virtual 8086 mode. Compatibility for this was not designed or implemented in the CPU (say thanks to AMD and intel). So, either you lose 64 bits and everything that requires it or you lose DOS. There's hardware virtualization (intel-VT/AMD-Pacifica) which kind of brings 16 bits back, but you need a hypervisor for it, and, since there's no magic (a hypervisor by itself doesn't make two PCs out of one), you still need to emulate/virtualize a lot of things that DOSBox does.

There's no cheap and efficient solution. Other than a separate old PC dedicated solely for DOS stuff. And these are increasingly harder to get and maintain.

I think you're grossly underestimating the amount of work needed and the complexity involved. If you can't rewrite the program, use an emulator or a VM. If you can, rewrite it to work on Windows natively. Another option may be simply bundling DOSBox or some such with the program, making it merely appear as one Windows program, perhaps just a single .exe with everything inside.


Need Your Help

Any reason to use JSONP instead of CORS?

http cors jsonp

My understanding is that JSONP is kind of hacky way of implementing something that could be done using CORS. Still I see people asking questions of how to use JSONP even if they have access to serv...

JAVA search method

java search methods

I have a small problem. I wrote a few code in Java to solve one problem but my solution was not efficient.