## EMUfailure.txt

Uwe Bonnes (original author), bon@elektron.ikp.physik.th-darmstadt.de
Sep 28, 2003 for dosemu 1.2.0 (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.rutgers.edu. or the SourceForge BTS at http://www.dosemu.org/. Perhaps it can be made going with the help others. Have a look at the dosemu-howto how to do so.

## Fundamental problems

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 in a Dosbox and under OS/2 either. These programs are characterized by using any of these features:

### Virtual Control Program Interface (VCPI)

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

### Programs using older Versions of the Pharlap Extender

The Pharlap Extender in it's older versions needed ring 0 access too, so it can't me made working in the emulator.

Example:Autocad Version 12c1 For DOS

### MSDOS enhanced mode Windows kernel krnl386.exe

krnl386.exe needs Ring 0 access too.

### Windows programs using Win32s

Win32s needs Ring 0 access too.

### Does my failing program belong to these groups?

Check with "strings <program.exe> | less" if the program contains some of these keywords vcpi, pharlap and win32s. Newer Pharlap programs may work.

### Fundamental problem with the Linux kernel

The PC Internal 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.

### Fundamental problems with the CPU

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.

#### Problem with the virtualization of the IF flag

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

[ the interrupts are still disabled here ]

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.

#### ESP register corruption

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. Intel was contacted to comment on that issue, and their comment follows:

" We understand your concern, but at this time we do not have anyone to look at this. This part has been out for nearly 20 years and all of the designers are currently working on new projects. We will make a note of this and see if somewhere down the road someone in software can take a look at this. "

The reliable workaround on the dosemu side was not found, but there are some hopes that this can be worked around on the kernel's side. 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.

It appeared that it may be possible to work around this problem by using a different DOS extender with the programs that are using the dos4gw extender by default. The DOS32A extender at http://dos32a.sf.net, seems not to trigger the problem. It can be used as follows: `DOS32A progname.exe` (at the DOS prompt). CauseWay dos extender also seems to help.

It may be possible in the future to work around this problem by using the CPU emulation. It is already possible to run dosemu under a CPU emulator called Qemu (http://savannah.nongnu.org/projects/qemu), where this problem doesn't exist.

## Known bugs

### Things YOU may help changing

#### List of currently known bugs in Dosemu 1.2.0.

- Some documentation is known to be well out of date.

- Windows 3.1 will not run very well because for some reasons.

- OPL3 FM is not implemented yet (but Midi, SB8 and SB16 work)

- IPX doesn't play well with DPMI. You might be able to use the packet driver in combination with DOS TSR drivers such as LSL, PDETHER and IPXODI. See NOVELL-HOWTO.txt and README.txt for details.

- Some database programs (Clipper, FoxPro) have problems with locking in certain configurations. smbfs doesn't support locking. $_full_file_locks=(on) may or may not help.

- The direct text console (without graphics) may have the whole screen jumping one line up.

- Console graphics (especially switching VCs) can be problematic with certain video cards, in particular in combination with fbdev graphical consoles.

- DPMI interrupt handling may be unreliable.

- Mortal Kombat 1 and 2 are not producing any sound for unknown reasons.

- X-COM Apocalypse locks up at startup if configured with sound.

- RTC periodic interrupts are not implemented yet.

#### Bug reports that are currently open at http://www.dosemu.org/. but that were not yet confirmed by dosemu developers.

- An (unknown) DPMI clipper program hangs when run on a SMP machine

- A chess program (VChess) may crash in xdosemu when the mouse is moved (there are still some issues with the internal mouse driver)

- Another chess program (Nimzo 3) crashes when there is no CD in the CDROM drive.

- Watcom C may fail freeze on AMD but not PIV.

### Problems probably solved

Here reported problems with older versions are listed. The current version should have solved them, but this has to be validated. Please report if you had problems in the listed areas and these problems are now solved.

- There are known problems with xdosemu (e.g. it may not work at all for you.)

- xdosemu sessions accessed from remote, non-Linux X-sessions (e.g. SUN stations and others) may not work correctly. Use $_mitshm=(off).

- The internal mouse driver is known to have problems.

- Running a protected mode 'make' and a protected mode compiler (e.g. Borland's) may not work. Try switching to a real mode make.

- dd2demo.exe

  This is a game found at

      http://www.psygnosis.com/

  Reported by Hans Lermen, it kills dosemu, giving an output like:

      general protection at 0x1fba: a7
      ERROR: SIGSEGV, protected insn...exiting!

  The crash happens in DMPI Call 0x0302 At least DMPI Call 0x0506 is not yet implemented.

  This demo is no longer for download. But if you can test please let us know for completeness.

- bae.exe

  This is a demo version of an Electronic CAD programm, found at

      http://www.bartels.de/

  Reported by Uwe Bonnes, it stops dosemu with a blank screen in an unusable state. You have to do a remote login to kill dosemu, or hit reset with all it's possible fatal result. The possible reason is the missing implementation of DMPI Call 0x0800, as Uwe Bonnes reported it once working on the console with some hack.

  However, this demo is no longer for download, and, moreover, they have a native Linux version.

### QIC tape programs

Reported by vignani@mail.tin.it (Alberto Vignani): Tape is not supported. Worse, if you use a floppy under dosemu, you have sometimes to remove/reinstall the ftape module.

## Programs exhibiting graphical problems in xdosemu

The following programs work perfectly on the Linux console (suid/sudo/root) with graphics enabled but exhibit minor or major glitches in xdosemu.

### Text programs with custom fonts

Programs such as Norton Commander and the Watcom Debugger use custom characters to display icons, radio buttons and similar characters. This problem is addressed in current development versions and the fixes will likely be backported to a later version of DOSEMU 1.2.x

### Games with graphical problems

The following games exhibit glitches or don't work at all in xdosemu. Please let us know when any problems are solved or even better, help us solving!

- Commander Keen 1 wobbles like jelly and the window shakes every time it scrolls.

- Commander Keen 4 gives you a black screen.

- Clyde's Adventures statsbar fonts completely garbled xdosemu. Download at: http://www.gamesdomain.com/directd/513.html

- Pinball Dreams 2 takes a long time to start. Once it's past the startup screen it runs fine though.