What's the difference between 32 bit OS and 64 bit OS? Can a 32 bit OS run in a 64 bit processor?

  • If you're talking about Windows (and the Win32 tag seems to indicate that), then yes, absolutely - Vista and Win7 64-bit support almost all 32-bit apps through a compability layer - I haven't found anything yet that doesn't work just fine on Vista 64-bit (except for system-level drivers)
    – marc_s
    Jul 20 '09 at 11:15
  • 6
    The question seems more whether you can install say Win Vista x86 onto a box that have a 64-bits processor, rather than whether x86 apps run on say Win Vista x64.
    – KTC
    Jul 26 '09 at 0:14

Your question is architecture specific. x64 is essentially an extension to x86 architecture. It supports a 64 bit address space. It provides some new instructions and new registers.

You can run 32-bit x86 Windows on an x64 machine. Note that you can't do this on Itanium 64-bit systems.


A 64 bit processor can run both 32 and 64 OS (at least an x64 can). A 32 bit processor can run only 32 natively.

The difference is mostly about the size of a Pointer/Reference. On 64 bit machines, you can reference an address in a 64 bit address-range (thus giving you 2^64 bytes of memory). On 32 bit you can only address 2^32 bytes (=4 GB). Now if you look at current computers it is obvious why the world is moving to 64 bit: 32 bit can't easily address all the RAM anymore.

On x64 (AMD/Intel) you have additional benefits of 64 bit. The CPU has more registers and thus allows more efficient code.

On other architectures the differences between 64 and 32 bit are less obvious. For example the Nintendo 64 (remember that?) was a 64 bit machine but most of its code was 32 bit. So in that case 64 bit served more as a marketing trick.


The currently-accepted answer is generally correct but not specifically so. There really isn't a single thing called a "32-bit CPU" or a ""64-bit CPU" - that's a description that refers to only one small part of the architecture of the CPU. In particular, it references the number of address selection lines between the CPU and the memory, i.e. the so-called address space available for memory operations.

In the days of yore when the CPU when people used to sit down and weave (wrap) the wires between a processor and the memory, you would have had to use either 32 or (theoretically, because it didn't exist at the time) 64 wires between the CPU and the memory controller that would be used to specify which memory address you wanted to access. For example, let's say we have a 2-bit memory architecture: sending 00 would select address 0, 01 would select address 1, 10 would select address 2, and 11 would select address 3. This 2-bit gives us 2^2 bytes of RAM (4 bytes).

If you take a 32-bit CPU and you add on 32 more wires between the CPU and the memory controller so that you're magically able to support more memory, you now have a "64-bit CPU" that can run 32-bit code or 64-bit code. What does this mean and how does this happen? Well, let's take our 2-bit CPU from the earlier part of this answer and add another wire, turning it into a 3-bit CPU, taking us from 4 bytes to 2^3 or 8 bytes of RAM.

Existing "2-byte" code will run, setting the values of the last 2 wires like indicated above (00-11). We'll wire the extra connection to be zero by default, so actually when the 2-byte code runs, when it selects 00, it's actually selecting 000 and when it selects 11 it's actually selecting 011. Easy.

Now a programmer wants to write "native" 3-byte code and writes her software to take advantage of the extra address space. She tells the CPU that she knows what she's doing and that she'll take manual control of the new, extra wires. Her software knows about the extra wire(s) and correctly sends out 000-111, giving her full access to the range of memory supported by the this new CPU architecture.

But that's not how it has to happen. In fact, that's normally not how things happen. When 64-bit CPUs were first introduced (and there were many), they all went with entirely new architectures/designs. They didn't just tack on an additional 32 wires and say "here you go, this is a 64-bit CPU you can use in 32-bit or 64-bit mode," but rather they said "This is our new CPU and it only takes programming in this entirely new machine language, behaves in this entirely new way, solves a bazillion different problems far more elegantly than the old x86/i386 32-bit CPUs ever did, and it's a native 64-bit architecture. Have fun."

That was the story of the Intel Itanium, now famously known as the "Itanic" because of how massively it sank. It was supposed to herald in the new 64-bit era, and it was something to behold. Variable length instructions, huge caches, 64-bit address space, tons of registers, super exciting, super cool, and super hard to convince everyone to recompile or rewrite 20 years of legacy code for. This was back when AMD and Intel were actually competing, and AMD had the brilliant idea of saying "let's forget all this 'solve all the world's problems' business and just add 32 more wires to the i386 and make a 32-bit compatible 64-bit CPU" and the x86_64 CPU architecture was born.

In fact, if you look at the kernel names and sources for major operating systems (Linux, Windows, BSDs, etc) you'll find them littered with references to AMD64 CPUs and AMD64 architecture. AMD came up with a winning strategy to get everyone to switch over to the 64-bit world while preserving compatibility with 32-bit applications, in a way that a 32-bit OS could run on 64-bit hardware or even 32-bit applications could run on a 64-bit OS on 64-bit hardware. Intel followed suite sooner rather than later with their "Intel EM64T" architecture (which was basically identical to AMD64) and x86_64 won out while the Itanic and others like MIPS64 and ALPHA64 were seen no more in the desktop/server market.

tl;dr amd64 aka x86_64 CPUs are designed to be compatible with both 32- and 64-bit kernel and code, but most 64-bit CPUs are decidedly not backwards compatible in the same way. A 32-bit CPU can access at most 4GiB of memory, while a 64-bit CPU can access a stunning 16 EiBs (16 × 1024^6 bytes, or 4 billion times as much memory as 4GiB).

  • 1
    You have a few factual errors: 1) the itanium did not introduce variable length instructions ( every x86 has had them ); it added very long word instructions, which were capable of concurrently operating on multiple 64 bit quantities. 2) x86_64 did not just slap on more address lines; it also added a bunch of extra registers, and widened all of the registers ( and the ALUs that operate on them ) from 32 to 64 bits. Compare this to the 8086/8088, which added 4 more address lines and segment selector registers, but kept them all at 16 bits, like the 8080 before it.
    – psusi
    Nov 1 '15 at 18:10

Both a 32 and 64 bit OS can run on a 64 bit processor, but the 64 bit OS can use full-power of the 64bit processor (larger registers, more instructions) - in short it can do more work in same time. A 32 bit processor supports only 32 bit Windows OS.

  • 3
    This is incorrect generally, though correct for x64 specifically. Jul 30 '09 at 18:28
  • 1
    A 32 bit processor will run any operating system designed to run on such a processor architecture.
    – Waxhead
    Nov 29 '11 at 18:48
  • a 32-bit x86 OS obviously can't run on ARM64, so 32 and 64 bit OS can run on a 64 bit processor is generally not correct
    – phuclv
    Oct 3 '15 at 5:24
  • @Phúc There might be 64 bit processors, which do not support their 32 bit twin. However you use false logic in your argument. SunOS 4.4.1 on 32 bit MicroSparc won't run on ARM32 either. Using your logic means, it is generally not correct that a 32 bit OS can run on a 32 bit processor. If I ignore common sense like you do, I can argue, that 32 bit ARM OS runs on Intel i386/x64, as Android developers run Android ARM images on their Wintel machines. Of course the OS is for the right processor family and of course the OS runs on physical hardware and not emulation (enough said, out)
    – Tino
    Jan 20 '17 at 10:52