cannot map temp file pool

cannot map temp file pool

[Jan Willem Stumpel]

I did 'nothing' (apart from the usual Debian dist-upgrades) to my
beautifully-working dosemu installation and now I get this.. sigh..

 jws@vega:~$ xdosemu

   You do not have the DOSEMU vga font installed and are running
   remote X. You need to install the vga font on your _local_
   Xserver.
   Look at the readme for details. For now we start with an fixed
   font, which does not display all national characters correctly.
   ... be warned

 ERROR: MAPPING: cannot map temp file pool, Operation not
 permitted
 ERROR: MAPPING: cannot map temp file pool, Operation not
 permitted
 Segmentation fault
 jws@vega:~$

WTH is this? No idea what "map temp file pool" means. I hope
someone is still around who can answer this. The dosemu font was
always OK, BTW.

Regards, Jan

Re: cannot map temp file pool

[Damyan Ivanov]

[-- Attachment #1: Type: text/plain, Size: 1217 bytes --]

[resent with list included]
Jan Willem Stumpel -- 19.09.2006 15:27 --:
> I did 'nothing' (apart from the usual Debian dist-upgrades) to my
> beautifully-working dosemu installation and now I get this.. sigh..
> 
>  jws@vega:~$ xdosemu
> 
>    You do not have the DOSEMU vga font installed and are running
>    remote X. You need to install the vga font on your _local_
>    Xserver.
>    Look at the readme for details. For now we start with an fixed
>    font, which does not display all national characters correctly.
>    ... be warned
> 
>  ERROR: MAPPING: cannot map temp file pool, Operation not
>  permitted
>  ERROR: MAPPING: cannot map temp file pool, Operation not
>  permitted
>  Segmentation fault
>  jws@vega:~$
> 
> WTH is this? No idea what "map temp file pool" means. I hope
> someone is still around who can answer this. The dosemu font was
> always OK, BTW.

I'd run xdosemu under strace and look for "permission denied" errors
there.



	dam
-- 
Damyan Ivanov                           Modular Software Systems
dam@modsoftsys.com
phone +359(2)928-2611, 929-3993              fax +359(2)920-0994
mobile +359(88)856-6067             dam@jabber.minus273.org/Gaim


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: cannot map temp file pool

[Jan Willem Stumpel]

Damyan Ivanov wrote:

>>WTH is this? No idea what "map temp file pool" means. I hope
>>someone is still around who can answer this. The dosemu font was
>>always OK, BTW.
> 
> 
> I'd run xdosemu under strace and look for "permission denied" errors
> there.

I tried that -- but could not make sense of it. I get things like

open("/dev/shm/dosemu_16975", O_RDWR|O_CREAT|O_TRUNC|O_NOFOLLOW,
0600) = 5
fcntl64(5, F_GETFD)                     = 0
fcntl64(5, F_SETFD, FD_CLOEXEC)         = 0
unlink("/dev/shm/dosemu_16975")         = 0
ftruncate(5, 0)                         = 0
ftruncate(5, 15794176)                  = 0
mmap2(NULL, 15794176, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_SHARED,
5, 0) = -1 EPERM (Operation not permitted)
write(4, "ERROR: MAPPING: cannot map temp "..., 67) = 67
write(2, "ERROR: MAPPING: cannot map temp "..., 67) = 67

15794176 is some suspiciously "round" number (hex 00F10000).

I'd appreciate any ideas.

Regards, Jan

Re: cannot map temp file pool

[Robert Komar]

On Tue, 19 Sep 2006, Jan Willem Stumpel wrote:

> open("/dev/shm/dosemu_16975", O_RDWR|O_CREAT|O_TRUNC|O_NOFOLLOW,
> 0600) = 5
> fcntl64(5, F_GETFD)                     = 0
> fcntl64(5, F_SETFD, FD_CLOEXEC)         = 0
> unlink("/dev/shm/dosemu_16975")         = 0
> ftruncate(5, 0)                         = 0
> ftruncate(5, 15794176)                  = 0
> mmap2(NULL, 15794176, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_SHARED,
> 5, 0) = -1 EPERM (Operation not permitted)

The man page for mmap suggests that you get EPERM when you ask for
PROT_EXEC but tmpfs was mounted no-exec.  You should check the
mount options for tmpfs, I think.

Cheers,
Rob Komar

Re: cannot map temp file pool

[Mike McCarty]

Jan Willem Stumpel wrote:
> Damyan Ivanov wrote:
> 
> 
>>>WTH is this? No idea what "map temp file pool" means. I hope
>>>someone is still around who can answer this. The dosemu font was
>>>always OK, BTW.
>>
>>
>>I'd run xdosemu under strace and look for "permission denied" errors
>>there.
> 
> 
> I tried that -- but could not make sense of it. I get things like

These things make some sense to me. Perhaps I can help. Someone with
the source can help better.

> open("/dev/shm/dosemu_16975", O_RDWR|O_CREAT|O_TRUNC|O_NOFOLLOW,
> 0600) = 5

open(.,.,.) opens files or devices for reading or writing, and
returns a small positive integer on success. This integer is
used for later calls to do things to the file or device.
If it fails, it returns -1. This indicates successful open
on /dev/shm/dosemu_16975 with READ+WRITE, CREATE if non-existent,
TRUNCATE an existing file and reuse it, do NOT FOLLOW links.

Now, /dev/shm is SHARED MEMORY. It is there to allow multiple
processes to access the same memory area without having to
use interprocess communication. There is no file involved.

The open channel number (FD or File Descriptor) is 5.

> fcntl64(5, F_GETFD)                     = 0

fcntl(fd,option,...) does various File CoNTroL operations.
It returns 0 for success, -1 for an error. FD number 5 (return
from above open) was successfully queried.

   F_GETFD
        Read  the  close-on-exec flag.  If the FD_CLOEXEC bit is 0, the
        file will remain open across exec, otherwise it will be closed.
 

> fcntl64(5, F_SETFD, FD_CLOEXEC)         = 0

Again, FD 5 has had an option set successfully.

  F_SETFD
        Set  the  close-on-exec  flag  to  the  value  specified by the
        FD_CLOEXEC bit of arg.

In this case, set to TRUE.

> unlink("/dev/shm/dosemu_16975")         = 0

The "file" has been "removed". This means it has been marked
by the system for removal. But it is still open (we guess,
since no close() has been done), so the "file" still exists,
but when it is closed, it will automagically go away.

IOW, when all processes have relinquished access to the
shared memory (like by exiting to the system), then the
shared memory will be returned to the pool.

> ftruncate(5, 0)                         = 0

ftruncate(Fd,Size) sets the size of a file. I suppose
that in the case of shared memory, it resizes it. This
is a successful call.

> ftruncate(5, 15794176)                  = 0

Ditto. It successfully changed FD 5 to 15794176 bytes.

> mmap2(NULL, 15794176, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_SHARED,
> 5, 0) = -1 EPERM (Operation not permitted)

This is a POSIX call, IIRC.

This call has failed. mmap2() attempts to map a shared memory region
to a real process relative memory address so it can do accesses.
 
      void * mmap2(void *start, size_t length, int prot, int flags, int  fd,
        off_t pgoffset);

start	the requested start location in memory; this is only a
	suggestion, and the system may not use the requested
	address. NULL means you are willing to accept whatever
	the system gives you (which is what is going to happen,
	anyway)

length	number of bytes to map to the process memory

prot	access protection requested

flags	some access flags

fd	File Descriptor (5 in this case, our shared memory region)

pg_offset	offset into the shared memory region to start
		mapping. In this case, no beginning piece
		is skipped over, we want it all.


This call, when it succeeds, returns a pointer to the shared memory
region. Again, this was done on FD 5. The requested
permissions are READ, WRITE, EXECUTE, flags are SHARED access.
The return indicates that the operation failed (-1) and
the errno indicates PERMISSION DENIED.

So, it appears that something is wrong with your permissions
on /dev/shm/dosemu_16975.

$ ls -ld /dev/shm
drwxrwxrwt  2 root root 40 Sep  8 06:57 /dev/shm

My shared memory is accessible to everyone, apparently.

I wonder whether your permission bits are incorrect on
/dev/shm.

> write(4, "ERROR: MAPPING: cannot map temp "..., 67) = 67

This is a successful attempt to write some byes to
FD 4 (probably some log file). It tried to write 67 bytes,
and wrote 67 bytes. This is a successful call, probably
reporting the mmmap2() failure.

> write(2, "ERROR: MAPPING: cannot map temp "..., 67) = 67

This is a successful attempt to write to FD 2 (stderr, the
standard error reporting file, likely your display) probably
the very same message.

> 15794176 is some suspiciously "round" number (hex 00F10000).

It's the length of the mapped area. It's normal for this
to be a "round" number.

> I'd appreciate any ideas.

Well, hopefully I've given you some.

Mike
-- 
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
You have found the bank of Larn.
I can explain it for you, but I can't understand it for you.
I speak only for myself, and I am unanimous in that!

Re: cannot map temp file pool

[Jan Willem Stumpel]

Mike McCarty wrote:
> Jan Willem Stumpel wrote:
> So, it appears that something is wrong with your permissions
> on /dev/shm/dosemu_16975.
> 
> $ ls -ld /dev/shm
> drwxrwxrwt  2 root root 40 Sep  8 06:57 /dev/shm
> 
> My shared memory is accessible to everyone, apparently.
> 
> I wonder whether your permission bits are incorrect on
> /dev/shm.

Well, in the first place, sincere thanks for your reply (and also
thanks to the others who replied, whose messages I still have to
digest). It seems that while development of dosemu has stopped,
the list is still very much alive.

But..

 jws@vega:~$ ls -ld /dev/shm
 drwxrwxrwt 3 root root 60 2006-09-19 17:24 /dev/shm

The permissions seem the same.

Regards, Jan

Re: cannot map temp file pool

[Robert Komar]

On Tue, 19 Sep 2006, Jan Willem Stumpel wrote:

> Mike McCarty wrote:
>> Jan Willem Stumpel wrote:
>> So, it appears that something is wrong with your permissions
>> on /dev/shm/dosemu_16975.
>>
>> $ ls -ld /dev/shm
>> drwxrwxrwt  2 root root 40 Sep  8 06:57 /dev/shm
>>
>> My shared memory is accessible to everyone, apparently.
>>
>> I wonder whether your permission bits are incorrect on
>> /dev/shm.
>
> Well, in the first place, sincere thanks for your reply (and also
> thanks to the others who replied, whose messages I still have to
> digest). It seems that while development of dosemu has stopped,
> the list is still very much alive.
>
> But..
>
> jws@vega:~$ ls -ld /dev/shm
> drwxrwxrwt 3 root root 60 2006-09-19 17:24 /dev/shm
>
> The permissions seem the same.

It's not just the permissions that are important, but whether you
can directly execute files within the temporary filesystem.  Run
'mount' and see if tmpfs is mounted with the 'noexec' option.
If it is, then that's at least one of your problems.

Cheers,
Rob Komar

Re: cannot map temp file pool

[Alain M.]

Jan Willem Stumpel escreveu:
> 
> It seems that while development of dosemu has stopped,
> the list is still very much alive.

Well, this is very common in Linux programs. It works... so if someone 
needs something *more* then it's a different story :)

Alain

Re: cannot map temp file pool

[Jan Willem Stumpel]

Robert Komar wrote:

> It's not just the permissions that are important, but whether
> you can directly execute files within the temporary filesystem.
> Run 'mount' and see if tmpfs is mounted with the 'noexec'
> option. If it is, then that's at least one of your problems.

Aha..

vega:/home/jws# mount
/dev/hda5 on / type ext2 (rw,errors=remount-ro)
proc on /proc type proc (rw,noexec,nosuid,nodev)
/sys on /sys type sysfs (rw,noexec,nosuid,nodev)
devshm on /dev/shm type tmpfs (rw)
devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=620)
usbfs on /proc/bus/usb type usbfs (rw,noexec,nosuid,nodev)
/dev/hda6 on /dosd type vfat (rw,noexec,nosuid,nodev,umask=000)
automount(pid2284) on /misc type autofs
(rw,fd=4,pgrp=2284,minproto=2,maxproto=4)
rpc_pipefs on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
vega:/home/jws#

