May 20, 2005 for dosemu 1.3.2 (and possibly earlier
versions)
This file lists programs and groups of programs not running or running only partially under dosemu. The most up-to-date version of this file may be found on: http://www.dosemu.org/. Please report about possible additions to linux-msdos@vger.kernel.org or the SourceForge BTS at http://www.dosemu.org/. Perhaps your program can be made going with the help of others. Have a look at the dosemu-howto how to do so.
Programs that don't work under the MSDOS Emulator and probably won't ever work, because of fundamental problems. Some of these fundamental problems result in these programs not being runnable on Win3.x/Win95/WinNT and under OS/2 DOS box either. These programs are characterized by using any of these features:
VCPI allows programs to run in ring 0. This is kernel mode in Linux and not sensible.
Example: sim2181.exe from Analog Devices DSP Kit
Older versions of the Pharlap Extender (run286) need ring-0 access under DOSEMU to install their own DPMI server. The use of proprietary undocumented extensions to the DPMI protocol makes DOSEMU's DPMI server unsuitable for this extender.
Example: Autocad Version 12c1 For DOS
Example: the game BioForge by Origin Systems.
The JEMM memory manager provides proprietary extensions to the EMS protocol. These are not supported by DOSEMU.
Example: Wing Commander Privateer by Origin Systems
Check with "strings <program.exe> | less" if the program contains some of these keywords: vcpi, RUN286.
The Programmable Interval Timer (PIT) can be programmed to produce interrupts with frequencies up to almost 2MHz. Linux sets this to only 100Hz (2.6 kernels can set it to 1KHz) and doesn't allow the software to change that. This limits the minimal interval between subsequent SIGALRM notifications for software that uses the setitimer(2) syscall. To emulate the PIT frequencies that are higher than the frequency Linux sets the PIT to, dosemu uses "interrupt bursts": on every SIGALRM reception dosemu triggers the timer interrupt as many times as necessary to compensate the gap since the previous SIGALRM reception. This allows to keep a precise timing but causes problems for some programs. When the timer interrupt handler is invoked more than once without letting the main thread to execute, some programs can lock up. The game "Cosmo" is one of those.
Another problem is that due to the aforementioned low timer frequency dosemu is not able to properly emulate the timings for different emulated hardware. That also causes problems for some programs. Scream Tracker 3, for example, can lock up at startup because the interrupt from an emulated SB card can be triggered earlier than it should be in a real system.
Possibly a workaround may be found in future DOSEMU versions.
There are several defects in Intel's x86 CPUs that are causing problems for some software. Below is a description of the defects that are known to cause problems for software running under dosemu.
Intel's manual http://www.intel.com/design/intarch/techinfo/pentium/inout.htm says:
" A procedure may use the POPF instruction to change the setting of the IF flag only if the CPL is less than or equal to the current IOPL. An attempt by a less privileged procedure to change the IF flag does not result in an exception; the IF flag simply remains unchanged. "
The fact that the exception is not being generated, prevents dosemu from catching and properly simulating the POPF instruction executed in protected mode. That, in particular, means that the following code, executed in protected mode (not in v86 mode) under dosemu, will end up with interrupts disabled (IF cleared):
sti
pushf
cli
popf |
This bug can only affect DPMI programs, as using DPMI is the only way to execute protected mode code under dosemu. Known programs that are affected are the games from ID software, namely Doom2 and Duke Nukem 3D, but only when configured with sound. An optional work-around was added to dosemu, which just re-enables the interrupts if they were disabled for too long in protected mode. Additionally the address of the instruction that disabled the interrupts, is added to a black-list and this instruction is ignored for subsequent passes so that it can't disable the interrupts any more. This is potentially unsafe, but if the timeout is long enough, no harm was observed so far. The timeout is configured via the $_cli_timeout option, which is measured in a 10ms timer ticks. Setting that option to 0 disables the workaround completely, making Doom2 unplayable with sound enabled.
Intel's x86 CPUs have a defect described here: http://www.intel.com/design/intarch/specupdt/27287402.PDF chapter "Specification Clarifications" section 4: "Use Of ESP In 16-Bit Code With 32-Bit Interrupt Handlers", which reads as follows:
"ISSUE: When a 32-bit IRET is used to return to another privilege level, and the old level uses a 4G stack (D/B bit in the segment register = 1), while the new level uses a 64k stack (D/B bit = 0), then only the lower word of ESP is updated. The upper word remains unchanged. This is fine for pure 16-bit code, as well as pure 32-bit code. However, when 32-bit interrupt handlers are present, 16-bit code should avoid any dependence on the upper word of ESP. No changes are necessary in existing 16-bit code, since the only way to access ESP in USE16 segments is through the 32-bit address size prefix."
The corruption happens when the Linux kernel returns control to the dosemu process, while a 32-bit DPMI client that uses a 16-bit data segment for the stack is active. This is not the usual case, but unfortunately some 32-bit DPMI clients are actually using a 16-bit segment for the stack, and even the dos4gw extender behaves that way sometimes.
Programs that are known to be affected by this issue are:
Need For Speed 1 (demo version at least, when configured with sound)
Syndicate Wars (when used with dos4gw 0.8)
Open Cubic Player
These programs are crashing shortly after startup, but this problem is difficult to detect reliably, so there may be many more programs that experience a random crashes due to this CPU bug.
The reliable work-around was developed and added into linux-2.6.12. If you hit that problem, consider upgrading your linux kernel.
| Next | ||
| Known bugs |