Apologies for delayed responses, I don't check this forum that much nowadays.
wrote:
Maybe I wasn't clear: I was just referring to the user-mode virtual memory limits of a 32bit process using using linear memory addressing, which are 2GB (or 3GB for large address aware binaries) on 32bit Windows.
On some server versions of 32bit Windows, as you say, the OS can use more than 4GB memory to accomodate those processes, on the client versions of Windows the limit of physically usuable memory is 4GB minus whatever is mapped for device and unpagable OS space.
E.G., on my W500 fully 1.5GB of 4GB installed memory is mapped by the BIOS above 4GB physical memory address, to get it out of the way of the large space taken up by the 2 graphics adapters (and other devices). There's no reason in principal why Microsoft couldn't allow the 1.5B to be mapped by user-mode process space, while keeping both the pagable and unpageable bits of device drivers allocated "safely" in the lower 2.5GB physical addresses.--But I grant you that this would be a very unlikely change! I'm just geekily disappointed & irritated that 1.5GB memory is unavailable for use without adaquate technical justification.
A few points:
1. You mentioned in an earlier post that the inability to reference memory outside of the 4 GB range using segmented addressing was a Microsoft limitation. That isn't really true - it's more to do with the programming model of Windows. Take a look at the header files that come with the Windows SDK, like winbase.h and winnt.h.
To switch over to a segmented addressing system, like in the DOS days, would be a radical change. For example, every application would have to ensure that their data and code segment registers point to the correct segments or else memory corruption could occur. For applications that are unaware, they could inadvertantly change the value and cause crashes. (Also see point #3 for additional pitfalls.)
2. You mentioned a few times, the large memory features in Windows such as AWE and PAE. None of those features actually allows applications to address more than 4 GB.
- AWE uses a paging model that maps in memory to the 4 GB space, similar in concept to swapping boxes of items. Only one box of goods is available at any given moment, but all boxes can be accessed.
- 4GT only increases the user mode space to 3 GB.
- PAE allows the system, not the application, to use more than 4 GB.
3. You also stated that memory mapping (either user or driver memory) was a solution. The problem occurs when you have interaction between the two memory mappings.
For example, an application needs to send a block of data to the device, say a Firewire device. The application would allocated a buffer on the application's address space, pass it to an IOCTL function, and let the driver handle it. However, at that moment, the driver is mapped to its own address space, which doesn't match the application's address space. Now, either the driver or Windows is stuck with the task of either:
- Copying the memory from one address space to the other. If every call had to do this, there would be a massive performance hit.
- Do translation, if it is even possible (it would be impossible if the driver has mapped a large enough portion such that Windows couldn't map the application's address space without unmapping part of the driver's address space).
- Fail the call. Not very practical - the application would have no real way of knowing how to allocate memory such that the call could succeed.
Another possible solution, could be to make new Windows APIs to handle these cases, allowing for memory allocation to happen on common address spaces. Of course, retrofitting all existing applications to do this would be practically impossible.
wrote:
3) Not sure what you mean by "why do they configure they laptops they way they know it's not gonna work?" But the this configuration of the W500 does work--just not with the full advantage of the installed memory when used with 32bit operating systems, and this is something Microsoft is responsible for, not Lenovo! And as others have mentioned, Microsoft will not change the memory size licensing conditions for hardware compatibility and product line differentiation reasons.
4. I highly doubt there were any "memory size licensing conditions" - it is simply a matter of practicality. The APIs that allow applications under Windows applications to gain access to more memory come with costs. One of them is the fact that they need processor and chipset support.
Back when Windows XP came out (2002), only server chipsets even allowed for more than 4 GB of memory to be installed on the system. Consumer level chipsets, such as the Intel 875P, could only support 4 GB. Having APIs that allowed access to more memory would simply have made things more difficult for application designers, driver writers and OS testers.
Fast forward a few years, to the release of Vista (and even Windows 7). The market for Windows XP software is so large, that it is impossible to ignore. Thus, it would only make sense to keep the same restrictions as XP for the consumer level OS's
I understand it is annoying to not be able to use the memory purchased, but this problem has been around for years. While it has only been in the past few years that people have been able to purchase machines with large amounts of memory, it wasn't exactly a hidden secret.
spidey101
4