There doesn't seem to be a filesystem actually called tmpfs but
there is devshm which has the "type" tmpfs.

Is this a clue? Maybe I should make some link. I wonder what
tricks were performed by my latest Debian dist-upgrade.

For completeness, here is /etc/fstab:

# /etc/fstab: static file system information.
#
# <file system><mount point><type><options>      <dump><pass>
/dev/hda5      /        ext2  defaults,errors=remount-ro  0 1
/dev/hda6      /dosd    vfat  defaults,rw,user,umask=000  0 0
/dev/hda7      none     swap  sw                          0 0
proc           /proc    proc  defaults                    0 0
/dev/fd0       /floppy  auto  defaults,user,noauto        0 0
/dev/hdc       /cdrom   iso9660 defaults,ro,user,noauto   0 0
/dev/hdd       /cdrw    iso9660 defaults,user,noauto      0 0
procyon:/      /nfs     nfs   defaults,noauto,rw          0 0
vega:/home/jws#

There is no tmpfs, but there never was, and dosemu always worked
(until today).

Regards, Jan

Re: cannot map temp file pool

[Bart Oldeman]

Hi Jan Willem,

it's an issue with the 'initscripts' Debian package, in
/etc/init.d/mountdevsubfs.sh

Hopefully it's only temporary: it also breaks UML
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=386945

