DOSEMU-1.1.5 vs. DPMI

DOSEMU-1.1.5 vs. DPMI

[Peter B. Steiger]

1.1.5 compiles and runs fine, but I seem to be having some trouble with my 
DPMI-based programs.  Hardware is AMD Duron 850MHz with 512MB RAM.  
There's a 60-GB drive with a 10-GB fat32 partition on which I installed 
Windows 98 rev. A.  Linux is Linux From Scratch using kernel 2.4.20, gcc 3.2.2.  
Since I own Tool O' The Devil '98, I do not use freedos; my boot directory 
/usr/share/dosemu/bootdisk just contains links to /mnt/fat32 files and folders.

The program I'm most interested in running was written in Clipper, an old dBase-
type compiler that actually creates the EXE with a complete p-code parser built 
in so it can interpret your program on-the-fly.  The EXE is linked with Blinker, 
which allows you to link as a real mode or protected mode application.

In real mode my test program works fine... just a "Hello, world" display; I can 
also run an enormous memory hog test that creates a meg or two of string 
arrays in real mode (swapping to a disk file for VM).  But if I try to run either 
of those programs in protected mode, I get:

DPMI unhandled exception 06 - terminating client
it is likely that dosemu is unstable now and should be rebooted

... as soon as the program loads, before any output appears.  This happens 
regardless of whether I run as root (yeah, I know, danger Will Robinson...) or anyone 
else.  The same error occurs at the console and in an X window with xdosemu.  I 
tried building with and without mitshm; it makes no difference.

What's strange is, this used to work.  I'm using the same hardware and the same 
dosemu.conf files I had when I ran Red Hat 7.3 with kernel 2.4.20, gcc 2.96, dosemu 
1.0.something last year.

Relevant portions of dosemu.conf are:
$_xms = (16383)	
$_ems = (off)		
$_dpmi = (65535)	
$_dosmem = (639)	

I have experimented with various amounts of each type of memory, and I have made 
sure that /proc/sys/kernel/shmmax has a high enough limit to handle anything I throw 
at it.  The kernel is compiled with the SYSVIPC option enabled.

config.sys says:
device=C:\windows\himem.sys
device=C:\windows\emm386.exe noems
dos=high,umb
files=100

I can supply the complete dosemu.conf and/or the two EXE files (with and without 
DPMI support linked in) if anyone is bored enough or curious enough to explore this; 
I'm an applications developer so my knowledge of what's going on with the system's 
use of memory is just about nonexistent.

Any ideas, suggestions, or general ridicule gratefully accepted through the list or my 
own email.  Thanks!
pbs
--------
Peter B. Steiger
Cheyenne, WY

Re: DOSEMU-1.1.5 vs. DPMI

[Stas Sergeev]

Hello.

Peter B. Steiger wrote:
> DPMI unhandled exception 06 - terminating client What's 
> strange is, this used to work.
DPMI underwent a major surgery recently,
so there is no surprise.

> the same dosemu.conf files I had when I ran Red Hat 7.3 
> with kernel 2.4.20, gcc 2.96, dosemu 1.0.something last 
> year.
Just to be paranoid, could you please
verify that it still works on 1.0.2.1?
You have changed gcc and probably something
else, so who knows...

> device=C:\windows\himem.sys 
> device=C:\windows\emm386.exe noems
Neither of this will work under dosemu.

> I can supply the complete dosemu.conf and/or the two EXE
> files (with and without DPMI support linked in)
Yes. Please open the bug entry in dosemu's
BTS on sourceforge and upload your files
there.

Re: DOSEMU-1.1.5 vs. DPMI

[Peter B. Steiger]

Stas says:

> Just to be paranoid, could you please
> verify that it still works on 1.0.2.1?
> You have changed gcc and probably something
> else, so who knows...

OK, here's what I found out:
1.0.2.1 installed from precompiled binaries works under kernel 2.4.20, gcc 3.2.2

The binaries I thought were 1.0.x on my RH system (kernel 2.4.20, gcc 2.96) are 
something newer; the announce file says it's 1.1.2 but I can no longer test it 
because the binaries crash on my current (kernel 2.4.20, gcc 3.2.2) system.  I 
also can't get 1.1.2 to compile on my current system.

1.1.5 compiled easily on gcc 3.2.2, but it will not handle the DPMI calls by Clipper 
the way the earlier versions did.  Also, while writing all this and running tests, I 
found the 1.1.5.1 patch and built that, but I got the same results.

I used the free pascal compiler on my NT to create some test programs that 
allocate large amounts of DPMI memory, and they work fine with 1.1.5.{0,1}  So 
it's not ALL uses of DPMI that fail, only the Clipper programs.

> Yes. Please open the bug entry in dosemu's
> BTS on sourceforge and upload your files
> there.

Done.  I included the Pascal EXE that requests DPMI successfully and the 
boot.log that it generated with +M enabled in debug, and the  Clipper EXE and 
boot.log that show DPMI crashing.
pbs
--------
Peter B. Steiger
Cheyenne, WY

Re: DOSEMU-1.1.5 vs. DPMI

[Peter B. Steiger]

Stas,

I wrote those example EXEs for my own testing and then like an idiot I didn't 
clean them up for anyone else to make sense of... I uploaded a new pair of tests 
(dpmiok.exe and dpmibad.exe) and their corresponding logs with -D9+M debug 
options as you requested.  Unfortunately that won't tell you much more than the 
previous log files did... my dpmibad.log stops where it does because it halts with 
the exception error 06 before any output appears.

I see from your comments on the bug report that you did get correct output 
from dpmibad.exe... that tells me that the fault lies not in dosemu or the dpmi 
handling routines, but my own build or my configuration... probably my build, 
since the same configuration works with the older prebuilt binary.

configure options are:
--prefix=/usr  --datadir=/usr/share --disable-use-svgalib --enable-mitshm --
enable-experimental --enable-dodebug --enable-debug --enable-aspi --disable-
cpuemu --with-syshdimagedir=/usr/share/dosemu --with-fdtarball=none

compiling with gcc 3.2.2 on kernel 2.4.20.  Anything in the above you did 
differently which might affect the DPMI performance?
pbs
--------
Peter B. Steiger
Cheyenne, WY