PAE Driver Problems?

http://social.technet.microsoft.co [...] vista&ac=8

Firstly, the use of PAE extensions to expand address space is not prermitted in consumer versions of the OS. You must use a server version to do that: NT, 2003, etc. PAE also requires all of your applications and drivers be written as Large_Address_Aware in order to handle the 36 bits of address space which can be granted. Meanning, if you installed an app that isn't written to take advantage of PAE, then you gain nothing. The same is true of your drivers, except worse: If they weren't specifically writen as Large Address Aware, then not only do you not gain any address space, but they WILL crash your computer *every* time they are given a reference outside the usual 32 bits.

You may have noted I mentioned 36 bits of address space. PAE in NO WAY, SHAPE, OR FORM turns a 32 bit OS into a 64 bit one. Go find whoever told you that, and kick him in the nuts for being stupid.


Regarding switching to 64:


Microsoft do not allow anyone to use the "Windows" logo on any product unless it has 64 bit drivers and works properly on 64 bit Windows. Let me say that again in case you don't want to understand: If It Has A Windows Logo, Then It Is Certified To Run, period. End of discussion. Download 64 bit drivers from the exact same place you get the 32 bit ones, install them, and get on with life. It's not hard.

Why is this so??



On the processor side:

The CPU reads the actual binary code, which is presented in the form of instructions. These instructions are the "x86" and "x64" that you read/hear about. Now, most people understand that an x86 Processor (pre~2003, 2004) can't run x64 code. That's because the newer standard has commands, syntax, instructions, and data sets that do not exist in the older one. BUT: Understand that the newer x64 instruction set includes everything in the x86 - So any x64 processor can and will fully handle anything that's x86. Indeed, if your processor is a Sempron, P4, or newer, it *is* an x64 processor.

Therefore, as long as the (game) was compiled to the x86 (32bit) standard, the CPU can fully understand and run it because they are still 'speaking' the same language. And the reverse isn't true: Imaging speaking to a grade school child with words and phrases an MBA can use. The kid (older standard) won't understand it. The MBA can fully understand the child, though.



On the side of the OS: There is a similar mechanic, though here it's called an "API" (Application Programming Interface). In very broad terms, it works like the instructions sent to a CPU: These are the commands and formats programmers use to talk to the Operating System, which they use to access system resources like memory and information on the hard drive. You can think of it like the teller window at the bank: It's your way to pass an instruction inside in order to get the result you want. When you go to the teller (API), you have to give her a message [/i](instruction)[/i] in the format that that she understands, right? The OS wants to see some Function (Withdrawl), the location required (Account #), and some data set (how much). If you give the teller (OS) that, then you'll get your twenty bucks.

As long as the program (game, whatever) follows the proper API's then it will run on the Operating System.

Therefore: As long as a given (32 bit) game is written to the proper Windows (Vista) API's, and compiled to run on an x86 processor, then it *will* run on 64 bit (Vista).


Generally speaking, when you hear about incompatibilities it's because the programmers who wrote a given application either did not adhere to the proper API spec when they wrote their code, or because they took short cuts (which may no longer work), or because the (new) Operating System's API set is different from the old one.