Windows 7 32-bit with full 4 GB or 8 GB RAM support

[tablet_user]

is there 32bit motherboards that even support 64gb ram? Or is this just peoples way of avoiding 64bit os's for no reason whatsoever.

[hdood]

is there 32bit motherboards that even support 64gb ram? Or is this just peoples way of avoiding 64bit os's for no reason whatsoever.

There are 32-bit boards that support more than 3GB...

The people whining need to get real. Microsoft has no obligation to do anything, and the 4GB limit is not a "licensing issue" (even though it may be implemented that way internally), it's a published design limit of the product. If you don't like it, don't buy it. If it comes pre-installed on a system with more than 3GB (or whatever) of RAM, return it as defective.

Microsoft does not sell a 32-bit OS that supports more than 4GB, and the idea that they somehow have a duty to make and sell such a product just because they're technically capable of doing so is absurd. The world doesn't work that way.

Now I happen to think that hacks like this are quite clever, but some of you are taking the complaining it a bit too far.

[Geoff Chappell]

why would you want to do such a thing. People need to understand that 32bit is on the way out, move on! 64bit is a far better system then 32bit Windows.

As I said, that so many people do seem to want to do "such a thing" for real-world use astonishes me, too, but is another story. I'm only trying to straighten out for you what the patch does, since the Russian hackers evidently haven't and this forum has made an epic thread out of all sorts of confusion and misinformation.

Obviously, the way of the future is to get 64-bit Windows with as much more memory than 4GB as is sensible for your expected usage and with all 64-bit applications. Between that and the reality of the typical offerings from OEMs when Windows Vista first came out, things are grey enough that people with different weightings may reasonably come to different assessments. They or others may have a historical interest in knowing what they were sold and how fully informed were their purchasing decisions. That people are interested in what happened doesn't mean they don't understand that what happened is "on the way out" and doesn't mean you have to prod them to "move on".

That you and others have moved on to the future and have no interest in looking back is great for you, but surely the point that you're uninterested can be made just once by any one of you and then you can all leave the discussion alone as something that doesn't interest you but may interest others. That so many have given their time to this thread to declaim that they're uninterested is almost as astonishing as the number who are willing to patch their 32-bit kernel for everyday use.

'Tis why people buying a PC should do research to see if the machine will meet their immediate and/or future needs. To assume that any one particular piece of hardware will "just work" in any PC, no matter what, is a bit shortsighted.

Yes. For the hypothesised I/O controller, the purchaser can't be unhappy with anyone but himself for his having 250GB of unused disk space when the manufacturer did say there was a 750GB limit and the purchaser went ahead anyway with the purchase. However, he may reasonably (but perhaps not productively) be unhappy with the manufacturer for offering only a poor choice, or for the feeling that the manufacturer had not been entirely honest about describing why and how the controller was limited.

[Geoff Chappell]

Perhaps because OEMs and users are not qualified to make this decision...

That some OEMs and users are not qualified to make this decision may be true. That some, even many, OEMs and users do not have sufficient information to make this decision may also be true. But the point you say you were answering is that I just wanted everyone to be clear that the technical "complications" presented by Microsoft do not themselves explain why memory is disabled forcefully and irremediably. That you have supplied a possible explanation for the missing step is a useful amplification of my point, thank you.

... , as evidenced by this thread.

Ignorance in this thread is not evidence that OEMs and users aren't qualified. It may just be that they weren't well-informed.

Had Microsoft stated plainly that 32-bit Windows Vista has the code for using memory above 4GB but has disabled it because OEMs and users aren't qualified to decide about enabling it, then a) the patch that started this thread would likely never have been written and b) even if it had, a good proportion of contributions to this thread, about impossibility, would not have persisted beyond the first reference to Microsoft's statement.

There is no DIP switch, ...

Wow, for a "fair comparison" you state definitively that there is no DIP switch. Registry settings are to software as DIP switches are to hardware. Plainly, there is a DIP switch in any reasonable analogy.

... the I/O controller just doesn't enable >750GB support because it has not been tested for that case and there are known compatibility / stability concerns.

At least you're admitting into the analogy that the controller does have the circuitry. This is progress: when last I looked, Microsoft nowhere admits that 32-bit Windows Vista has all the code that Windows needs for using memory above 4GB.

As for its not having been tested, my elaboration of your analogy didn't say why it's disabled, just that it is and that the purchaser might not be happy to learn it was there all along. But let's take the analogy further, as you want.

This code is as much tested as any. By the time of Windows Vista SP1 it is exactly the code in Windows Server 2008. It is anyway not like the code was written yesterday. It's a decade old now. True, some prominent bugs didn't get shaken out until Windows Server 2003 SP1, but it's just not credible to say just that the code has not been tested for memory above 4GB. You depend on some important qualifications, which you ought to state, especially in a thread where you yourself have acknowledged that so many participants have the wrong idea. What you're saying is, at best, not that the Windows code for using memory above 4GB wasn't tested but that 3rd-party drivers weren't tested for how they work with the tested Windows code.

The manufacturer offers a free exchange for a version of the controller which does support >750GB without the caveats,

The original analogy doesn't go this far either, but if you push it this far, it's bound to break down. Operating systems are vastly more complex than I/O controllers. The change from 32-bit to 64-bit Windows is not just of one linear dimension.

To change the controller is relatively free of externalities. Changing an operating system is not. Quite a few people don't care very much to disturb their working installation of 32-bit Windows just for the sake of using all 4GB of their RAM. Not everyone likes the idea of a multi-gigabyte download, even for free, and an operating system reinstallation, which costs their own time and hassle, just to "fix" one thing that they see as a problem.

but for some reason you're deciding that you'd rather try to hack the thing to do something unsupported.

If you're going to impute intentions, please read the article and note what it actually says of my intentions. You have no business whatever to use language that even allows an inference that my intentions were to have users do something unsupported with 32-bit Windows instead of migrating to 64-bit Windows.

The "license data" is part of the product code. Changing that is unsupported and violates your license agreement.

When did registry settings become "product code"? Next you'll be saying that any time a user edits a registry setting except through an approved user interface they're violating the license agreement. Get real. No court in the developed world would go along with that.

Yes, changing the code, as in the hack, violates the license agreement. Changing it in order to test what the author of the software says about the software almost certainly supports a defence of fair use for the purpose of criticism - and that's even with it taken as stipulated that the license "agreement" is lawful and valid.

Computers in the last 3-4 years with 64-bit OSes and 4+ GB of memory are rare. That set is probably okay in this regard, but since they already have a 64-bit OS, the point is moot. This discussion is about machines which came with 32-bit OSes.

They're demonstrably common now. They were advertised in several flyers that came with the weekend papers. Note also that I said "pre-installed or available as an option".

True, 3-4 years ago, though more 4 than 3, even "available as an option" was uncommon. So, there will be some machines that do not have remapping. As I have said, at least I provide a tool with which users can discover this, and thus be saved from upgrading to 64-bit Windows only to find that they don't get the use of any additional memory (and indeed, get less efficient use of what memory they do have).

As I say, I don't know, but I don't think you do either - and you haven't supported your claim of rarity with anything more than an assertion. Although it has been common for 3-4 years to see fine print warning that the installed 32-bit Windows won't have the full use of 4GB, I find it hard to believe that this warning is the manufacturer's way of saying the machine does not remap. Anecdotal support for this is the sheer number of people who say they have upgraded to 64-bit Windows and magically got the extra memory into use. If remapping were rare, as you say, then this favourable outcome from upgrading to 64-bit Windows would also be rare, wouldn't it? Indeed, you'd think a lot more people would be more hesitant about recommending the upgrade.

Nvidia and ATI video drivers, for example.

Yes, they have 32-bit drivers that misbehave when memory is above 4GB. This is not disputed. NVIDIA has at least one on the Windows media.

But what of it? I didn't say there aren't examples of 32-bit drivers that misbehave. In what you say you were replying to, I wrote very specifically about constructing "a bug in a 32-bit driver that wouldn't have to be fixed when porting to 64 bits." Well, I should have stressed that I meant the code should compile correctly, but anyway, for your answer to be meaningful, ought you not be correspondingly specific?

C'mon, if you want to refute my point, show me a plausibly real-world code example that compiles without warning for both 32-bit and 64-bit, but which is buggy for 32-bit and not buggy for 64-bit.

