swapping for HDPMI32? NO :-( (DOSX)
> 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 ***
Complete thread:
- swapping for HDPMI32? - Laaca, 11.08.2007, 15:28 (DOSX)
- swapping for HDPMI32? - Rugxulo, 11.08.2007, 22:56
- swapping for HDPMI32? GCC - DOS386, 13.08.2007, 07:14
- swapping for HDPMI32? GCC - rr, 13.08.2007, 10:16
- swapping for HDPMI32? GCC - DOS386, 16.08.2007, 09:53
- swapping for HDPMI32? GCC - rr, 13.08.2007, 10:16
- swapping for HDPMI32? GCC - DOS386, 13.08.2007, 07:14
- swapping for HDPMI32? - Japheth, 12.08.2007, 16:19
- swapping for HDPMI32? NO :-( - DOS386, 13.08.2007, 07:32
- swapping for HDPMI32? NO :-( - rr, 13.08.2007, 10:17
- swapping for HDPMI32? NO :-( - Japheth, 13.08.2007, 11:42
- swapping for HDPMI32? NO :-( - rr, 13.08.2007, 11:52
- swapping for HDPMI32? NO :-( - Japheth, 13.08.2007, 23:19
- swapping for HDPMI32? NO :-( - rr, 14.08.2007, 09:24
- swapping for HDPMI32? NO :-( - Japheth, 14.08.2007, 22:29
- swapping for HDPMI32? NO :-( - rr, 15.08.2007, 09:40
- swapping for HDPMI32? NO :-( - Japheth, 15.08.2007, 14:46
- swapping for HDPMI32? NO :-( - Japheth, 16.08.2007, 20:51
- swapping for HDPMI32? NO :-( - rr, 17.08.2007, 11:54
- swapping for HDPMI32? NO :-( - Japheth, 17.08.2007, 20:05
- swapping for HDPMI32? NO :-( - rr, 17.08.2007, 11:54
- swapping for HDPMI32? NO :-( - Japheth, 16.08.2007, 20:51
- swapping for HDPMI32? NO :-( - Japheth, 15.08.2007, 14:46
- swapping for HDPMI32? NO :-( UTF-16 NO - DOS386, 16.08.2007, 09:46
- swapping for HDPMI32? NO :-( - rr, 15.08.2007, 09:40
- swapping for HDPMI32? NO :-( - Japheth, 14.08.2007, 22:29
- swapping for HDPMI32? NO :-( - rr, 14.08.2007, 09:24
- swapping for HDPMI32? NO :-( - Japheth, 13.08.2007, 23:19
- swapping for HDPMI32? NO :-( - rr, 13.08.2007, 11:52
- swapping for HDPMI32? NO :-( - Japheth, 13.08.2007, 11:42
- swapping for HDPMI32? NO :-( - rr, 13.08.2007, 10:17
- swapping for HDPMI32? - Rugxulo, 11.08.2007, 22:56