The DOSEMU source code could probably work around it by mmap()ing READ|WRITE
and then mprotect it with EXEC. But maybe at some future point someone
will restrict mprotect() to report EPERM in such situations too for
security reasons.

Anyway. another way to work around it is to change $_mapping. If you set it to
"mapashm" or "mapfile" then dosemu should work again.

Bart

Re: cannot map temp file pool

[Mike McCarty]

Bart Oldeman wrote:
> Hi Jan Willem,
> 
> it's an issue with the 'initscripts' Debian package, in
> /etc/init.d/mountdevsubfs.sh
> 
> Hopefully it's only temporary: it also breaks UML
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=386945
> 
> The DOSEMU source code could probably work around it by mmap()ing 
> READ|WRITE
> and then mprotect it with EXEC. But maybe at some future point someone
> will restrict mprotect() to report EPERM in such situations too for
> security reasons.

I don't understand why SHARED MEMORY needs execution access, anyway.

This looks like a defect in the code to me.

Mike
-- 
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
You have found the bank of Larn.
I can explain it for you, but I can't understand it for you.
I speak only for myself, and I am unanimous in that!

Re: cannot map temp file pool

[Bart Oldeman]

On 9/19/06, Mike McCarty <Mike.McCarty@sbcglobal.net> wrote:
>
> I don't understand why SHARED MEMORY needs execution access, anyway.
>
> This looks like a defect in the code to me.

