4 GB RAM in 32-bit Windows
As I have read everywhere, 32-bit Windows cannot handle more than 3 GB of RAM. A lot say not to install more than 3 GB of RAM.
My question is this: Assuming that I don't care that the last GB goes to complete waste, does having 4 GB of RAM installed while running 32-bit windows (ie. XP Pro SP2) HARM the system? In other words, will a 3 GB system actually OUTPERFORM a 4 GB system?
My question is this: Assuming that I don't care that the last GB goes to complete waste, does having 4 GB of RAM installed while running 32-bit windows (ie. XP Pro SP2) HARM the system? In other words, will a 3 GB system actually OUTPERFORM a 4 GB system?
0
Comments
If you install ntldr from a server 2003 copy and enable highmem (its a boot option you can put in the boot.ini) it will enable 34bit memory addressing (Bewhere this is very hacky and causes some really strange things).
support(dot)microsoft(dot)com(slash)kb(slash)284893
(forum won't let me paste links in normal format)
So 2 GB, in this case, is "superior" to having 4 GB. Although nobody really needs Sound Recorder (due to substitutes), I'm wondering if it might be an indication of a problem on a wider scale with other applications.
My point though, is that I'm not sure if the Sound Recorder problem is unique or if it could be a SIGN that many OTHER older apps may exhibit similar incompatibilities.
I doubt it. The executable itself is called sndrec32, and I'm not even certain the NT kernel OSes (NT, 2000, and XP) can run 16-bit applications natively. Moreover if 16-bit was involved we'd see problems at 2^16 bytes = 64KB.
What you guys are most likely thinking of is 16-bit audio. Yes, sndrec32 can record in 8-bit and 16-bit audio (most sound cards can't input/output more precisely than 16 bits).
I would suggest instead that the sndrec32 problem is caused by a signed integer mistake in its programming.
The title of the MS KB article is:
Here's an explanation. sndrec32 could store the amount of mem available into a signed integer, which has 31 bits of storage in addition to the sign bit. A huge unsigned value like 2.1GB has a '1' as the most significant bit, which doubles as the sign bit for signed integers, so 2.1GB and in fact every other value 2GB and over would look negative in signed form. So if the program compares mem_available < mem_needed, the expression could inadvertently evaluate true and the program would exit with an error like the one above. This mistake is probably easy to make because in C/C++, the signed integer is just called "int".
So my answer would be a similar mistake could potentially cripple any program until it got patched, but it's impossible to say how many programs like that are out there. The fact that we've heard about the problem only on a program as little used as sndrec32 indicates it isn't terribly widespread.
(I still have to decide 2gb vs 4gb myself so I'd be interested to hear more discussion)