[ANNOUNCE] DOSEMU-1.1.5

[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

Download Problem DOSEMU-1.1.5

[Claudia Neumann]

Am Samstag, 7. Juni 2003 02:07 schrieb 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.

Hi,

I just tried to download dosemu-1.1.5.tgz from the mirror in Brussels and the 
mirror in Dublin. The download didn't stop at 2073 kb, but went on til I 
stopped it > 5000 kb. Is there something wrong with the download procedure? 
Is the file bigger the 5000 kb?

Regards

Claudia

Re: Download Problem DOSEMU-1.1.5

[Bart Oldeman]

On Sat, 7 Jun 2003, Claudia Neumann wrote:

> I just tried to download dosemu-1.1.5.tgz from the mirror in Brussels and the
> mirror in Dublin. The download didn't stop at 2073 kb, but went on til I
> stopped it > 5000 kb. Is there something wrong with the download procedure?
> Is the file bigger the 5000 kb?

I'm on a modem now so I'm not too happy to test it completely but wget
gives me this:

wget http://belnet.dl.sourceforge.net/sourceforge/dosemu/dosemu-1.1.5.tgz
--00:05:24--
http://belnet.dl.sourceforge.net/sourceforge/dosemu/dosemu-1.1.5.tgz
           => `dosemu-1.1.5.tgz'
Connecting to belnet.dl.sourceforge.net:80... connected!
HTTP request sent, awaiting response... 200 OK
Length: 2,121,858 [application/x-tar-gz]

This length is correct.

Bart

Re: Download Problem DOSEMU-1.1.5

[Ged Haywood]

Hi Bart,

On Sat, 7 Jun 2003, Bart Oldeman wrote:

> On Sat, 7 Jun 2003, Claudia Neumann wrote:
> 
> > I just tried to download dosemu-1.1.5.tgz from the mirror in Brussels and the
> > mirror in Dublin. The download didn't stop at 2073 kb, but went on til I
> > stopped it > 5000 kb. Is there something wrong with the download procedure?
> > Is the file bigger the 5000 kb?

You shouldn't have stopped it.

But apart from that it's fine, and I like what I see.

> Length: 2,121,858 [application/x-tar-gz]
> 
> This length is correct.

But the TYPE isn't...
I think somebody forgot to gzip the .tgz file. :(

73,
Ged.

Re: Download Problem DOSEMU-1.1.5

[Alistair MacDonald]

On Sun, Jun 08, 2003 at 01:05:34AM +0100, Ged Haywood wrote:
> On Sat, 7 Jun 2003, Bart Oldeman wrote:
> > On Sat, 7 Jun 2003, Claudia Neumann wrote:
> > 
> > > I just tried to download dosemu-1.1.5.tgz from the mirror in Brussels and the
> > > mirror in Dublin. The download didn't stop at 2073 kb, but went on til I
> > > stopped it > 5000 kb. Is there something wrong with the download procedure?
> > Length: 2,121,858 [application/x-tar-gz]
> > 
> > This length is correct.
> 
> But the TYPE isn't...
> I think somebody forgot to gzip the .tgz file. :(

This is nothing new, its been happening for years ...

Some web browsers have the annoying tendency to decompress files on download.
They don't tell you they are going to do it, they just do.

There is nothing wrong with the file size, or the extension.

Alistair

Re: Download Problem DOSEMU-1.1.5

[Ged Haywood]

Hi there,

On Sun, 8 Jun 2003, Alistair MacDonald wrote:

> Some web browsers have the annoying tendency to decompress files on download.
> They don't tell you they are going to do it, they just do.
> 
> There is nothing wrong with the file size, or the extension.

No, there isn't, but then I didn't say that.  :)

I've been using Netscape under Linux to download gzipped tarball files
for several years.  I've never seen this before:

http://www.jubileegroup.co.uk/strange_download.gif

but if someone can tell me why it's suddenly happened I'll be pleased
to know.  It could easily be because I've recently upgraded my desktop
machine to Slackware V9 (which has Netscape 7, previously I've been
using 4.7 which certainly never did what you say unless you wanted it).  
It could also be that this was a mistake, because there are a number
of things which broke as a result. :(  

But I've downloaded several gzipped tarballs using the latest Netscape
lately and had no problems with it.  I feel sure that the content-type
is getting confused somewhere along the line but I haven't investigated.
The patches applied cleanly - I just had to untar the file without giving
the gunzip option to 'tar'.

Anyway, my point to Claudia was that if she allowed the download to
finish she'd have the file she needs.  If she just does a quick mental
calculation of the download rate and file size she'll know roughly how
long she'll need to wait, despite what the browser tells her.

73,
Ged.

Re: Download Problem DOSEMU-1.1.5

[Bart Oldeman]

On Sun, 8 Jun 2003, Ged Haywood wrote:

> Hi there,
>
> On Sun, 8 Jun 2003, Alistair MacDonald wrote:
>
> > Some web browsers have the annoying tendency to decompress files on download.
> > They don't tell you they are going to do it, they just do.
> >
> > There is nothing wrong with the file size, or the extension.
>
> No, there isn't, but then I didn't say that.  :)
>
> I've been using Netscape under Linux to download gzipped tarball files
> for several years.  I've never seen this before:
>
> http://www.jubileegroup.co.uk/strange_download.gif
>
> but if someone can tell me why it's suddenly happened I'll be pleased
> to know.  It could easily be because I've recently upgraded my desktop
> machine to Slackware V9 (which has Netscape 7, previously I've been
> using 4.7 which certainly never did what you say unless you wanted it).

yes, it really looks like your new netscape automatically decompresses on
the fly. I'm not sure what you can do about it but all I know now that
it's not a DOSEMU problem -- type, extension and size are all correct :)

Bart

Re: Download Problem DOSEMU-1.1.5

[Claudia Neumann]

Am Sonntag, 8. Juni 2003 12:58 schrieben Sie:
> yes, it really looks like your new netscape automatically decompresses on
> the fly. I'm not sure what you can do about it but all I know now that
> it's not a DOSEMU problem -- type, extension and size are all correct :)
>
> Bart

Hi all,

if it is a browser mistake, then Mozilla 1.2.1 has the same problem. I 
started the download with Mozilla and I was surprised to get a download rate 
of nearly 12 kb/s, which is not what I usually get. But then it went on and 
on passed the 5000 kb. Now I know of the problem, I won't stop the download 
any more. Or I try opera.

Thanks from a newbie

Claudia

Re: Download Problem DOSEMU-1.1.5

[Ged Haywood]

Hi all,

On Sun, 8 Jun 2003, Claudia Neumann wrote:

> if it is a browser mistake, then Mozilla 1.2.1 has the same problem.

It could easily be that, but I still think there's more to it than
just the browser.  I've used the same browser to download other .tgz
files today with no problem.

73,
Ged.

Re: Download Problem DOSEMU-1.1.5

[Bart Oldeman]

On Sun, 8 Jun 2003, Ged Haywood wrote:

> On Sun, 8 Jun 2003, Claudia Neumann wrote:
>
> > if it is a browser mistake, then Mozilla 1.2.1 has the same problem.
>
> It could easily be that, but I still think there's more to it than
> just the browser.  I've used the same browser to download other .tgz
> files today with no problem.

right, the problem is with some sourceforge mirrors, see
http://sourceforge.net/tracker/?group_id=1&atid=200001&func=detail&aid=747229

Bart

Re: Download Problem DOSEMU-1.1.5

[Ged Haywood]

Hi Bart,

On Mon, 9 Jun 2003, Bart Oldeman wrote:

> On Sun, 8 Jun 2003, Ged Haywood wrote:
> 
> > On Sun, 8 Jun 2003, Claudia Neumann wrote:
> >
> > > if it is a browser mistake, then Mozilla 1.2.1 has the same problem.
> >
> > It could easily be that, but I still think there's more to it than
> > just the browser.  I've used the same browser to download other .tgz
> > files today with no problem.
> 
> right, the problem is with some sourceforge mirrors, see
> http://sourceforge.net/tracker/?group_id=1&atid=200001&func=detail&aid=747229

Aha.  I normally use the Belgian one as it's the closest to me.  Good
to know (that I'm not going crazy:).  It isn't a problem for me.
Thanks Bart.

I'll let you know how it goes with 1.1.5 when I get a quiet few
moments.  I just want to be able to compile something with an old
Symantec DOS C compiler (one module of a commercial software suite
which I wrote; the module is about five thousand lines, it's not the
biggest but it won't compile under DOSEMU when the other 80 all do).

73,
Ged.

RE: Download Problem DOSEMU-1.1.5

[Riley Williams]

Hi all.

 >>> if it is a browser mistake, then Mozilla 1.2.1 has the same problem.

 >> It could easily be that, but I still think there's more to it than
 >> just the browser. I've used the same browser to download other .tgz
 >> files today with no problem.

 > right, the problem is with some sourceforge mirrors, see
 >
http://sourceforge.net/tracker/?group_id=1&atid=200001&func=detail&aid=74722
9

Based on that webpage, it's happening because the web server is sending
a header that reads...

	Content-Encoding: x-gzip

...and the browser is CORRECTLY treating this as a request to decompress
the file on the fly. Basically, it's a web server misconfiguration.

The reason that wget doesn't hit the problem is that it's mirroring the
site, so correctly FAILS to decompress as it assumes your web server is
set up identical to the one it's mirroring.

Best wishes from Riley.
---
 * Nothing as pretty as a smile, nothing as ugly as a frown.

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.488 / Virus Database: 287 - Release Date: 5-Jun-2003

RE: Download Problem DOSEMU-1.1.5

[Justin Zygmont]

I never had any problems with the download, and 1.1.5 sure runs nice.  I'm 
just suprised that sound doesn't seem to work properly, anyone else notice 
this?

Re: Download Problem DOSEMU-1.1.5

[Ross Vandegrift]

On Sat, Jun 07, 2003 at 09:44:40PM +0200, Claudia Neumann wrote:
> I just tried to download dosemu-1.1.5.tgz from the mirror in Brussels and the 
> mirror in Dublin. The download didn't stop at 2073 kb, but went on til I 
> stopped it > 5000 kb. Is there something wrong with the download procedure? 

This happened to me last week trying to download 1.1.4 using Galeon, but
I was downloading from ibiblio.  I tried again and used a different
mirror and wget instead of galeon, and everything was fine.


-- 
Ross Vandegrift
ross@willow.seitz.com

A Pope has a Water Cannon.                               It is a Water Cannon.
He fires Holy-Water from it.                        It is a Holy-Water Cannon.
He Blesses it.                                 It is a Holy Holy-Water Cannon.
He Blesses the Hell out of it.          It is a Wholly Holy Holy-Water Cannon.
He has it pierced.                It is a Holey Wholly Holy Holy-Water Cannon.
He makes it official.       It is a Canon Holey Wholly Holy Holy-Water Cannon.
Batman and Robin arrive.                                       He shoots them.

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