DOSEMU needs shared memory for things like the HMA and EMS that are
mapped multiple times. E.g. the 64K at 1MB must be able to wrap and so
point to the same address as 0. The only way to accomplish that in
Linux is too use either shared memory or a temporary file (slower).

DOS programs execute in this memory, so the memory needs to be executable.

Bart

Re: cannot map temp file pool

[Jan Willem Stumpel]

Bart Oldeman wrote:

> Anyway. another way to work around it is to change $_mapping.
> If you set it to "mapashm" or "mapfile" then dosemu should work
> again.

Thanks a lot. This worked.

Regards, Jan

Re: cannot map temp file pool

[Mike McCarty]

Jan Willem Stumpel wrote:
> Bart Oldeman wrote:
> 
> 
>>Anyway. another way to work around it is to change $_mapping.
>>If you set it to "mapashm" or "mapfile" then dosemu should work
>>again.
> 
> Thanks a lot. This worked.

GREAT! But, why did it fail in the first place?

Mike
-- 
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
You have found the bank of Larn.
I can explain it for you, but I can't understand it for you.
I speak only for myself, and I am unanimous in that!

Re: cannot map temp file pool

[Jan Willem Stumpel]

Mike McCarty wrote:
> Jan Willem Stumpel wrote:
> 
>> Bart Oldeman wrote:
>>
>>
>>> Anyway. another way to work around it is to change $_mapping.
>>> If you set it to "mapashm" or "mapfile" then dosemu should work
>>> again.
>>
>>
>> Thanks a lot. This worked.
> 
> 
> GREAT! But, why did it fail in the first place?

The immediate reason has been pointed out by Bart. A change in the
Debian initscripts package. The latest version in which dosemu
worked by default is initscripts_2.86.ds1-15_i386.deb. Last
Saturday, this was replaced by initscripts_2.86.ds1-20_i386.deb.
So the breakage seems to be Debian-specific (for now).

One of the "initscripts" is /etc/init.d/mountdevsubfs.sh, which
contains line like

