Actually very close to all of existing application DLLs may be loaded high. This option should be considered stable and used extensively.
Yes... I am beginning to understand that. It brings up a new question: when should 'shared memory' be used and when 'high memory'? What are the advantages and disadvantages? Is 'shared memory' for shared code? If so, it would seem like QT, Java and Odin would be better off staying in shared memory. If they are loaded high, are they not shared among different apps? I'm just trying to get my head around how this dual memory concept is supposed to be used....
There are (
DISCLAIMER:
this is how I understand and what I know, I may be highly inaccurate, or even completely wrong! Think on your own!) generally four user memory arenas: low (<512 MiB) private and shared and high (>=512 MiB) private and shared ones. Yes, shared memory is for shared objects like DLLs, which are Qt (it's spelled Qt, not QT) and Odin (partly).
Dividing memory on low and high memory arenas make it possible to seamlessly run 16-bit applications, which is one of the greatest advantages of OS/2 (well, was?).
Low memory is also used for interaction with device drivers, as the current way it is organized limits it to low memory: the main driver code may be 32-bit, but some external parts of it must be 16-bit (it is possible it will get changed within the OS/4 project).
There are possibly some other places where low memory must be used, but that shouldn't be significant, as the amounts of memory used by system components are hardly comparable to the amounts used by modern applications like FFox or AOO.
When you mark a DLL as loadable high, it gets loaded to the
high shared arena, which means that it's still shared, as well as that scarce low memory (limited to 512 megs minus amount of allocated low private memory) isn't wasted.