bcc dpmi ver1.2.0

Hello.

No.

Uncommitted memory support was recently implemented in dosemu. You have to upgrade your dosemu from CVS (to version 1.3.1) to get it working. And it will work reliably only with 2.4 kernels or with the latest 2.6.7-pre kernels because earlier 2.6 kernels have bugs in that area.
And you also should not run dosemu on any 2.6 kernels prior to 2.6.6.

True, uncommitted memory support is a DPMI 1.0 feature, but can also be implemented as a "VIRTUAL SUPPORT" API extension of DPMI 0.9, that's how it is now implemented in dosemu. Don't expect it in 1.2 versions of dosemu anytime soon however.

That's something the one should never do. You can't run any DPMI server under dosemu because dosemu have the DPMI server built in.

No.

It is called 32rtm I beleive. It can work under the 1.3.1/CVS dosemu as a DOS extender. And you can run your Borland tools.

Will CVS dosemu build against the 2.6 kernel headers? I had to use 2.4 headers for version 1.2.1 since matrox.c includes <sys/pci.h>, which in turn includes <linux/pci.h>, which, I suppose, is one of those headers we're not supposed to use anymore... :-(

sys/pci.h should be fine and non-controversial though.
In a way /usr/include/linux/pci.h isn't a true kernel header but a sanitized copy for internal use by glibc (it used to be symlinked to the kernel source but that was during libc5 times (before 1999)). A very messy situation indeed.

The problem is that this sanitized copy wasn't clean enough. You need to remove the #include <linux/mod_devicetable.h> from /usr/include/linux/pci.h. This is at least the solution from Debian when I contacted them about the problem (they fixed it last December, and that's why i didn't bother about a workaround). I don't know about other distro's but Fedora doesn't seem to have problems with pci.h, and most other ones include dosemu so that should work too.

Bart

The <sys/pci.h> for glibc 2.2.5 does nothing but include <linux/pci.h>. Version 2.3 might be different, but I'm still screwing up the courage to upgrade (it requires gcc 3, which is going to be a major PIA for me).

I wondered about that, since I didn't get the usual "don't include kernel headers" warning.

I stuck an "#ifdef __KERNEL__" around it which seems to have done the trick. Of course, now when an upgrade patch eventually fails, I'll have to somehow remember what I've done. :-)

I don't run a distribution kernel, and the developers haven't fixed it as of 2.6.6 (whenever I gripe about header bugs I get a pro forma response about not using kernel headers in applications).

If it's not fixed in 2.6.7 I'll file a bugzilla report.