Why an upgrade? Your license is already valid for both the 32-bit and 64-bit versions of Windows Vista or Windows 7. If you want a 64-bit (>4GB of memory) system, then use the 64-bit version. No need to "press Microsoft."

But the premise is of someone who wants, for whatever reason, "the everyday use of all 4GB on 32-bit Windows". Installing 64-bit Windows, as much as you may think it natural and desirable, does not satisfy the premise and therefore does not solve the problem.

For a solution, the user would have to get new license data from Microsoft. The license data would be exactly as for their current license but with less restriction on memory use. I call that an upgrade. What would you rather call it?

[Rigby]

But the premise is of someone who wants, for whatever reason, "the everyday use of all 4GB on 32-bit Windows". Installing 64-bit Windows, as much as you may think it natural and desirable, does not satisfy the premise and therefore does not solve the problem.

For a solution, the user would have to get new license data from Microsoft. The license data would be exactly as for their current license but with less restriction on memory use. I call that an upgrade. What would you rather call it?

There isn't a facepalm in the world big enough for that post. :wacko:

[Kpssst]

But the premise is of someone who wants, for whatever reason, "the everyday use of all 4GB on 32-bit Windows". Installing 64-bit Windows, as much as you may think it natural and desirable, does not satisfy the premise and therefore does not solve the problem.

For a solution, the user would have to get new license data from Microsoft. The license data would be exactly as for their current license but with less restriction on memory use. I call that an upgrade. What would you rather call it?

The question is: why would a user who knows they need to access all 4GB of RAM even consider buying a 32-bit version? If you need all that RAM, you would opt for 64-bit. It is "natural and desirable."

[Geoff Chappell]

The question is: why would a user who knows they need to access all 4GB of RAM even consider buying a 32-bit version? If you need all that RAM, you would opt for 64-bit. It is "natural and desirable."

Do you mean this is your different question which you'd now like me to answer, or that this is what you think was the question that I replied to?

My point in my reply, which you quote, is that saying there's no need to press Microsoft for a license upgrade does not deal with the problem as actually stated, i.e., the everyday use of all 4GB on 32-bit Windows. Installing 64-bit Windows solves a different problem. It may be much better worth solving but it is nonetheless a different problem. No matter how natural and desirable may be the solution to that different problem, some care ought be taken not to pass it off as solving the stated problem.

Just because someone would like that what's said about 32-bit Windows is at least plausible doesn't mean they should answer for why anyone might want to know about 32-bit Windows, let alone that they're against progressing to 64-bit Windows. I can't say that this simple point has eluded a large proportion of contributors to this silly thread but it has been at least as significant a contribution to the silliness as have those posts that insist 4GB is all the memory that any 32-bit operating system can possibly ever use.

[hdood]

Get over it. There's no such thing as a "license upgrade." The restriction is not a license issue, that is just a completely irrelevant implementation detail. It is an absolute limit on what is supported by the product, and one that is documented by Microsoft.

You seem to be under the impression that Microsoft exists to be nice to you personally, when it in fact exists solely for the purpose of making huge amounts of money. My prediction is that removing the restriction without dealing with the compatibility problems (which is really impossible) would end up costing Microsoft a lot more than they gain. A lot. It would likely also cause headaches for more users than it helps. Why would they do it?

If someone absolutely wants it, they should use one of the patches and shut up, instead of fantasizing about what Microsoft "could" do. That is my opinion. They said no back when this could have been argued to be somewhat relevant, so thinking something is going to change now in 2010 is completely delusional. I'm all for voicing ones opinion and frustration, but really, it is in no way constructive and shouldn't have gone past a single post.

[Rigby]

A Windows license is valid for both 32 and 64 bit versions, your single product key works for either one. You don't have to pay again.

This "license upgrade" stuff is nonsense.

[Stetson]

For a solution, the user would have to get new license data from Microsoft. The license data would be exactly as for their current license but with less restriction on memory use. I call that an upgrade. What would you rather call it?

Yes, the license upgrade is horrible! That whole $0 upgrade fee from 32-bit to 64-bit!

[Brandon Live Veteran]