(version 15, does not break dosemu)
   SHM_OPT=
    [ "${SHM_SIZE:=$TMPFS_SIZE}" ] &&  SHM_OPT="-osize=$SHM_SIZE"
    domount tmpfs shmfs /dev/shm $SHM_OPT

("improved" version 20, breaks dosemu)
   SHM_OPT=
    [ "${SHM_SIZE:=$TMPFS_SIZE}" ] && SHM_OPT=",size=$SHM_SIZE"
    domount tmpfs shmfs /dev/shm -onoexec,nosuid,nodev$SHM_OPT

This must have been done for security reasons, although I have no
clue about (the severity of) the security issues which are at
stake here.

I do not know why the Debian maintainer of dosemu himself did not
tweak to this breakage. Or maybe he did, and the Debian version of
dosemu now has a different $_mapping default. Haven't checked this
yet. Though a Debian user, I've been compiling my own dosemu from
source for years, not liking Debian's dosemu package (see my
"dosemu for dummies" page).

Regards, Jan

Re: cannot map temp file pool

[Mike McCarty]

Jan Willem Stumpel wrote:
> Mike McCarty wrote:
>>GREAT! But, why did it fail in the first place?
> 
> The immediate reason has been pointed out by Bart. A change in the

[snip]

> One of the "initscripts" is /etc/init.d/mountdevsubfs.sh, which
> contains line like
> 
> (version 15, does not break dosemu)
>    SHM_OPT=
>     [ "${SHM_SIZE:=$TMPFS_SIZE}" ] &&  SHM_OPT="-osize=$SHM_SIZE"
>     domount tmpfs shmfs /dev/shm $SHM_OPT
> 
> ("improved" version 20, breaks dosemu)
>    SHM_OPT=
>     [ "${SHM_SIZE:=$TMPFS_SIZE}" ] && SHM_OPT=",size=$SHM_SIZE"
>     domount tmpfs shmfs /dev/shm -onoexec,nosuid,nodev$SHM_OPT

Ah, I see. Very clear.

> This must have been done for security reasons, although I have no
> clue about (the severity of) the security issues which are at
> stake here.

[snip]

Hmm. Self-modifying code permitting one to insert code into
a shared memory region and execute it? Difficult to catch
with a "scanner" I suppose.

Thanks for the response.

Mike
-- 
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
You have found the bank of Larn.
I can explain it for you, but I can't understand it for you.
I speak only for myself, and I am unanimous in that!

Re: cannot map temp file pool

[Claudia Neumann]

Hi!

Am Mittwoch, 20. September 2006 19:03 schrieb Jan Willem Stumpel:
> I do not know why the Debian maintainer of dosemu himself did not
> tweak to this breakage. Or maybe he did, and the Debian version of
> dosemu now has a different $_mapping default. Haven't checked this
> yet. Though a Debian user, I've been compiling my own dosemu from
> source for years, not liking Debian's dosemu package (see my
> "dosemu for dummies" page).

