DOS ain't dead

> What about adding a virtual memory into HDPMI32 like CWSDPMI has? Windows
> programs usually don't care about enough memory - they rely on virtual
> memory services provided by win kernel. There can be unpredictable results
> in case when application tries to allocate more memory than is available.

Last I heard, Japheth disliked such implementation in CWSDPMI (and maybe the idea in general for his HDPMI tools).

Of course, CWSDPMI really only implemented it because (last I heard) it started on such old machines (386) w/ low memory that it was sorely needed in order to compile most C++ apps.

I think DPMIONE supports swapping, but I've never tested it. (Anyone?)

---
Know your limits.h

> There can be unpredictable results in case when application tries to allocate
> more memory than is available.

Yes, all poorly written applications can give "unpredictable results". Smart applications catch those "out of memory" errors and report them to the user.

> What about adding a virtual memory into HDPMI32 like CWSDPMI has?

Virtual memory was crucial in the days of 2,4,8 MB machines. Nowadays it's far less important. And IMO providing virtual memory is not the task of a DPMI host if it is possible to implement it in cpu ring 3. And with HDPMI, it CAN be implemented that way.

> Windows programs usually don't care about enough memory - they rely
> on virtual memory services provided by win kernel.

I don't know what the majority of Windows programs do. But I usually have disabled virtual memory when running Windows and have no problems so far.

---
MS-DOS forever!

> What about adding a virtual memory into HDPMI32 like CWSDPMI has?

No SWAP is a feature

> Windows programs usually don't care about enough memory - they rely
> on virtual memory services provided by win kernel.

Somewhat true ... but

> There can be unpredictable results in case when application
> tries to allocate more memory than is available.

The results are pretty predictable and range from "desperately slow" to "unusably slow"

I wonder whether this request comes because of

- running of Win32 apps on HX (1)
or
- because of Blocek (2)

(1) I had no problem with HDPMI. Useful apps do work well. There are some very poorly designed apps (like "XVI32" file editor and several clones of it) that can "edit file of any size" - before editing you must "open" it, means copy the complete file into swapfile taking 5 minutes or more ... editing is slow as hell ... and finally complete file must be copied back. No loss if such stuff doesn't work on HX and never will. Also, there are several archivers (PAQ/KGB) NOT protected from swap, means you "can" compress with the "insane" level using 2 GiB of "memory" on a 512 MiB machine - but don't expect more 1 byte per second performance YES, you will have to kill it after several hours of HD running and no visible progress HDPMI32/HX is much better here - provides almost all memory to the app and if it's still not enough, the app aborts.

(2) This bug really must be fixed. I don't know whether it comes from your source, the "VendomGFX" or FPC code, but it's NOT a bug of HDPMI32. "fixing" a bug by creating an "anti-bug" never was a good idea: 25 years ago, when designing the 80286 PC, because of 1 or 2 buggy 8086 applications accessing (inexistent) memory > 1 MiB and relying the accesses to get mapped down to lowest 64 KiB of memory, the horrible A20 BUG was invented ... and persists up to now

Swapping / temp file usage can be much better implemented at application level, as used to be done on well designed 8086 software

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