But the premise is of someone who wants, for whatever reason, "the everyday use of all 4GB on 32-bit Windows". Installing 64-bit Windows, as much as you may think it natural and desirable, does not satisfy the premise and therefore does not solve the problem.

For a solution, the user would have to get new license data from Microsoft. The license data would be exactly as for their current license but with less restriction on memory use. I call that an upgrade. What would you rather call it?

Microsoft is at this time unwilling to supply a 32-bit client version of Windows 7 which uses PAE to address >4GB of memory. The reasons for this have been explained several times in this thread. It is not possible to justify such an offering from a cost perspective (testing, support calls) or user experience perspective (how do I know which drivers and software will work) when a more reasonable alternative (64-bit Windows) is already offered.

[Geoff Chappell]

Oh, yes, you're the one I gave up trying to reply to because of trouble I was having with the site. (I've been browsing it without running scripts or accepting cookies, and it's not the easiest to use this way.) No matter, it seems we can pick up the main point now that you've made it even more strongly:

You seem to be under the impression that Microsoft exists to be nice to you personally,

How on earth do my words reasonably give you this impression? Nowhere in this thread, and probably nowhere else, have I knowingly said what I think Microsoft ought to have done or what I'd have liked them to do. Where do you think I did that? I'm not even sure there's anything I especially would have liked them to do in the programming. My interest is only that whatever they did should be described accurately, by them and by others. (Whether this too is fantasising, I leave as another story.)

What I have done here is point out that various statements about what Microsoft has done in 32-bit Windows Vista and Windows 7 are not complete, and indeed are not true without qualification. In providing those qualifications, I'm not advocating them as alternatives that Microsoft ought to have implemented. If you think I have, then that would be a process not of impression (by me on you) but of supposition (all of your own).

Thus, if someone says there is a technical capability to have 32-bit Windows Vista use memory above 4GB but Microsoft would have had to write new code, I qualify by pointing out that the code was written, is old (and well-tested), and actually is in the product as shipped.

If someone says the code isn't tested, the qualification is that the missing testing is only with third-party products (just in case readers get the mistaken impression that the code still had to be tested for everything within Windows itself).

And so it goes, including to this thing about a license upgrade. If someone says there's no simple lawful way for a user of 32-bit Windows to have the use of all his 4GB, the qualification is that the most change required to Windows is a change of four bytes in the registry plus changes to some small files that support the tamper-proofing. Pointing this out in no way advocates that the license upgrade ought to be available. It is to say that if that's the problem you want solved, this is all you would need. It is to say to others: don't overstate what would be required.

My prediction is that removing the restriction without dealing with the compatibility problems (which is really impossible)

A qualification is surely needed there, too. The compatibility problems can't occur if memory above 4GB is prevented from being used. The restriction is necessary, without doubt. But a truncatememory option added to the BCD store by default would see to it, at least from the technical side. That's not to say this is what Microsoft ought to have done, but it is to say that any argument on the line that Microsoft had to do X to deal with the compatibility problems is incomplete without eliminating alternatives. You can't eliminate them without knowing of them.

Microsoft is at this time unwilling to supply a 32-bit client version of Windows 7 which uses PAE to address >4GB of memory. The reasons for this have been explained several times in this thread. It is not possible to justify such an offering from a cost perspective (testing, support calls) or user experience perspective (how do I know which drivers and software will work) when a more reasonable alternative (64-bit Windows) is already offered.

If anyone actually does want to use all their 4GB of memory on 32-bit Windows - remember that I myself have said that I'm astonished so many want to - and asks Microsoft for the simple change that allows this, Microsoft can then give your explanation of why the simple change is not available.

Meanwhile, Microsoft does not formally admit that working code for using memory above 4GB is already in the 32-bit products and people like you present explanations that are incomplete and even inaccurate. Let's be clear that these are contributing causes of much of the misinformation throughout this thread.

I only wanted to clear up what the patch must be and how it must work, since there was a lot of speculation and misinformation. I'd have done better to leave you all to it, which is what I'm doing henceforth.

[bogas04]

Cant read that much , so is 4gb ram possible in 32bit os without any major problems? Or will it just show total amount of ram in system properties?

[The_Decryptor Veteran]

Cant read that much , so is 4gb ram possible in 32bit os without any major problems? Or will it just show total amount of ram in system properties?

You can hack the kernel to get access up to 64GB of RAM (BIOS permitting)

Of course, it will result in problems, the problem free route is to get a 64bit OS.

[hdood]

Thus, if someone says there is a technical capability to have 32-bit Windows Vista use memory above 4GB but Microsoft would have had to write new code, I qualify by pointing out that the code was written,

Yes, the code is there, but the feature isn't actually part of the product. This is an important distinction. The fact that it's there is simply a side-effect of the fact that the same code is used in several separate and independent products (the server line.) You can find various other things in Windows 7 where the same applies.

is old (and well-tested), and actually is in the product as shipped.

If someone says the code isn't tested, the qualification is that the missing testing is only with third-party products (just in case readers get the mistaken impression that the code still had to be tested for everything within Windows itself).

As for it being tested, I believe that is only true for the Server editions of the OS. You could argue that the difference between the server and consumer editions are minor, but if the feature was enabled, separate tests would probably have to be done for the consumer editions as well. For Windows 7, it's very possible that it was not properly tested at all, since the Server version (2008 R2) it shares code with is 64-bit only.

The third-party thing is a big issue though. The entire ecosystem writes software with the assumption that the restriction is there. Some of this third-party software is even part of Windows, in the form of drivers.

Pointing this out in no way advocates that the license upgrade ought to be available. It is to say that if that's the problem you want solved, this is all you would need. It is to say to others: don't overstate what would be required.

Well, fair enough, but you are still understating what would be required on Microsoft's side. All a user has to do is patch a few bytes, but I think even you understand that Microsoft would have to do a lot more work than that in order to ship the feature.

A qualification is surely needed there, too. The compatibility problems can't occur if memory above 4GB is prevented from being used. The restriction is necessary, without doubt. But a truncatememory option added to the BCD store by default would see to it, at least from the technical side. That's not to say this is what Microsoft ought to have done, but it is to say that any argument on the line that Microsoft had to do X to deal with the compatibility problems is incomplete without eliminating alternatives. You can't eliminate them without knowing of them.

Maybe, but who is going to enable this option? OEMs cannot do it on systems they sell to their customers, because the customer will be installing arbitrary drivers that have not been tested with it.

Users could do it themselves, but who would they blame when the system started crashing? They would likely blame Microsoft and whoever they bought the machine from -- even though they themselves changed the setting, but chances are they didn't even understand it.

people like you present explanations that are incomplete and even inaccurate. Let's be clear that these are contributing causes of much of the misinformation throughout this thread.

I'm not sure what I have said that is inaccurate. I don't dispute any of the technical claims you've made (although I haven't followed the thread that closely), and I'm not quite sure what misinformation you are referring to. My point is simply that the feature isn't part of the product, and that it's completely irrelevant that the code is technically speaking there and functional.

If anyone actually does want to use all their 4GB of memory on 32-bit Windows - remember that I myself have said that I'm astonished so many want to - and asks Microsoft for the simple change that allows this, Microsoft can then give your explanation of why the simple change is not available.

Meanwhile, Microsoft does not formally admit that working code for using memory above 4GB is already in the 32-bit products and people like you present explanations that are incomplete and even inaccurate. Let's be clear that these are contributing causes of much of the misinformation throughout this thread.

But this logic makes no sense. Why would they "admit" that it's there? What does "admitting" that accomplish, when the code is unused and not part of the product, and is only there as a side-effect?

Microsoft does publish details on what the OS supports, and both the 4GB limit and the fact that it will be lower than that (3.25 or less) is published on Microsoft's site. That is all I would expect them to publish.

An explanation of the technical reason for the limit is not that relevant (although there actually is one on their site). Going as far as detailing how it's implemented (he license stuff) is just silly, and most companies in fact try to avoid giving out implementation details because they are internal and not something customers need to know. You could even argue that they shouldn't know, so they don't become dependent on it. This is of course generally speaking, but you can't work with the assumption that Microsoft would treat this specific feature any different from others "just because."

[LiquidSolstice]

This....is just sad.

[Robotic]

So to sum up.

1. It is possible to use more than 4GB in a 32-bit OS but normal Windows 32-bit client OSes don't enable it because of possible driver problems. I like this summary from Microsoft regarding memory and 32-bit systems :)

