XP 32 bit Memory

J. P. Gilliver (John) wrote:

When I suggested a memory manager, I wasn't talking about going beyond
the 4G limit, I was talking about accessing the RAM within the 4G but
beyond where hardware sits on some machines, i. e. using non-contiguous
memory.

That is a hardware problem that you cannot solve with software. That is
why the memory remapping function were invented.

J. P. Gilliver (John) wrote:

When I suggested a memory manager, I wasn't talking about going beyond
the 4G limit, I was talking about accessing the RAM within the 4G but
beyond where hardware sits on some machines, i. e. using non-contiguous
memory.

That is a hardware problem that you cannot solve with software. That is
why the memory remapping function were invented.

dennis wrote:
John John - MVP wrote:


I know that a certain RAM disk can apparently make use of the memory
above the 4GB barrier, I guess this is what you mean by "device space".

With device space I mean this:
http://msdn.microsoft.com/en-us/library/ms801998.aspx

Thanks for the link. In one of his blogs Mark Russinovich said that
"...problematic client driver ecosystem led to the decision for client
SKUs to ignore physical memory that resides above 4GB, even though they
can theoretically address it." My understanding about this is that
while (some of) the server versions can do this the whole point of
limiting memory access below 4GB on clients with PAE was to specifically
prevent drivers from playing in the upper memory arena. So now I'm not
sure what to think...

http://blogs.technet.com/markrussino...1/3092070.aspx
Mark's Blog : Pushing the Limits of Windows: Physical Memory

John

dennis wrote:
John John - MVP wrote:


I know that a certain RAM disk can apparently make use of the memory
above the 4GB barrier, I guess this is what you mean by "device space".

With device space I mean this:
http://msdn.microsoft.com/en-us/library/ms801998.aspx

Thanks for the link. In one of his blogs Mark Russinovich said that
"...problematic client driver ecosystem led to the decision for client
SKUs to ignore physical memory that resides above 4GB, even though they
can theoretically address it." My understanding about this is that
while (some of) the server versions can do this the whole point of
limiting memory access below 4GB on clients with PAE was to specifically
prevent drivers from playing in the upper memory arena. So now I'm not
sure what to think...

http://blogs.technet.com/markrussino...1/3092070.aspx
Mark's Blog : Pushing the Limits of Windows: Physical Memory

John

In message , dennis
writes:
J. P. Gilliver (John) wrote:

When I suggested a memory manager, I wasn't talking about going
beyond the 4G limit, I was talking about accessing the RAM within the
4G but beyond where hardware sits on some machines, i. e. using
non-contiguous memory.

That is a hardware problem that you cannot solve with software. That is
why the memory remapping function were invented.

They seemed to solve it OK in the days of DOS and the (I think it was)
640K barrier, with LOADHI (IIRR) and so on; ISTR prog.s and drivers had
to be loadhigh aware, or something like that. It's all a Long Time Ago
....
--
J. P. Gilliver. UMRA: 1960/1985 MB++G.5AL-IS-P--Ch++(p)Ar@T0H+Sh0!:`)DNAf
** http://www.soft255.demon.co.uk/G6JPG-PC/JPGminPC.htm for ludicrously
outdated thoughts on PCs. **

Reality and talent shows lack honesty. They manipulate the viewer with mawkish
stories. Contestants turn tragedies into qualifications. - Sean Lock, in Radio
Times, 20-26 June 2009

In message , dennis
writes:
J. P. Gilliver (John) wrote:

When I suggested a memory manager, I wasn't talking about going
beyond the 4G limit, I was talking about accessing the RAM within the
4G but beyond where hardware sits on some machines, i. e. using
non-contiguous memory.

That is a hardware problem that you cannot solve with software. That is
why the memory remapping function were invented.

They seemed to solve it OK in the days of DOS and the (I think it was)
640K barrier, with LOADHI (IIRR) and so on; ISTR prog.s and drivers had
to be loadhigh aware, or something like that. It's all a Long Time Ago
....
--
J. P. Gilliver. UMRA: 1960/1985 MB++G.5AL-IS-P--Ch++(p)Ar@T0H+Sh0!:`)DNAf
** http://www.soft255.demon.co.uk/G6JPG-PC/JPGminPC.htm for ludicrously
outdated thoughts on PCs. **

Reality and talent shows lack honesty. They manipulate the viewer with mawkish
stories. Contestants turn tragedies into qualifications. - Sean Lock, in Radio
Times, 20-26 June 2009

Thanks for the link. In one of his blogs Mark Russinovich said that
"...problematic client driver ecosystem led to the decision for client
SKUs to ignore physical memory that resides above 4GB, even though they
can theoretically address it." My understanding about this is that
while (some of) the server versions can do this the whole point of
limiting memory access below 4GB on clients with PAE was to specifically
prevent drivers from playing in the upper memory arena. So now I'm not
sure what to think...

http://blogs.technet.com/markrussino...1/3092070.aspx
Mark's Blog : Pushing the Limits of Windows: Physical Memory

