Re: DOSEMU-1.1.5 vs. DPMI

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,

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

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

[ANNOUNCE] DOSEMU-1.1.5

[Bart Oldeman]

DOSEMU 1.1.5

DOSEMU 1.1.5 is out. This is still a developer's release. Things may
work fine for you (and do for me) but some things can break that were
working in 1.0.x. An example is copying and pasting of multiple lines
which still doesn't appear to work correctly in all cases. That said,
a lot of things have improved since 1.0.2.1; we aim to fix the remaining
regressions for 1.2.0.

Please look at <http://www.dosemu.org/bleeding> for downloads.

I thank all contributors and testers for their patches and input
during the 1.1.4 test cycle; you all know who you are.

some things that are new in 1.1.5 in comparison to version 1.1.4:
- many bugs have been fixed.
- compiles with gcc 3.3 and newer glibc's.
- requires gcc/egcs >= 2.91.66 / glibc 2.1.3 or higher.
- added TUN/TAP support for networking (as a substitute for dosnet that
  does not require root).
- added fullscreen support for X (use Ctrl-Alt-F to switch between
  windowed and fullscreen mode).
- improved the CPU emulator for VGAEMU; some more games run in xdosemu
  now.
- added a $_vbios_post option: DOSEMU can skip the VGA BIOS' post when
  it is run on the console.
- added long file support for file locking.
- use of ~/.dosemu/drives/* -- by default DOSEMU will look in
  ~/.dosemu/drives for boot directories, hard disk images and
  symbolic links to those. A symbolic link from ~/.dosemu/drives/c
  to your boot directory is a useful alternative to setting $_hdimage
  in dosemu.conf or ~/.dosemurc.
- the dosemu script is more quiet and uses -home by default.
- added ability to use a DOS command as a DOSEMU option (without
  -E). In that case "exitemu" happens automatically when the DOS
  command terminates. This requires a "unix -e" command in your
  autoexec.bat.
- use async I/O: async I/O speeds up the I/O dramatically.
  performance of the packet driver is doubled.
- improved security if DOSEMU is run suid-root or via sudo
  * DPMI is no longer inherently insecure because DOSEMU drops root
    privileges before booting the DOS (and forks a server to deal
    with some port I/O if necessary -- on the Linux console this
    is required for some video cards and if $_speaker="native").
  * DOSEMU can be run via sudo in the same way as suid-root (it will
    revert to the identity of the original user) -- therefore it
    is no longer necessary to install two seperate DOSEMUs
    suid-root and one non-suid-root copy for security. One
    non-suid-root copy is all you need if you use sudo.
    As a side-effect dosemu.users is no longer necessary; without
    a dosemu.users file DOSEMU will only use its root privileges
    if it is run on the Linux console.
  * partition access, mouse access (console only) and serial access
    are no longer automatically accomplished using root privileges
    but must be regulated via permissions on the relevant /dev/xxx
    devices.
  * Note that, as before, root permissions are in general not
    necessary if DOSEMU is run in a terminal or in X.

Enjoy,
Bart Oldeman

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