[softwarelist] Re: OvPro 2.77 memory

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
  http://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: