Mail Archives: djgpp-workers/1997/09/30/10:06:51
> After some consideration, I've decided to do what I can to turn CWSDPMI
> into a 32-bit program. I won't be able to do that all by myself, but it's
> better than nothing :-)
Morten Welinder started that effort about 2 years ago, and was about 1/3
finished before he and I both got buried in real life responsibilites which
prevented us from finishing the re-write of CWSDPMI into MWDPMI, a real
DPMI 1.0 host, with minimal DOS memory footprint. There was a minimal
amount of code written in DJASM to bootstrap the 32-bit DPMI kernel, which
was written in GCC. If anyone wants to futz with DPMI, this is the
project to start from, period. Morten writes awesome code.
At one time the code was ftpable from riceng (before it died) and I haven't
tried to find a copy of his most recent code to put on the replacement
ftp site (which is built, with anon ftp, but is at work instead of rice...)
I may be begging for someone to send me a copy of this back...
The rest of your layout sounds like returning to the extender concept,
which was a nightmare for maintenance, and I strongly disagree with it.
The ONLY way to communicate with any non-DOS environment (like Windows, NT,
OS/2, DOSEMU, ...) is via DPMI. Re-writing the entire libc to be non-DPMI
compliant would be a disaster.
What problem are you trying to solve here? CWSDPMI low memory footprint?
Lack of DPMI 1.0 features? Target your effort to the real problem. If
a free, reliable DPMI 1.0 provider is available, someone can enhance DJGPP
to recognize this and use those features. This would include a separate
run-time expandable stack, support for nested 16-bit dpmi programs, and
several other good things. An environment which won't run under anthing
except native DOS will essentially be ignored. You can always go back to
DJGPP v1.09 ...
- Raw text -