DOS ain't dead

(for those who don't read comp.os.msdos.djgpp often):

Charles Sandmann writes:

I would like to announce the beta for CWSDPMI release 7.

The purpose of this release is to allow high performance access to large
amounts of physical memory (up to 4GB).  Memory above 32-bit address space
(common on machines over 3GB physical memory) will be mapped to fill the
address hole to provide a full 4GB memory.  4MB pages will be automatically
used for large memory requests.  Release 7 also includes the bug fixes
included in the release 5 2008 refresh, and improved 4MB page support included in the never completed r6.

Current DJGPP releases support large memory allocation requests and with
CWSDPMI release 7 allow a contiguous memory block over 4091MB.  This
CWSDPMI release is dedicated to those few dozen people who want to prove
their 4GB+ computers can actually run 4GB 32-bit applications.

For those who need more than 4GB, I'll provide some code that allows you
to map 5GB+ memory (up to 64GB) into the address space on request.
The next release will probably be when I get several people bugging me that
64GB isn't enough under DOS

Binary Distribution:  http://clio.rice.edu/djgpp/beta/csdpmi7b.zip
Source Distribution:  http://clio.rice.edu/djgpp/beta/csdpmi7s.zip

Please send me any comments or bug reports.
Have fun, and thanks for testing !


---
Know your limits.h

This most likely means that this version of CWSDPMI will install its own and -inevitably - proprietary handler for physical memory access beyond the 4 GB barrier. This makes it incompatible with any programs which also want to access or manage this memory.

I don't like this approach. There exist plans to extend some memory managers - JemmEx and XMGR - to also use this memory. They won't cooperate with this CWSDPMI version.

---
MS-DOS forever!

> I don't like this approach. There exist plans to extend some memory
> managers - JemmEx and XMGR - to also use this memory. They won't cooperate
> with this CWSDPMI version.

How does it work in current CWSDPMI? I think that if there's XMS manager CWSDPMI ask it and if no XMS manager present then it use it's own memory manager? The same should work for CWSDPMI 7 when such XMS manager will be available and currently it will handle it itself.

BTW what about v6? It was stopped/transformed to v7?

---
DOS gives me freedom to unlimited HW access.

> > I don't like this approach. There exist plans to extend some memory
> > managers - JemmEx and XMGR - to also use this memory. They won't
> cooperate
> > with this CWSDPMI version.

E-mail CWS himself and tell him your plans, ideas, etc. It's not a final, just a beta! He welcomes testers and comments.

> BTW what about v6? It was stopped/transformed to v7?

r6 had preliminary 4 MB pages but was buggy. Yes, indeed this one was also known as r6 until very very last minute, and he decided to just rename it (probably to prevent confusion). BTW, old public r6 (2003?) erroneously reported "5.00" to int 31h, 401h "get DPMI capabilities".

> How does it work in current CWSDPMI?

5 ???

> I think that if there's XMS manager CWSDPMI ask
> it and if no XMS manager present then it use it's own memory manager?

YES. No XMS host -> raw mode

> BTW what about v6? It was stopped/transformed to v7?

v6 did deserve the DEATH. It has been around since 2001 but never properly announced and apparently some (C) / version stuff inside was not even updated.

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***