Coding for High Memory
Jim Moe
Can any one suggest a resource that explains how to have applications
use High Memory?
--
jmm (hyphen) list (at) sohnen-moe (dot) com
(Remove .AXSPAMGN for email)
Lars Erdmann
> Hello,
> Can any one suggest a resource that explains how to have applications
> use High Memory?
>
4.52 kernel and you have to specify something like
VIRTUALADDRESSLIMIT=3072
to make room for high memory in the system arena. The example would give
you an additional memory space for private and shared memory from 512 MB
to 3072 MB. Specifying VIRTUALADDRESSLIMIT=512 would therefore not give
you any high memory (as it was in Warp 4).
1.)
If you allocate memory during runtime:
DosAllocMem(&pMem,ulLen,...|OBJ_ANY);
Be aware that pMem cannot be passed to a 16-bit function or to a
function that directly or indirectly calls a 16-bit function making use
of that address as the linear 32-bit address pMem allocated in high
memory address space cannot be thunked to a virtual 16:16 address.
2.)
If you have a DLL, you can let the program loader load its code and data
segments into high memory by using the newest exehdr.exe. If you do not
have the Warp 4.52 toolkit you can get a fairly new version of
exehdr.exe here:
http://www.os2site.com/sw/dev/util/exehdr001020.zip
The output of "exehdr.exe /?" should look something like this:
Operating System/2 Executable File Header Utility
Version 4.01.003 Dec 11 2003
Copyright (C) IBM Corporation 1988-2003
Copyright (C) Microsoft Corp. 1988-1992.
All rights reserved.
Usage: EXEHDR [options] filename...
Valid options are:
/?
/HEAP:(0H - ffffH)
/HELP
/HIGHMEM[:num[,num...]]
/NOHIGHMEM[:num[,num...]]
/MAX:(0H - ffffH)
/MIN:(0H - ffffH)
/NEWFILES
/NOLOGO
/PMTYPE:(PM | VIO | NOVIO | WINDOWAPI | WINDOWCOMPAT |
NOTWINDOWCOMPAT)
/RESETERROR
/STACKDOS:(0H - ffffH)
/STACKOS2:(0H - ffffffffH)
/VERBOSE
You can then run:
exehdr.exe /HIGHMEM mydll.dll
Again, the data loaded in high memory cannot be accessed by a 16-bit
function or by a function that directly or indirectly calls a 16-bit
function making use of the data address.
3.) You will find the OS/2 APIs that can take high memory addresses in
this INF file:
http://www.os2.com/file_d/text/ADIWSEB.ZIP
That's it.
Regards,
Lars
Steven Levine
at 02:37 PM, Jim Moe <jmm-list...@sohnen-moe.com> said:
> Can any one suggest a resource that explains how to have applications
>use High Memory?
It's pretty straightforward. Just add OBJ_ANY to the DosAllocMem() call.
The Programming Guide and Reference Addendum lists the APIs that support
upper memory.
You might want to do a Google Groups search of comp.os.os2.* for OBJ_ANY
the see the comments and caveats.
To load your app's DLLs in upper memory, you would use an exehdr.exe that
supports the /highmem switch.
Note that the heap managers for the typical runtimes do no support use of
upper memory. If you are developing with OpenWatcom, this can be
corrected relatively easily. If you are using something else, it may be
more difficult.
Steven
--
--------------------------------------------------------------------------------------------
Steven Levine <ste...@earthlink.bogus.net> MR2/ICE 2.67 #10183
Warp/eCS/DIY/14.103a_W4 www.scoug.com irc.fyrelizard.com #scoug (Wed 7pm PST)
--------------------------------------------------------------------------------------------
Steven Levine
at 01:45 AM, Lars Erdmann <lars.e...@arcor.de> said:
Hi,
>0.) To prepare your system for use of high memory, you have to have a
>4.52 kernel and you have to specify something like
>VIRTUALADDRESSLIMIT=3072
>to make room for high memory in the system arena.
I would advise against anything this large. It definitely break Acrobat5
and can cause AGP apeture problem on some systems.
My experience is that 2048 is safe. The default of 1024 provides 512MB of
upper memory out of the box.
Regards,
Rich Walsh
> Jim Moe schrieb:
>
> If you have a DLL, you can let the program loader load its code and
> data segments into high memory by using the newest exehdr.exe.
This is highly ill-advised. The feature has an unresolved bug that
causes the kernel to trap. When used with Mozilla, this would occur
about 1 time out of 4 - in the case of Moz, always while closing the
app and always resulting in the complete disappearance of files like
bookmarks or prefs.js. For a while, I had virtually all of 32-bit
PM running high but it wasn't immune from the problem either.
Here's a quote from Scott G. dated Thu, 12 Jan 2006, message ID
<oduxf.188$or4...@newssvr12.news.prodigy.com>:
> I decided that, like a couple of other things I wanted to do, that
> there wasn't enough customer demand to justify the extra testing
> effort to make it really rock-solid. So, no, it's still kind of
> flakey. :-(
--
== == almost usable email address: rich AT e-vertise.com == ==
Herbert Rosenau
wrote:
> 2.)
> If you have a DLL, you can let the program loader load its code and data
> segments into high memory by using the newest exehdr.exe. If you do not
> have the Warp 4.52 toolkit you can get a fairly new version of
> exehdr.exe here:
> http://www.os2site.com/sw/dev/util/exehdr001020.zip
> The output of "exehdr.exe /?" should look something like this:
>
> Operating System/2 Executable File Header Utility
> Version 4.01.003 Dec 11 2003
> Copyright (C) IBM Corporation 1988-2003
> Copyright (C) Microsoft Corp. 1988-1992.
> All rights reserved.
Download, unzip to its own directory gives me only
[E:\tools\exehdr].\exehdr /?
Operating System/2 Executable File Header Utility
Version 4.00.005 Oct 20 2000
Copyright (C) IBM Corporation 1988-2000
Copyright (C) Microsoft Corp. 1988-1992.
All rights reserved.
Usage: EXEHDR [options] filename...
Valid options are:
/?
/HEAP:(0H - ffffH)
/HELP
/MAX:(0H - ffffH)
/MIN:(0H - ffffH)
/NEWFILES
/NOLOGO
/PMTYPE:(PM | VIO | NOVIO | WINDOWAPI | WINDOWCOMPAT |
NOTWINDOWCOMPAT)
/RESETERROR
/STACK:(0H - ffffH)
/VERBOSE
that is an older version than delivered with os2tk45 coming with eCS
1.2R on CD2.
--
Tschau/Bye
Herbert
Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2 Deutsch ist da!
Marcel Müller
> Note that the heap managers for the typical runtimes do no support use of
> upper memory.
You can replace the global operator new/new[]/delete/delete[] and
malloc/realloc/free by your own versions with almost any C environment.
Marcel
Steven Levine
at 02:22 PM, Marcel Müller <news.5...@spamgourmet.com> said:
>You can replace the global operator new/new[]/delete/delete[] and
>malloc/realloc/free by your own versions with almost any C environment.
Agreed. I do not consider these custom versions typical.
A general solution is a bit more complicated becasue some APIs require the
data be located in the tiled memory region. This is easier to implement
in C++ than in C.
Lars Erdmann
Oops, Herbert is right (it was too late at night yesterday night).
The one you want to download is:
http://os2site.com/sw/dev/util/hdrtest.zip
Lars
Herbert Rosenau schrieb:
Lars Erdmann
Yes but with exehdr.exe /HI you are at the edge of technology :-).
But yes it is kind of dangerous. You can always revert by running:
exehdr.exe /NOH mydll.dll
But for your self-written DLLS it might be working fine. At least I have
one self-written WPS DLL loaded high (ok, I admit it's only since
yesterday night) and it works ok. But again, you have to be 100% sure
that it is not accessed by 16-bit code in any way.
Lars
Lars Erdmann
> In <44f7749c$0$17405$9b4e...@newsspool2.arcor-online.net>, on 09/01/2006
> at 01:45 AM, Lars Erdmann <lars.e...@arcor.de> said:
>
> Hi,
>
>
>>0.) To prepare your system for use of high memory, you have to have a
>>4.52 kernel and you have to specify something like
>>VIRTUALADDRESSLIMIT=3072
>>to make room for high memory in the system arena.
>
>
> I would advise against anything this large. It definitely break Acrobat5
> and can cause AGP apeture problem on some systems.
>
> My experience is that 2048 is safe. The default of 1024 provides 512MB of
> upper memory out of the box.
Thanks for the info. I didn't know. I'll change to that value. I have
quirks with my system but I don't know if it is related to that.
Lars
Ruediger Ihle
<ste...@earthlink.bogus.net> wrote:
> My experience is that 2048 is safe.
I have seen excpetions to this. Especially on PCIe
systems with huge VRAM apertures and WinTV PVR cards.
In these cases we had to reduce it from 2048 (the
default for eCS) to 1536.
--
Ruediger "Rudi" Ihle [S&T Systemtechnik GmbH, Germany]
http://www.s-t.de
Please remove all characters left of the "R" in my email address
MikeG
> On Fri, 1 Sep 2006 01:26:18 UTC, Steven Levine
> <ste...@earthlink.bogus.net> wrote:
>
>> My experience is that 2048 is safe.
>
> I have seen excpetions to this. Especially on PCIe
> systems with huge VRAM apertures and WinTV PVR cards.
> In these cases we had to reduce it from 2048 (the
> default for eCS) to 1536.
>
>
Were you just seeing hangs at startup or was it causing other problems?
Mike
Alex Taylor
>>> My experience is that 2048 is safe.
>>
>> I have seen excpetions to this. Especially on PCIe
>> systems with huge VRAM apertures and WinTV PVR cards.
>> In these cases we had to reduce it from 2048 (the
>> default for eCS) to 1536.
>
> Were you just seeing hangs at startup or was it causing other problems?
The desktop would start, but programs would not run.
--
Alex Taylor
http://www.cs-club.org/~alex
Remove hat to reply (reply-to address).
MikeG
> On Sat, 02 Sep 2006 08:13:36 -0400, MikeG <gree...@cox.net> wrote:
>>>> My experience is that 2048 is safe.
>>> I have seen excpetions to this. Especially on PCIe
>>> systems with huge VRAM apertures and WinTV PVR cards.
>>> In these cases we had to reduce it from 2048 (the
>>> default for eCS) to 1536.
>> Were you just seeing hangs at startup or was it causing other problems?
>
> The desktop would start, but programs would not run.
>
I was having hangs right before I would normally see the startup.cmd
window. This seemed to be happening close 50% of boots. I changed to
1536 and it hasn't happened since.
Thanks for the tip.
Mike
Lars Erdmann
VIRTUALADDRESSLIMIT seems to fix the problem. OS/2 is getting old ...
Lars
William L. Hartzell
Ruediger Ihle wrote:
> On Fri, 1 Sep 2006 01:26:18 UTC, Steven Levine
> <ste...@earthlink.bogus.net> wrote:
>
>> My experience is that 2048 is safe.
>
> I have seen excpetions to this. Especially on PCIe
> systems with huge VRAM apertures and WinTV PVR cards.
> In these cases we had to reduce it from 2048 (the
> default for eCS) to 1536.
>
>
Why the large Vram apertures? OS/2 is a 2d operating system. Limit the
aperture size to what is used.
What about system code? How does one get code into the system arena up
high? Was Rich loading 32-bit system dlls into upper application memory?
--
Bill
Thanks a Million!
Rich Walsh
>
> What about system code? How does one get code into the system arena up
> high? Was Rich loading 32-bit system dlls into upper application memory?
Scott G. had put out a revised version of exehdr that let you mark 32-bit
code segments as "HIGHMEM". Sadly, the changes to the kernel that permitted
loading code high were never fully debugged. Use the feature and you're
guaranteed to get a trap in the kernel sooner or later. When used with
Mozilla, it would occur about 1 time in 4 - always while shutting it down,
and always resulting in the complete disappearance of files like bookmarks
and prefs.js. Too bad, as this feature alone would have given OS/2 a whole
new lease on life...
Ruediger Ihle
<wlhar...@comcast.net> wrote:
> Why the large Vram apertures? OS/2 is a 2d operating system.
> Limit the aperture size to what is used.
Tell that IBM ;-). The original approach was the ask PCI for
the memory aperture and map whatever is reported back. Now
we have seen cards, that report 1GB or so, even though they
have "only" 256MB of RAM physically installed. I think some
issues were fixed in newer GRADD versions and SciTech also
did a workaround. But then there are these people, who
complain "I have a card with 512MB and OS/2 reports only
a part of it..."
> How does one get code into the system arena up high?
Device drivers, file systems etc. and - of course - the
kernel itself go there. Also work memory allocated by the
mentionend components will. This could include file system
caches and memory mapped I/O areas.
Steven Levine
at 05:24 AM, "Rich Walsh" <spamyo...@127.0.0.1> said:
>and you're guaranteed to get a trap in the kernel sooner or later. When
>used with Mozilla, it would occur about 1 time in 4 - always while
>shutting it down, and always resulting in the complete disappearance of
>files like bookmarks and prefs.js. Too bad, as this feature alone would
>have given OS/2 a whole new lease on life...
This sounds familiar. Did you every look at a trap dump? My experience
so far is that they all share in common that the active process is a VDM
that has AUD$ open.
I am still hopeful that once the nature of the trap is better understood,
a workaround can be developed.
William L. Hartzell
Ruediger Ihle wrote:
> On Sat, 9 Sep 2006 03:44:51 UTC, "William L. Hartzell"
> <wlhar...@comcast.net> wrote:
>
>> Why the large Vram apertures? OS/2 is a 2d operating system.
>> Limit the aperture size to what is used.
>
> Tell that IBM ;-). The original approach was the ask PCI for
> the memory aperture and map whatever is reported back. Now
> we have seen cards, that report 1GB or so, even though they
> have "only" 256MB of RAM physically installed. I think some
> issues were fixed in newer GRADD versions and SciTech also
> did a workaround. But then there are these people, who
> complain "I have a card with 512MB and OS/2 reports only
> a part of it..."
>
>
>> How does one get code into the system arena up high?
>
> Device drivers, file systems etc. and - of course - the
> kernel itself go there. Also work memory allocated by the
> mentionend components will. This could include file system
> caches and memory mapped I/O areas.
>
>
I am thinking about a 32-bit exe to replace a 16-bit sys file. Excuse
me for asking before I have the need or even look into the problem
space. I was asking if one was to rewrite the Multimedia device driver
part of MMOS2 (or any other part of OS/2) as exe/dll files and load them
into the system high arena by calling a cmd file after config.sys
processing? Then one could load different drivers depending upon the
user/root (ses stuff like Security/2) signed-in.
Ruediger Ihle
<wlhar...@comcast.net> wrote:
> I am thinking about a 32-bit exe to replace a 16-bit
> sys file. Excuse me for asking before I have the need
> or even look into the problem space. I was asking if
> one was to rewrite the Multimedia device driver part
> of MMOS2 (or any other part of OS/2) as exe/dll files
> and load them into the system high arena
This all doesn't really make much sense to me. First, an
MMPM driver is not neccessarily a device driver from the
OS perspective. It can be an ordinary DLL (Timidity MCD
is an example for that) or a mix of DLLs and multiple
physical device drivers. A sound card driver is usually
of the latter category with some support components
(AUDIOIF.DLL, SSM.SYS and R0STUB.SYS) beeing part of
MMOS2 itself.
As for the memory layout, you can divide the 4GB virtual
address range in three main areas: The low (application)
area (64K to 512MB), the high (application) area (512MB
to VIRTUALADDRESSLIMIT) and the system area (VIRTUALADD-
RESSLIMIT to 4GB). Both application areas are split into
a private and a shared part. The private arenas run from
low addresses to high while the shared arenas run downwards
from high to low. If they collide, we are dead. The kernel
places some data (for example page tables) from VIRTUAL-
ADDRESSLIMIT on upwards, while memory allocations/mappings
done by device drivers grow downwards below the kernel
code which is located at the end near the 4GB boundary.
Again, if the gap between theses allocations and the
mentioned kernel data structures gets too small, we are
in big trouble. And the latter is what we experience,
when VIRTUALADDRESSLIMIT is set too high.
The new EXEHDR option discussed earlier in this thread
causes DLLs to be loaded in the high shared arena instead
of the low shared arena. DLLs don't get loaded into the
system arena, which out of reach for application code.
William L. Hartzell
Ruediger Ihle wrote:
> On Sun, 10 Sep 2006 22:14:14 UTC, "William L. Hartzell"
> <wlhar...@comcast.net> wrote:
>
>> I am thinking about a 32-bit exe to replace a 16-bit
>> sys file. Excuse me for asking before I have the need
>> or even look into the problem space. I was asking if
>> one was to rewrite the Multimedia device driver part
>> of MMOS2 (or any other part of OS/2) as exe/dll files
>> and load them into the system high arena
>
> This all doesn't really make much sense to me.
Only if you think of using what is there, instead of replacing it.
My question is how does one load code into the high SYSTEM arena? Our
leading problem is the limited space between low SYSTEM arena and low
APPLICATION arena, not the over large apertures, which we can limit by
restricting the size of memory recognized by the video code. (As for
the idiots who want to see all that memory on their video card, show
them that memory, just don't map it.) If we move system code above
VIRTUALADDRESSLIMIT, that frees memory from the low SYSTEM arena. Thus
from what you said above, Rich Walsh moved code from the low SYSTEM
arena to upper APPLICATION memory, which may be the cause of the traps
he reports, that is being in the wrong arena.
Lars Erdmann
Again, you cannot make applications use the system memory arena. It's
reserved for the system, period.
The only "self-written" code/data that makes use of the system memory
arena is device drivers, file systems.
I think you are mixing up terms and you are confusing system memory
arena with high and low memory. If you want to have a better idea of
what different types of memory arenas exist in OS/2 4.52 and above, have
a look at the XWP help for the "memory" page of the kernel object (it's
in german here but I guess you get the picture):
Warp V2.x,V3,V4
4096 MB -----------------------------------------------------
System-Arena
512 MB -----------------------------------------------------
Gemeinsame (shared) Arena
variabel ---------------+-----------+---------------
Private | Private | Private
Arena | Arena | Arena
Prozeß 1 | Prozeß 2 | Prozeß 3
0 MB -----------------+-----------+---------------
Warp 4.52 and above (eCS ...):
4096 MB ---------------------------------------------
System-Arena
VIRTUALADDRESSLIMIT ---------------------------------
Arena für hohen Speicher
(gemeinsam und privat)
512 MB ---------------------------------------------
Gemeinsame (shared) Arena
variabel ---------------+-----------+---------------
Private | Private | Private
Arena | Arena | Arena
Prozeß 1 | Prozeß 2 | Prozeß 3
0 MB -----------------+-----------+---------------
So, everything above VIRTUALADDRESSLIMIT cannot be used by applications
, only by kernel and device drivers and file system drivers.
Everything from 64 k - 512 MB (low memory)(lowest 64 k not usuable due
to NULL selector) can be used by apps as well as everything from 512 MB
- VIRTUALADDRESSLIMIT (high memory).
Low memory as well as high memory is then split into private and shared
arena:
low memory: private arena growing upwards from 64 k to x
shared arena growing downwards from 512 MB to x
high memory: private arena growing upwards from 512 MB to y
shared arena growing downwards from VIRTUALADDRESSLIMIT to y
x and y are not fixed. They are variable to have the flexibility to
assign more private memory and less shared memory or vice versa.
Lars
William L. Hartzell
You are assuming that I am speaking about an user land application,
defuse yourself of that.
> The only "self-written" code/data that makes use of the system memory
> arena is device drivers, file systems.
> I think you are mixing up terms and you are confusing system memory
> arena with high and low memory. If you want to have a better idea of
> what different types of memory arenas exist in OS/2 4.52 and above, have
> a look at the XWP help for the "memory" page of the kernel object (it's
> in german here but I guess you get the picture):
<snip wrong conjecture>
Do you assume that the code of MMOS2, PM, GRE, MPTS, and the KERNEL are
user applications, then I can see your wrong conjecture. All that I
named in the previous sentence is or can be kernel space code. I am not
speaking about user land code, here.
So again, how does one load code up above VIRTUALADDRESSLIMIT?
Steven Levine
at 07:51 PM, "William L. Hartzell" <wlhar...@comcast.net> said:
><snip wrong conjecture>
>Do you assume that the code of MMOS2, PM, GRE, MPTS, and the KERNEL are
>user applications, then I can see your wrong conjecture. All that I
>named in the previous sentence is or can be kernel space code. I am not
>speaking about user land code, here.
You are wrong. The vast majority of the code that makes up mmos2, pm, gre
and mpts is definitely ring3 (i.e. user land code). More of what most
consider the kernel than you might think is also ring3 code (see
doscalls.dll).
To learn this for your self, use
lxlite -c:exemap
and look at the segment definitions.
>So again, how does one load code up above VIRTUALADDRESSLIMIT?
You write the code as a 16-bit or 32-bit driver.
Ruediger Ihle
<wlhar...@comcast.net> wrote:
Sorry, but I have the feelling that you did not understand
what I and others wrote.
> My question is how does one load code into the high SYSTEM
> arena?
There is no high or low system arena. There is only one as
described in my and Lars's postings. And it is protected,
so that ring 3 code cannot directly call functions there.
This makes it impossible to put anything other than kernel
code and device drivers / file systems there.
> Our leading problem is the limited space between low SYSTEM
> arena and low APPLICATION arena
No, it is not. I guess you are confusing this with a congestion
in the low application area, which can be caused by excessive
use of DLLs. Note that by default all shared code (including
the DLLs composing PM, MMOS2, TCPIP etc.) appear in the low
shared application arena, which then may collide with the low
private arena of a given process.
> Rich Walsh moved code from the low SYSTEM arena to upper
> APPLICATION memory
No, he didn't. He flagged some DLLs (Mozilla and PM) to be
loaded in the high shared application arena (i.e. from
VIRTUALADDRESSLIMIT downwards) instead of their regular
location in the low shared application arena (from 512MB
downwards). This did not work reliable. Most likely because
it was never fully tested and debugged by IBM. I guess Scott
simply didn't have the time and the "business case" to do
that.
Marty
> So, everything above VIRTUALADDRESSLIMIT cannot be used by applications
> , only by kernel and device drivers and file system drivers.
> Everything from 64 k - 512 MB (low memory)(lowest 64 k not usuable due
> to NULL selector) can be used by apps as well as everything from 512 MB
> - VIRTUALADDRESSLIMIT (high memory).
Just to add some more complexity to the picture, don't we also reserve
some of the first 1MB for SYSINIT "real mode" virtual machines, like
video BIOS access, INT 13, and VMBs? I personally found a significant
savings in low memory (and reduction in shared/low-private collisions)
when I removed DOS/Win3.1 compatibility from my system. Also BIG
PM-managed bitmaps (like desktop wallpaper) take up huge tracts of
shared memory - specifically if they are JPGs, because they are
converted to rasterized bitmaps in memory and fragment shared memory in
the process.
--
[Reverse the parts of the e-mail address to reply.]
William L. Hartzell
Ruediger Ihle wrote:
> On Mon, 11 Sep 2006 18:59:51 UTC, "William L. Hartzell"
> <wlhar...@comcast.net> wrote:
>
> Sorry, but I have the feelling that you did not understand what I and
> others wrote.
I understand that you don't understand what I wrote. You seem to be
limited to what exehdr is capable of doing. (And yes, I have that tool.)
>
>
>> My question is how does one load code into the high SYSTEM arena?
>>
>
> There is no high or low system arena. There is only one as described
> in my and Lars's postings. And it is protected, so that ring 3 code
> cannot directly call functions there. This makes it impossible to put
> anything other than kernel code and device drivers / file systems
> there.
What is this protection that limits ring 3 code from executing from
there? I want to put ring 3 system code up there. One to three and
half GiB of virtual memory is way too much. Since we know that OS/2
will run fine in less than 128 MiB of physical memory without swapping
or discarding pages, that means most of the upper system arena (and I'm
going to continue to call it that) has nothing in it, even when
someone's card allocates 1.5 GiB for some empty frame buffer's aperture.
(I'd think when one has problems with large apertures, it because of
where the frame buffer was mapped, not the size. I'm also of the
opinion that one does not need to map the whole buffer.)
>
>> Our leading problem is the limited space between low SYSTEM arena
>> and low APPLICATION arena
>
> No, it is not. I guess you are confusing this with a congestion in
> the low application area, which can be caused by excessive use of
> DLLs. Note that by default all shared code (including the DLLs
> composing PM, MMOS2, TCPIP etc.) appear in the low shared application
> arena, which then may collide with the low private arena of a given
> process.
>
>
>> Rich Walsh moved code from the low SYSTEM arena to upper
>> APPLICATION memory
>
> No, he didn't. He flagged some DLLs (Mozilla and PM) to be loaded in
> the high shared application arena (i.e. from VIRTUALADDRESSLIMIT
> downwards) instead of their regular location in the low shared
> application arena (from 512MB downwards). This did not work reliable.
> Most likely because it was never fully tested and debugged by IBM. I
> guess Scott simply didn't have the time and the "business case" to
> do that.
There is a low system arena. I think you are ignoring that system code
loads from 512 MiB downwards. It loads above application shared memory.
You are combining the two and that is the source of the confusion on
your part. Remember that the 9 and earlier series kernels never used
anything above 512 MiB. IBM never changed the kernel behavior when they
added the capability to load above the 512 MiB limit, except where Scott
had the time to move some data structures up there. (And if my memory
of the increased size of lower free memory between fixpack 12 and 13, it
was only about eight to ten MiB that moved.) BTW, it will be hard to
convince me that any 16-bit device driver loads up there. Do you know
of any switches to any tool to cause a 16-bit device driver to load
above VIRTUALADDRESSLIMIT? IF YOU DO, THAT TOOL WILL LOAD RING THREE
CODE UP THERE WITH THE RIGHT HACK.
I'd still bet that there are switches to some tool to load ring 3 code
above VIRTUALADDRESSLIMIT, but maybe not outside IBM. IT WOULD BE NICE
TO HAVE SUCH A TOOL.
Steven Levine
at 11:50 AM, "William L. Hartzell" <wlhar...@comcast.net> said:
>> cannot directly call functions there. This makes it impossible to put
>> anything other than kernel code and device drivers / file systems
>> there.
>What is this protection that limits ring 3 code from executing from
>there?
The virtual page mappings.
>I want to put ring 3 system code up there.
Well all have blue-sky wishes.
>One to three and half
>GiB of virtual memory is way too much.
Is this fact or opinion?
> (I'd think when one has problems with large apertures, it because of
>where the frame buffer was mapped, not the size. I'm also of the opinion
>that one does not need to map the whole buffer.)
This may very well be true, but who is going to fund the changes to the
current implementation?
>There is a low system arena. I think you are ignoring that system code
>loads from 512 MiB downwards. It loads above application shared memory.
You really do yourself a disservice when you make statements like this.
Please spend to some quality time with Theseus so you have a minimal
understanding of what lives where in virtual address space and physical
memory.
>BTW, it will be hard to
>convince me that any 16-bit device driver loads up there.
Too bad for you. Again, all I can recommend is you spend some quality
time with Theseues or the kernel debugger.
>Do you know
>of any switches to any tool to cause a 16-bit device driver to load
>above VIRTUALADDRESSLIMIT?
No switches needed. Again, spend some time with Theseus.
>IF YOU DO, THAT TOOL WILL LOAD RING THREE
>CODE UP THERE WITH THE RIGHT HACK.
We are waiting for you to provide proof of concept code.
Regards,
Ruediger Ihle
> Just to add some more complexity to the picture, don't we also reserve
> some of the first 1MB for SYSINIT "real mode" virtual machines, like
> video BIOS access, INT 13, and VMBs?
That is physical memory. We are talking about virtual here, so this will
probably not directly contribute to the problem.
> I personally found a significant savings in low memory (and reduction
> in shared/low-private collisions) when I removed DOS/Win3.1 compatibility
> from my system.
That is still well possible. But I guess it's more due to PM not needing
to support DOS windows in this case.