As explained before, it is not purely a Windows limitation - it's a combination of factors that limits the total usable memory on a 32-bit Windows system to less than 4 GB (maximum addressable memory size using a flat 32-bit pointer).

Many system components start mapping into the address space due to their memory needs.  The most obvious are graphics cards, due to their larger memory requirements.  But other components may map as well, causing further loss of OS available memory.

32-bit Windows, as far as I know, does not hard code the reading of < 3,000 MB of RAM.  On my desktop, with a ATI HD 4890 and a workstation level motherboard with 2 x 2 GB installed, I have a listed total of 3,144,492 KB (or approximately 3,070 MB, just under 3.00 GB).  This is using Windows XP Professional.

Even 64-bit Windows may possibly read less than the installed memory size, depending on the chipset used (not as relevant to AMD or Intel's ix series).  For example, a Intel's P43 chipset can only handle 8 GB of memory.  If you installed a full 8 GB on a motherboard with this chipset, the system may not actually see the full 8 GB, as the chipset may not allow remapping of device memory to above the 8 GB mark.

As for Windows/Linux/OSX differences - your post stated that you are using custom BIOS images to get the additional memory recognized.  Perhaps whatever modification you made was not appropriate for Windows' memory detection system, but was suitable enough for the other operation system's detection methods.

---

wrote:

As explained before, it is not purely a Windows limitation - it's a combination of factors that limits the total usable memory on a 32-bit Windows system to less than 4 GB (maximum addressable memory size using a flat 32-bit pointer).

I agree with all you write, but remember that the 32-bit flat pointer address size limit applies only to the 32-bit process address space--the X86 microprocessor can reload the segment/paging registers with some other value that references a whole other tract of 32-bit memory space mapped to entirely different areas of physical RAM (or not mapped at all, depending on the state of paging). And of course paging allows all those 32-bit process spaces to share common code and data.

If other (principally licensing) considerations allowed it, a machine running 32bit Vista could have as many 32bit processes mapped to as much physical RAM as the motherboard chipset allows, but each such process would only be able to use a maximum of 4GB *minus* the space taken up by the OS's and drivers' footprints in that 4GB space. Hence an 8GB machine running 32bit Windows and using all that physical memory is feasable, but not allowed by licensing limitations. (If a Royalty OEM like Lenovo or HP really pushed Microsoft on this question, we might be in a different place.)

Even in 32bit Windows, those parts of the OS and drivers that interact with physical memory addresses (e.g. DMA and paging routines, direct hardware port access, etc.) have to deal with addresses that exceed 32-bits: they simply wouldn't work on recent X86 microprocessors running in segmented address modes.

Actually ... a 32bit system using PAE could in theory adress more than 4GBytes. Some of the Windows Server OSes do this. But those, like the 64 bit versions, require signed drivers (the signed drivers being the reason a lot of hardware manufacturers not supplying 64bit compatibility!), because a LOT of the joe's-truckstop-and-usbdevices drivers out there have HARDCODED memory adresses for their stuff that is quite likely to bluescreen any system that uses PAE or x64 adressing.

PAE has existed since Pentium Pro and ups the limit from 4GB to 64GB adress space. The reason this has not been done on end-user software, is PURELY those drivers written by incompetents. Start placing blame correctly: Blame lazy programmers.

//Svein

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.

Hey Guys,

All you say is true,but no one answers my question, and as it seems there is no Lenovo technical in this page!

considering all this, why does Lenovo ships laptops with windows 32 bit and 4GB of RAM?

i know they say on the website it's not recommended to use more than 3GB with windows 32 bit, but i bought my laptop off the shelf, it's Lenovo default configuration, So why Lenovo does this?

why do they configure they laptops they way they know it's not gonna work?

---

wrote:

Hey Guys,

All you say is true,but no one answers my question, and as it seems there is no Lenovo technical in this page!

 

considering all this, why does Lenovo ships laptops with windows 32 bit and 4GB of RAM?

i know they say on the website it's not recommended to use more than 3GB with windows 32 bit, but i bought my laptop off the shelf, it's Lenovo default configuration, So why Lenovo does this?

why do they configure they laptops they way they know it's not gonna work?

 

---

I'm no expert, but here are some considerations, in no particular order:

1) The wholesale contract price of 2 X 2GB memory sticks is probably very close to the price of 1 X 1GB + 1 X 2GB memory sticks.

