[softwarelist] Re: OvPro 2.77 memory
- From: Martin Wuerthner <public@xxxxxxxxxxxxxxx>
- To: davidpilling@xxxxxxxxxxxxx
- Date: Wed, 15 Nov 2006 15:56:47 +0100
In message <s27T$oBr4xWFFwJz@xxxxxxxxxxxxxxxxxxx>
David Pilling <flist@xxxxxxxxxxxxxxxxxxx> wrote:
> In message <DnDI7WALIgWFFwcl@xxxxxxxxxxxxxxxxxxx>, David Pilling
> <flist@xxxxxxxxxxxxxxxxxxx> writes
>>I'd be inclined to see how far I could drag the max mem slot in SparkFS
>>- I forget if you can drag the OP dynamic area slider.
>
> Well right idea David, but no use in practice. Later versions of SparkFS
> are set up to not claim a dynamic area of the maximum size, and OP no
> longer has a slider you can drag.
>
> Thanks to Martin for taking the trouble to write out an explanation.
>
> I feel there should be somewhere that standard catches are written up.
> Dynamic areas are one such saga, PostScript printer drivers are another.
> It often takes many postings for the situation to be completely
> explained, and then a day later it can all start again.
But fortunately, there are mailing list archives, so in the future,
you could just point to
//www.freelists.org/archives/davidpilling/11-2006/msg00019.html
for an explanation of the issue.
Amongst all the technical information, one of the reasons for my
posting was to point out that OvationPro could probably do better than
it currently does by
a) giving users an option whether to create a maximum size DA or a
limited size DA with a configurable size
b) using WimpSlot memory on systems without the 28MB memory limit
ad a) Quite a few applications allow this to be set up in their !Run
files, e.g., MessengerPro:
| set Maximum dynamic area size to 64MB
SetEval Messenger$DynamicAreaSize 64*1024*1024
So, OvationPro could be changed to only create a maximum size DA if
OvationPro$DynamicAreaSize is unset and otherwise (i.e., if the
variable is set) evaluate the variable to pass the user's preferred
maximum size when creating the DA.
This seemed like a good idea until I noticed that the standard DALimit
program that is run as part of the boot sequence sets ALL dynamic area
clamps to 128MB, so explicit claims for more than 128MB are clamped to
128MB, too. So, to allow OvationPro to use more than 128MB, the user
would also have to increase the second clamp value in
Choices.Boot.PreDesk.DALimit from 128*1024*1024 to the desired size
(and hope that the second, less important, clamp was not really needed
to stop the system from running out of logical address space).
This makes it a slightly long-winded procedure to set up and the user
would need to understand the address space issues, but then, it would
only be needed by the very few users who really require OP to handle
massive amounts of memory.
ad b) It would be good if OvationPro could revert to using only
standard WimpSlot memory when running on a system with big wimp slots
(Wimp_ReadSysInfo 11 returns the maximum Wimp slot size). That would
allow it to use 512MB when running on RISC OS 5 (without Aemulor)
without any negative side effects.
Martin
--
---------------------------------------------------------------------
Martin Wuerthner MW Software martin@xxxxxxxxxxxxxxx
---------------------------------------------------------------------
Other related posts:
