|
|
Post by andrew on Dec 27, 2018 20:19:44 GMT 1
Prior to 2018 you had an XMEM parameter. And now it's 10MB by default.
In the 2017 version did it do anything beyond the 10MB I'm evaluating if i should move to the 2018 version right now as i'm all on 2017 right now. I'm not 100% sure how much memory my application requires but I have it set to 30MB.
|
|
|
|
Post by Jos on Dec 27, 2018 20:57:05 GMT 1
In the DOS days 10MB of extended/XMS memory was HUGE (and expensive). There will be a handful of DOS programs that could benefit from more than 10MB: Editors handling large files, perhaps a sorting program, or a ZIP program.
You might think database programs with large databases would be in need for as much memory as possible, there aren’t.
A database program typically only holds 1 or 2 logical (4KB) pages per database and index file, no matter how large the files are.
Prior to version 2018.05.01 vDos requested the conventional, followed by extended, memory from Windows. It then got a pointer to that memory that had to be stored.
So every memory access was preceded by fetching that pointer. Linking the conventional and extended memory statically, got rid of continuously loading that pointer.
The primary goal was speed, but it also eased the implementation of more than one emulated core (next version) dedicated to the operating state of the CPU.
Jos
|
|
|
|
Post by andrew on Dec 27, 2018 21:16:09 GMT 1
Ok I guess testing is in store again. While in the DOS days yes it was huge. But a lot of people are using DOS applications developed well past Windows 98 Dos which had a lot more memory. I just know the default 4 from the older version was not enough.
|
|
|
|
Post by Jos on Dec 27, 2018 21:30:50 GMT 1
Even with lots of MB’s to spare, what is a DOS program supposed to do with more than it needs?
Jos
|
|
|
|
Post by andrew on Jan 18, 2019 19:29:46 GMT 1
I'm running a foxpro based database program.
When dealing with large database files occasionally it has problems. Just like nobody back in the 10MB was huge. 1GB databases were also unheard of or even possible.
So i'm running split versions. The older and newer depending on situation.
The newer one is vastly faster. But will error out when i run out of memory or whatever the memory issue is.
|
|
|
|
Post by Jos on Jan 18, 2019 19:39:08 GMT 1
FoxProX reports too little available memory, can you post a screenshot of that messsage?
The size of a database normally doesn't affect memory requirements.
Jos
|
|
|
|
Post by andrew on Jan 18, 2019 19:55:29 GMT 1
The Prior version I tested as low as XMEM = 30MB The old default low of 4MB was way too low and I constantly run into issues. Also i'm not sure what routines this program uses to get the process done.  |
|
|
|
Post by Jos on Jan 18, 2019 20:34:44 GMT 1
The “Page fault: directory or table entry not set” is certainly not the same as too little memory.
FoxProX tries to access virtual memory that isn’t setup by the PharLap DOS extender. Increasing XMS memory was no real remedy, it postponed or reduced the change for the exception to be triggered.
It occurs when FoxProX accesses the very last part of virtual memory, and I thought this was cured by the 2018.05.01 version (so also the practical switch to a 10MB limit).
But I got 2 reports that “Page fault” reoccurred. It seems PharLap initializes the virtual memory page tables incorrectly if HMA is not in use (just available in vDos).
I expect this fixed in the next version, faking HMA isn’t available (didn’t hear again of those reporting the problem).
Jos
|
|
