2G+ memory blocks

[Shelwien]

Its a common knowledge that normally WinXP-32bit only allows
a single process to access 2G of memory, and 3G with /3GB in boot.ini
and LARGEADDRESSAWARE flag set in executable header.

But today I wrote a program to test it out, and found
something interesting - further modifications to
WinXP are necessary to be able to use that memory with
existing compressors. Specifically, the system dlls have to
be rebased, or else the address space might become
fragmented (its a WinXP SP3):

[LARGEADDRESSAWARE+/ML]
block [00410000..7C7FFFFF]  size = 1987M = 2035648K = 2084503552
block [7FFF0000..BFFAFFFF]  size = 1023M = 1048320K = 1073479680
block [7C9B0000..7F6EFFFF]  size = 45M = 46336K = 47448064
block [7F7F0000..7FFDFFFF]  size = 7M = 8128K = 8323072
block [00340000..003FFFFF]  size = 0M = 768K = 786432

[LARGEADDRESSAWARE+/MD]
block [00410000..77C0FFFF]  size = 1912M = 1957888K = 2004877312
block [7FFF0000..BFFAFFFF]  size = 1023M = 1048320K = 1073479680
block [77C70000..7C7FFFFF]  size = 75M = 77376K = 79233024
block [7C9B0000..7F6EFFFF]  size = 45M = 46336K = 47448064
block [7F7F0000..7FFDFFFF]  size = 7M = 8128K = 8323072
block [00340000..003FFFFF]  size = 0M = 768K = 786432

[/MD]
block [00410000..77C0FFFF]  size = 1912M = 1957888K = 2004877312
block [77C70000..7C7FFFFF]  size = 75M = 77376K = 79233024
block [7C9B0000..7F6EFFFF]  size = 45M = 46336K = 47448064
block [7F7F0000..7FFAFFFF]  size = 7M = 7936K = 8126464
block [00340000..003FFFFF]  size = 0M = 768K = 786432
block [7FFF0000..7FFFDFFF]  size = 0M = 56K = 57344

[/ML]
block [00410000..7C7FFFFF]  size = 1987M = 2035648K = 2084503552
block [7C9B0000..7F6EFFFF]  size = 45M = 46336K = 47448064
block [7F7F0000..7FFAFFFF]  size = 7M = 7936K = 8126464
block [00340000..003FFFFF]  size = 0M = 768K = 786432
block [7FFF0000..7FFFDFFF]  size = 0M = 56K = 57344

http://shelwien.googlepages.com/maxmem_v0.rar

Update:

1. Default image base addresses of some dlls:
ntdll.dll - 7C900000
kernel32.dll - 7C800000
msvcrt.dll - 77C10000 (linked with /MD)

2. It appears possible to use a local rebased copy of kernel32.dll,
but somehow that only uses up some extra memory (seems like
system somehow loads the original kernel32.dll too, anyway).
Also a local version of ntdll.dll doesn't want to work at all,
rebased or not (errors while loading an executable).