Take advatage of 4GB+ RAM in Windows 7 32-bit

[ksoren]

http://www.msfn.org/board/index.php?showto...40&start=40

This was thread was closed, So I cannot reply...

cluberti, you are truly unbelievable. You meet a bit of resistance and then you close the thread?

If you some day get over yourself and actually research this topic, you'll realize how foolish your statements looks like. You have not understood what the physical and virtual address space really is or how paging works.

You know nothing about me or what I know, so how can you tell me that I know nothing about this subject? I can tell you this, I know more about it than you, obviously.

Are you going to close/remove this thread also?

[gunsmokingman]

You have no idea on how much cluberti, does know.

Wherea as you have shown how little you do know.

[cluberti]

Yes, and I'm going to call you out on rule 7b as well. I made it a point to be completely above-board, even when you've shown you're clearly not understood the architecture of Windows, and yet you come back and tell me somehow (again) that I'm wrong. 3 things, and I'll be done.

1. I know Windows Internals (both the book and the platform) like the back of my hand, and I've been working with the actual innards of Windows for 15 years. If you would read the documentation I linked in the thread, you'd understand that Windows handles PAE by loading a PAE kernel, which then allows for AWE calls to map physical pages into a virtual address space inside a process' VA range so it can access it (and manage it) directly. They're necessary for each other to work. I'm done discussing this.

2. The fact that you're bringing paging into this when physical memory pages mapped via VirtualAlloc AWE calls *cannot* be paged to disk is incredulous.

3. I know enough to know that you obviously understand the CPU architecture behind PAE, but you're also obviously not a developer nor have you ever had to actually write code for, or understand code running on, an x86 Windows PAE system.

You've had your time to make your arguments, and the fact remains that you still haven't understood the basics of the book you suggest others to read. Here was your quote:

So, have you gotten the point? That your explanation of AWE and that it is required to address physical RAM located above 4G is wrong? That you cannot use AWE to explain what PAE is? That you can remove the existence of AWE and still use RAM above 4G?

Let's dissect this, shall we?

"That your explanation of AWE and that it is required to address physical RAM located above 4G is wrong"

- Calling VirtualAlloc a specific way, also known as using the AWE APIs on Windows, *is* required (along with the PAE kernel being loaded) to address physical memory pages located above 4GB. This is *not* up for debate, and it's clearly documented on MSDN.

"That you cannot use AWE to explain what PAE is?"

- And why not? AWE is the API set, and VirtualAlloc specifically is the API called, used to map physical memory pages above the 4GB boundary into a process' VA. I didn't bother explaining all of the technical details in the Intel x86 architecture that allows for addressing of a 64bit PTE via the 4bit extensions to the processor necessary to address the RAM, because on Windows, I don't need to know the technical details of how this works to be able to utilize PAE on a Windows system - this is what the Win32 API is for. If you wanted a dissertation on PAE, you go to Intel and you download the PDF for the hardware, and you read it. But it still doesn't help you any on Windows, because you *have* to use the AWE API to access physical pages of memory above the 4GB boundary, so on Windows, for all intents and purposes, they are intertwined. Using one to bring in the other in a description of how this works *on Windows* is perfectly fine and valid, and I've explained this to people many times over this very way.

"That you can remove the existence of AWE and still use RAM above 4G?"

- On a Windows system, *no*, you cannot *not* use the AWE API and still use RAM above 4GB. If we're speaking from a developer perspective, this is the API set used to allocate physical pages of memory into a process' VA, and it's the only way short of writing a device driver and bypassing the OS entirely (and even then, you aren't bypassing the kernel entirely). Next, if we're speaking of how the Windows OS itself can put the VA of a process into memory above the 4GB boundary, how do you think it does it? Is there a memory allocation API lower than VirtualAlloc? No, there isn't.

Now that I've discussed this even further than I wished, I'm following through on my initial statement. Violation of rule 7b (not to mention the spreading of misinformation, which isn't a rule violation but should be) gets you banned. Congratulations.