By your logic a 16 bit OS is limited to 64 KB of memory but we all know intel developed routines so that x86 machines could access at least a megabyte. They achieved this by calculating the physical address by routines involving Segment/Offset addressing - the segment address is bit shifted left 4 bits and added to the offset address to obtain the real address - thus a maximum number of FFFF becomes FFFFF. To do this involved several CPU cycles but because these had direct access to the CPU registers they were fast. However such direct access to the hardware by software was not desirable for security purposes which was why IBM created OS/2 2 as a 32 bit OS while Windows 3.1 relied on 16 bit DOS. When Windows 95 came out M$ provided true 32 bit addressing but only OS/2 2 completely controlled access to hardware. Surrendering control of the hardware to the OS was something programmers took a while to adapt to - but OS/2 required it whilst M$ semed intent on creating ways around it. Obviously it is easier to use 32 bit registers to get true long pointers but as this system worked in 16 bit OSs it obviously works in all. Whether it is desirable to go back to older technology is probably why Microsoft decided to disable PAE - if indeed they did.
x86 architecture uses 32 bit address registers - 2^32 = 4,294,967,296 (4GB) - its a mathematical certainty, it will never overcome that. In modern day x86 architectures (since Pentium Pro) they have introduced PAE (Physical Address Extension). This effectively increases the size of the address registers from 32 to 36 bit : 2^36 = 68,719,476,736 (64GB). All 32 bit microsoft OS's since XP (and some ver. of 2000) support PAE, however microsoft have limited the amount of physical memory in their 32 bit desktop version OS's to 4GB. They have done this for driver compatibility reasons. Most of the drivers that come with windows are third party drivers and you have to very specifically code for the PAE switch - most suppliers have not done so and it would cause a very unstable system if MS did not control how PAE was used. 32 bit servers can go up to 64GB as MS strictly controls which drivers are distributed with them. I have no Idea what this "Ready for 4GB" patch does for any one - your OS already sees and uses what it can. (Don't forget the 4GB address pool is not only for DIMM RAM, it is used to address all your hardware - which is why you don't always "see" your full DIMM RAM.)
Well for months on two different computers with 6gb ram been running Win 7 x86 Ultimate dual boot with an unpatched and a patched ntkrnlpa.exe. When booting into the patched version all 6gig available and surely utilize all. Just for testing assigned 4gb ram to a virtual pc which ran smoothly when booting with the patched version. When booting with the unpatched it said as expected "not enough memory on host". There has been no issues at all for three months, both pcs run so far 100%. That is my experience, not saying everybody else would have had the same experience. And yes I am not out of my mind
No they didn't, read the Microsoft link in my previous post. Before XP SP2, windows was installed with a default of PAE disabled. With XP SP1 your RAM was limited to 4GB but the physical address space was not. This meant people with 4GB of RAM and proper hardware and BIOS support could utilize all 4GB of RAM with the /PAE boot option simply because they had access to RAM that was remapped above 4GB. Although PAE needs to be enabled, with proper BIOS and hardware support it is not PAE which is stopping you accessing the full 4GB or more but the windows memory manager. In Vista and Seven 32-bit client OSes it seems MS has thought about utilizing the memory remapped above 4GB by including the necessary code in the kernel but has decided for now to keep it capped using a protected registry key. I haven't used Ready4GB but am aware that by a simple kernel modification it is possible to ignore those registry settings.
Firstly - X86 microprocessors originally used 16 bit registers. It was the 386 that used 32 bit registers. You will note I prefaced my statement with reference to 16 bit. Secondly - You are simply wrong - the ability to address more memory than the largest number a register can hold predates not only the Pentium Pro but all 32 bit processors. Dos was a 16 bit OS that could address 1 MB despite 65536 being the largest number that a 16 bit register can contain - and ran fine on 8086 processors. If you don't understand the segment/offset addressing model then you probably do not have the capacity to understand how the use of this scheme allowed an address space of 1 MB using 16 bit registers which can only hold a number of FFFF hex - or 64KB. By shifting the segment address left 4 bits the largest number became FFFFF hex - 1 MB. Obviously, using this model if you can shift the segment address in 32 bit space you can address significantly more memory than the strict 4 GB limit that appears to be the limit calculated mathematically - although, initially the 4 GB limit seemed so huge that additional schemes to expand beyond this did not seem necessary. The only mathematical certainty is that there were workarounds to the limiting model of the original IBM PC - and the segment/offset address model was the answer adopted. You can argue all you like - this is fact. Those of us who can remember will note Bill Gates once said that no one will ever need more than the 640 MB of the original IBM PC model.
There are work arounds, such as PAE, However It still doesn't unlock the limit on how much ONE software can allocate RAM for. Yes you can USE the 8 GB or what ever of RAM, if you use multiple programs which use up that 8GB. However if you think you can use 1 program to eat up the whole 8GB then you are mistaken.
In my opinion, stay away from fixes like this. While others have installed it and continue to operate in a stable manner, the better option is to go 64-Bit. Remember that 32-Bit software can be installed, so if say Photoshop's 64-Bit version works oddly, install the 32-Bit version. The point is, you'll have better stability long-term going with the standard whereas going off and using workarounds can bite you if problems occur. Besides, if you require 32-Bit and need greater memory access, Windows Server 2008 32-Bit can access 64GB of RAM, and this sounds like the safer approach.
A little off topic I have 64 Win 7 with 4 gig installed but windows only show 3.5 Bios and cpu-z show 4 any ideas?
DOS is a 16-bit thing, but it can address more than 65536 bytes. You see, all it has to do is to do something like make the paging blocks into something with 32-bit addressing, and in theory, you could have 16 Tb of addressable memory (4 G * 4 K). 4 G is simply the limit for addressing every byte singularly. Going to word-addressing would push it to 16 G.
Any non-noob know that Server platforms has many cpu sockets with their own Memory. OS controlls ALL sockets memory independent. For example socket #1 cant allocate ram in socket #2 memory. Eh..noobity owns.. And the last one, Temp999 gratz with allocating 7+gb of VIRTUAL RAM. Try to allocate a SOLID block of 7GB....I wonder if its possible with 32bit pointers lol. By the way, FYI, 32bit server systems (with 4GB RAM) has 3.95GB to allocate because device address space was truncated. So, It's bad example. Learn TechNet more and be happy. There is no spoon, guys. The spoon will be there if your's MB is MULTI SOCKET. P.S: Don't count on PAE too much on SINGLE socket MB. It's not miracle and almost useless.
Believe it or not, I was not trying to contradict you. I was referring to modern processors - I should have been more clear. I never said any thing to the contrary. I just pointed out PAE was widely available from Pentium Pro. No need to get snooty! If you just shift bits you will lose info - that is a fact . It worked because of the 16bit segmentation registers, and as you correctly say it shifted bits 4 places left and this effectively provided a 20bit address from the 32bit segment-offset pair allowing 1MB. Your quote below is my point This just proves what I was trying to say: 16 is 16; 32 - 32, you can't get past that unless you implement some sort of workaround, such as PAE which increases the address size of the CPU(32 to 36bits) (or as they did on the 8086 - 20bit address on 16bit architecture). Yeah, I'm sure he still feels like a bit of a twat over this one.
Looking at that article for AWE, it looks like it has to be written in to the programme? I wouldn't think there would be too many programmes with this feature. Even if they did, or you can make it so with any 32 bit programme, why the non-embracement of x64?