http://msdn.microsoft.com/en-us/library/aa366796%28VS.85%29.aspx

When neither 4GT nor AWE are being used, the amount of physical memory that a single 32-bit process can use is limited by the size of its address space (2 GB). In this case, a PAE-enabled system can still make use of more than 4 GB of RAM to run multiple processes at the same time or to cache file data in memory.

4GT can be used with or without PAE. However, some versions of Windows limit the maximum amount of physical memory that can be supported when 4GT is used. On such systems, booting with 4GT enabled causes the operating system to ignore any memory in excess of the limit.

AWE does not require PAE or 4GT but is often used together with PAE to allocate more than 4 GB of physical memory from a single 32-bit process.

Notice the use of more than 4GB for a single 32-bit application, but don't get your hopes up of finding available software that will do this. The only application I can think of off-hand is Testlimit by Sysinternals using the -a option. http://download.sysinternals.com/Files/Testlimit.zip If you guys want to see how much physical RAM is usable this utility will eat it up without touching the pagefile as AWE uses locked pages. You might need the psexec utility from http://download.sysinternals.com/Files/pstools.zip for the priviledge.

2. Will the hack work for you? Well I guess you will just have to try it to find out. There are no guarantees as there may be some driver issues. Check everything yourself and don't expect any support for using it.

3. There may be update issues in the case of a kernel update but since the hack supposedly uses a modified copy, this may be limited to just having to re-apply the patch with the newer kernel.

4. It's generally best to move onto 64-bit, if you easily can.

[Yuhong Bao]

Only if you hack Windows to allow >4GB addressing via PAE and have hardware that supports remapping of device addresses and supports >4GB of addressing. Finding such hardware is rare.

Luckily such hardware is unnecessary as both Windows and Linux can support using bounce buffers for software remapping instead on both PAE and 64-but, but drivers still have to be ready fo rthis.

Not to mention that hacking your kernel / HAL to allow it to even happen... which itself can destabilze your system, cause updates to fail, require re-patching it when updates are made, etc.

That is why Geoff Chappell recommend naming the patched kernel a different name and use bootloader options to load the patched kernel.

[Yuhong Bao]

That is precisely what we say (or rather, said, since we don't ship 32-bit Server SKUs any more).

Leaving no 32-bit version of Windows 6.1 being able to address more than 4GB of RAM with PAE without this hack.

[Yuhong Bao]

Microsoft is at this time unwilling to supply a 32-bit client version of Windows 7 which uses PAE to address >4GB of memory. The reasons for this have been explained several times in this thread. It is not possible to justify such an offering from a cost perspective (testing, support calls) or user experience perspective (how do I know which drivers and software will work) when a more reasonable alternative (64-bit Windows) is already offered.

Well, now there is 64-bit Windows, but the decision in question was made back in 2004 when MS had to enable PAE for the NX bit was added in XP SP2, which was when x64 Windows was still in beta, and it wasn't released until Server 2003 SP1 in April 2005. Why didn't MS take the opportunity to offer an non-default option to use PAE to access more than 4GB of memory back then? BTW, I talked about this issue via email with Larry Osterman, and this was one of the question I asked.

[The_Decryptor Veteran]

Because PAE driver support in end user products is pretty much non existent, so there's no point offering a configuration option for it.

[Yuhong Bao]

If you bought a license, then yes. I do not believe that it is available to end-users though.

Luckily, Windows Server 2003 SP1 and Windows Server 2008 Enterprise both support 64GB, and licenses for both are available to end-users though at a high price.

[farmeunit]

I can't believe I wasted 30 minutes reading this :blush:

On a consumer PC there is little to no point running more that 4GB anyway. If you want to try the hack go ahead. No one is stopping you.

[Yuhong Bao]

Luckily such hardware is unnecessary as both Windows and Linux can support using bounce buffers for software remapping instead on both PAE and 64-but, but drivers still have to be ready fo rthis.

Ignore. I was confusing hardware DMA remapping for old 32-bit devices with memory reclaiming, which are two different things.

[Yuhong Bao]

BTW, one reason to use 32-bit with PAE instead of 64-bit is that V86 mode is not supported in long mode, thus NTVDM is not supported in 64-bit Windows.