I have surged the new Debian maintainer to update the Debian dosemu package. 
It is still 1.2.1 and I am afraid it will stay like this because the current 
maintainer has not done a bit. I suspect that the current maintainer has not 
even used dosemu himself. So if you want to use a current dosemu in Debian, 
you have to compile it yourself.  :(
 
Regards

Claudia

Re: cannot map temp file pool

[Jan Willem Stumpel]

Claudia Neumann wrote:
> Hi!
> I have urged the new Debian maintainer to update the Debian
> dosemu package. It is still 1.2.1 and I am afraid it will stay
> like this because the current maintainer has not done a bit. I
> suspect that the current maintainer has not even used dosemu
> himself. So if you want to use a current dosemu in Debian, you
> have to compile it yourself.  :(

Actually, in Debian Sid (unstable), it is now 1.2.2.

But this was introduced only last June, and it has the default
$_mapping = "". So it is guaranteed not to work on a updated
Debian Sid system.

Something must be wrong in the communication (two-way) between
Debian and dosemu..

It would be a pity if dosemu would die, either by the present
conflict among the developers, or by neglect by the major
distributions. There are many legacy DOS programs out there which
are still actively used. I get between 100 and 200 non-robot hits
every week on my dosemu page alone. There is still interest in
this project "out there".

Regards, Jan

Re: cannot map temp file pool

[Claudia Neumann]

Am Donnerstag, 21. September 2006 13:17 schrieben Sie:
> Claudia Neumann wrote:
> > Hi!
> > I have urged the new Debian maintainer to update the Debian
> > dosemu package. It is still 1.2.1 and I am afraid it will stay
> > like this because the current maintainer has not done a bit. I
> > suspect that the current maintainer has not even used dosemu
> > himself. So if you want to use a current dosemu in Debian, you
> > have to compile it yourself.  :(
>
> Actually, in Debian Sid (unstable), it is now 1.2.2.
>
> But this was introduced only last June, and it has the default
> $_mapping = "". So it is guaranteed not to work on a updated
> Debian Sid system.
>
> Something must be wrong in the communication (two-way) between
> Debian and dosemu..
>
> It would be a pity if dosemu would die, either by the present
> conflict among the developers, or by neglect by the major
> distributions. There are many legacy DOS programs out there which
> are still actively used. I get between 100 and 200 non-robot hits
> every week on my dosemu page alone. There is still interest in
> this project "out there".

Agreed!!

Regards

Claudia

Re: cannot map temp file pool

[Stas Sergeev]

Hello.

> It would be a pity if dosemu would die, either by the present
> conflict among the developers
You probably meant a past conflict. It is long-time
over with an apparent consequences. What is still
missing is only an "official" anouncement about these
consequences to help people (including distributors)
make their minds straight. We all can see the development
stopped, but it will help a lot if this is said explicitly
or refuted, so that people can think what to do next.

> or by neglect by the major distributions.
That tradition comes from an older times when dosemu used
to urge the users to run it as root, when the dosemu.org's
page had a jokes about RedHat (calling it "Colored Cap") etc.
And now the non-portable software doesn't rate by distributors
at all.

> There are many legacy DOS programs out there which
> are still actively used.
Have you evaluated dosbox? I did - works for games, doesn't
work for work (lacks serial port emulation which I need).

Re: cannot map temp file pool

[Jan Willem Stumpel]

Stas Sergeev wrote:
> Hello.
> 
>> It would be a pity if dosemu would die, either by the present
>> conflict among the developers [..]
> 
> You probably meant a past conflict. It is long-time
> over [..]

That is good news.

> missing is only an "official" anouncement about these
> consequences to help people (including distributors)
> make their minds straight. We all can see the development
> stopped, but it will help a lot if this is said explicitly
> or refuted, so that people can think what to do next.

I am a bit confused. Will development continue (including
incorporating your new sound system) or not?

> Have you evaluated dosbox? I did - works for games, doesn't
> work for work (lacks serial port emulation which I need).

My impression is that dosbox can run any program -- but only one
program at the time. You do not get a complete DOS system in which
you can switch between different programs. E.g. Fixed Disk
Organizer does not work. It is nor "for work" indeed.

Still, dosbox is an excellent program. It even runs those amazing
"demo scene" programs from the early 90's, like "Amnesia" (still
available from e.g. http://www.mindcandydvd.com/demos). For games,
dosbox is fine. And of course it is portable.

Regards, Jan

Re: cannot map temp file pool

[Stas Sergeev]

Hello.

Jan Willem Stumpel wrote:
>> You probably meant a past conflict. It is long-time
>> over [..]
> That is good news.
Hmm. The result of that conflict was my quit and the
development stop. Probably not very good. But that's
the past.

> I am a bit confused. Will development continue (including
> incorporating your new sound system) or not?
That's what I'd like to find out too. Since I have not
been able to replace dosemu with dosbox at work, and since
I now have the amd64 boxes both at home and at work, I need
the reliable x86_64 port (no, the current one doesn't suit me
at all). To decide whether to start working on it on my own,
I need to know this first.

> Still, dosbox is an excellent program. It even runs those amazing
> "demo scene" programs from the early 90's, like "Amnesia" (still
Doesn't run under dosemu even with the sound patch?

Re: cannot map temp file pool

[Jan Willem Stumpel]

Stas Sergeev wrote:

>> Still, dosbox is an excellent program. It even runs those amazing
>> "demo scene" programs from the early 90's, like "Amnesia" [..]
> 
> Doesn't run under dosemu even with the sound patch?

It refuses to start. Other "demos" simply crash dosemu.

Regards, Jan