2) Lenovo does actually maufacture (or did, I haven't looked at the current models) W500 with just 3GB of installed memory, loaded with 32bit operating systems (mostly Window XP "downgrade" option preloads), but installing 4GB may simply be a more efficient use of manufacturing, since then that hardware can also be used for 64bit preloads.

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.

As I've said, I think the "hardware compatibility" reason is very weak: if software developers and companies still distribute 32bit device drivers that "bluescreen" a running system, that is their business problem, not Microsoft's, who has been advocating correct 32bit/64bit driver development practices since the early 1990's.

From the customer's perspective, running a 32bit operating system for compatibility reasons (no Windows-on-Windows or other VM complications), with masses of available physical memory (more than 3GB) for multiple large 32bit processes--think technical workstation applications, say 2 or 3 Autodesk programs all open at once, without having to wait for a lot of paging activity--is very convenient, feasable, and reduces support headaches.

Microsoft, however, does not see it that way: they want end-users and software developers to move to 64bit client operating systems ASAP for a whole host of business and technical reasons. I suppose the inclusion of a seamless Windows XP VM in Windows 7 is part of that strategy, but I'm not up to date on how Microsoft thinks!

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.

Thanks for your reply.

I guess I haven't been quite clear: I'm not advocating Microsoft make available process address space larger than the current limits of a 32bit flat address--of course this would require a return to processes using segmented modes of process memory addressing: let's leave that blast from the past to the poor devils who have to design the OS's paging & process management code in the kernel.

I simply want 32bit processes to be able to be mapped into all available physical memory, should there be a need for the space. The example I gave was someone using several very memory-hungry programs, and not wishing to pay the swap-in/swap-out paging tax. As things are right now, the client versions of 32bit Windows OSs do not use physical memory above the 4GB limit for mapping process memory space, but this is an entirely artificial limit, since the Datacenter/Enterprise server versions of those OSs certainly can use more than 4GB. It's just a silly product differentiation issue for Microsoft, really, since ISVs can already limit their 32bit programs to running exclusively on server or client versions of Windows.

Granted, this would mean some double-buffering (and other) complications for programs/drivers using the reserved OS and I/O spaces in the first 4GB physical memory, which would be a higher bar and more restrictions on how device drivers and even regular programs access the still flat 32bit memory space, but most of that can be hidden from the regular processes--after all, this already works in the 32bit server versions of Windows with >4GB physical memory. And there would be a performance impact, but todays machines are so fast, I doubt most would notice.

Anyway, this is a change of Microsoft policy that will never happen, and I don't want to belabour the point.

---

wrote:

Thanks for your reply.

 

I guess I haven't been quite clear: I'm not advocating Microsoft make available process address space larger than the current limits of a 32bit flat address--of course this would require a return to processes using segmented modes of process memory addressing: let's leave that blast from the past to the poor devils who have to design the OS's paging & process management code in the kernel.

 

I simply want 32bit processes to be able to be mapped into all available physical memory, should there be a need for the space. The example I gave was someone using several very memory-hungry programs, and not wishing to pay the swap-in/swap-out paging tax. As things are right now, the client versions of 32bit Windows OSs do not use physical memory above the 4GB limit for mapping process memory space, but this is an entirely artificial limit, since the Datacenter/Enterprise server versions of those OSs certainly can use more than 4GB. It's just a silly product differentiation issue for Microsoft, really, since ISVs can already limit their 32bit programs to running exclusively on server or client versions of Windows.

 

Granted, this would mean some double-buffering (and other) complications for programs/drivers using the reserved OS and I/O spaces in the first 4GB physical memory, which would be a higher bar and more restrictions on how device drivers and even regular programs access the still flat 32bit memory space, but most of that can be hidden from the regular processes--after all, this already works in the 32bit server versions of Windows with >4GB physical memory. And there would be a performance impact, but todays machines are so fast, I doubt most would notice.

 

Anyway, this is a change of Microsoft policy that will never happen, and I don't want to belabour the point.

---

Unfortunately, your statements are an oversimplification.  Driver development is not something that can be done that easily.

For arguments sakes, let's assume Microsoft enables what you propose.  Now you have a set of drivers that do not work with Windows, causing devices to be rendered useless.  Let's also assume that approximately 10% of all drivers are legacy drivers or drivers whose companies no exist or no longer maintain them.  (This is probably a somewhat low estimate - when Windows NT 4 switched driver models, it caused quite a headache, and that was back in the days where there were few devices.)

Now you have an OS mode that will not run on the hardware that the consumers want to use, and due to that, probably existing software will also not work properly.  Device manufacturers will complain to Microsoft, since they don't need another driver model to write against.

Using path of least resistance, the general public will shut that mode down and switch back to the classic mode.  And since Microsoft already has a 64-bit mode for machines with large amounts of memory, and has drivers that work in that mode, the public will use that instead of going to some new, not widely supported mode.

As a side note, not many applications in the server world actually use the large memory functionality.  I believe SQL (and Oracle, etc) and Exchange do use the functionality, but I don't really know of any other widely used server software that actually uses the large memory functionality.

O.K., you are correct about oversimplification: apart from the policy considerations I mentioned, there would be compatibility issues in allowing 32bit processes to be placed above the present 4GB limit of installed memory, and that's just not practical with legacy considerations.

And of course the 64bit OS versions do exactly what I have described in wanting 32bit processes to use the full extent of installed memory.

Remember, I'm not talking about extending the 32bit memory limit that each process can address, just the convenience in allowing the 32bit OS to address & allocate all installed physical memory above 4GB for user processes, and not have to make the wholesale changes that a full 64bit OS requires in devices drivers, etc.

I also should have remembered the Windows NT 3.5x --> 4.0 compatibility sagas too, now.

Oh well, thanks for your contribution.