You also don't use this function to allocate memory. All the memory
allocation functions that the drivers (normally) use will always
allocate memory below 4G in 32bit XP.

Thanks for the link. In one of his blogs Mark Russinovich said that
"...problematic client driver ecosystem led to the decision for client
SKUs to ignore physical memory that resides above 4GB, even though they
can theoretically address it." My understanding about this is that
while (some of) the server versions can do this the whole point of
limiting memory access below 4GB on clients with PAE was to specifically
prevent drivers from playing in the upper memory arena. So now I'm not
sure what to think...

http://blogs.technet.com/markrussino...1/3092070.aspx
Mark's Blog : Pushing the Limits of Windows: Physical Memory

You also don't use this function to allocate memory. All the memory
allocation functions that the drivers (normally) use will always
allocate memory below 4G in 32bit XP.

J. P. Gilliver (John) wrote:

They seemed to solve it OK in the days of DOS and the (I think it was)
640K barrier, with LOADHI (IIRR) and so on; ISTR prog.s and drivers had
to be loadhigh aware, or something like that. It's all a Long Time Ago ...

The problem with not all 4GB being usable is because MMIO is overlapping
the address space where your RAM lives. All memory addresses in that
region are redirected to the IO-system. So you cannot get to that RAM.

Memory remapping solves that by remapping ram in that region up above
4G, so you can address it there instead (which 32bit XP doesn't do
willingly).

J. P. Gilliver (John) wrote:

They seemed to solve it OK in the days of DOS and the (I think it was)
640K barrier, with LOADHI (IIRR) and so on; ISTR prog.s and drivers had
to be loadhigh aware, or something like that. It's all a Long Time Ago ...

The problem with not all 4GB being usable is because MMIO is overlapping
the address space where your RAM lives. All memory addresses in that
region are redirected to the IO-system. So you cannot get to that RAM.

Memory remapping solves that by remapping ram in that region up above
4G, so you can address it there instead (which 32bit XP doesn't do
willingly).

There is another teensy weensy problem.
Microsoft using various means, does not allow legal modification of windows
core by "outsiders" to allow relocation to "unused" memory.
Since hardware, with a proper memory manager, in hardware and software,
usually can do such things, the problem ends up going back to Microsoft's
code.
After all, memory mapping is a very old technique, going back to the
minicomputers, if not farther back in history. Some of the minicomputers
had an rough equivalent to Windows swap file, in that if enough memory was
installed, resided in memory rather than only on disk. At one point, some
of HP's systems swapped out almost anything that was not currently in use.
The ops system maintained a table that was used to find everything.
(1970's) long before Apple, etc. One of the major problems is the
compatibility issue with older P/C hardware and "standards" that are the
result of "IBM compatibility", based on a crippled hardware design intended
to prevent competition with mainframe capabilities and save hardware costs.
The older schemes also were usually intended for use with multiusers, be the
"users" a physical person, or a process.


"dennis" wrote in message
...
J. P. Gilliver (John) wrote:

They seemed to solve it OK in the days of DOS and the (I think it was)
640K barrier, with LOADHI (IIRR) and so on; ISTR prog.s and drivers had
to be loadhigh aware, or something like that. It's all a Long Time Ago
...

The problem with not all 4GB being usable is because MMIO is overlapping
the address space where your RAM lives. All memory addresses in that
region are redirected to the IO-system. So you cannot get to that RAM.

Memory remapping solves that by remapping ram in that region up above 4G,
so you can address it there instead (which 32bit XP doesn't do willingly).

There is another teensy weensy problem.
Microsoft using various means, does not allow legal modification of windows
core by "outsiders" to allow relocation to "unused" memory.
Since hardware, with a proper memory manager, in hardware and software,
usually can do such things, the problem ends up going back to Microsoft's
code.
After all, memory mapping is a very old technique, going back to the
minicomputers, if not farther back in history. Some of the minicomputers
had an rough equivalent to Windows swap file, in that if enough memory was
installed, resided in memory rather than only on disk. At one point, some
of HP's systems swapped out almost anything that was not currently in use.
The ops system maintained a table that was used to find everything.
(1970's) long before Apple, etc. One of the major problems is the
compatibility issue with older P/C hardware and "standards" that are the
result of "IBM compatibility", based on a crippled hardware design intended
to prevent competition with mainframe capabilities and save hardware costs.
The older schemes also were usually intended for use with multiusers, be the
"users" a physical person, or a process.


"dennis" wrote in message
...
J. P. Gilliver (John) wrote:

They seemed to solve it OK in the days of DOS and the (I think it was)
640K barrier, with LOADHI (IIRR) and so on; ISTR prog.s and drivers had
to be loadhigh aware, or something like that. It's all a Long Time Ago
...

The problem with not all 4GB being usable is because MMIO is overlapping
the address space where your RAM lives. All memory addresses in that
region are redirected to the IO-system. So you cannot get to that RAM.

Memory remapping solves that by remapping ram in that region up above 4G,
so you can address it there instead (which 32bit XP doesn't do willingly).