Why is the 64-bit version of Windows bigger than the 32-bit version?

There are several reasons for the size discrepancy:

64-bit Windows contains a translation layer (Windows 32-bit on Windows 64-bit, or "WoW64") that allows it to run 32-bit software.
64-bit Windows also contains 32-bit versions of various programs (Internet Explorer) and libraries (in the WinSxS folder). As noted in the comments, this is the most significant reason for the size difference.
64-bit memory addresses are twice as long as 32-bit memory addresses, so 64-bit pointers are also twice as long. 64-bit programs that make heavy use of pointers will be noticeably larger than their 32-bit counterparts.

The first and last reasons do not contribute nearly as much as the 32-bit software that ships with 64-bit Windows - but for the sake of completeness, they should be considered.

rob

Posted 2012-03-01T07:39:09.983

Reputation: 13 188

4its mainly due point 1: the sxs folder inside the .iso is 177m for 32bit, 315m for 64bit. the windows folder inside the install.wim inside the iso is 7.9g for 32bit, 11.9g for 64bit. and inside that folder we have again WinSxS which is 3.9g for 32bit and 6.9g for 64bit. the side-by-side stuff is the biggest chunk of data here and it's there for both 32bit and 64bit apps in the 64bit version of windows. having bigger binaries and some double versions of applications has almost no impact on the size of the isos. – akira – 2012-03-01T09:51:47.790

27I don’t see how point 3 would impact the image size. Very few pointer values are hard-coded into the source code. Only those would take up space in the software binary (rather than the RAM image once the software is run). – Konrad Rudolph – 2012-03-01T10:10:32.973

10For (1), all the Wow64 .DLL's take up less then 1MB on my Win7 Pro installation. For (3), @KonradRudolph is correct. There is no true reason for intrinsic code bloat from moving from 32 to 64-bit - a few opcodes changed, although most are still only 32-bits wide (x86 is a variable-length instruction architecture). The majority of this discrepancy arises from (2). – Breakthrough – 2012-03-01T12:19:13.920

@akira The sxs folder has to do with (2), not (1). The side-by-side assemblies are not part of WoW64, although the 32-bit DLLs are executed under WoW64. However, the WinSxS folder is there to provide 32-bit and 64-bit binaries for programs which require the respective DLL - essentially having both a 32-bit and 64-bit version of the DLL.

– Breakthrough – 2012-03-01T12:29:53.280

@Breakthrough: true, but the vast majority of apps which make actually use of sxs are not delivered by the .iso ... 3rd party apps. but for those apps that sxs layer exists. so, the "truth" would be just that: the sxs folder is damn big. and its neither 1) nor 2) but something in between :) – akira – 2012-03-01T13:42:46.200

1@akira: The SXS folder does not consume space. It's a place where links (technically, junctions) to DLLs are collected. All of those DLLs have another place in the filesystem. Therefore, the SXS folder does not contribute to the disksize needed. – MSalters – 2012-03-01T14:37:02.597

@msalters: while technically correct (the very best kind of correct), winxsx does indeed contribute to the required disk space because windows cannot tell the difference when calculating disk space whether something in 2 locations is a pointer to a single file. So even though they don't technically take up disk space, explorer thinks they do and therefore you can't use the full size of the drive. – horatio – 2012-03-01T14:53:45.617

2@horatio: The "therefore" conclusion is wrong. Explorer checks the NTFS free space, which properly accounts for junctions. (You can see this because Explorer takes 1 minute+ to sum all file sizes, yet knows the free space instantly). – MSalters – 2012-03-01T14:57:31.353

"The Windows shell will count each reference to a hard link as a single instance of the file for each directory the file resides in. For example, if a file named advapi32.dll was 700 KB in size and was contained in the component store and the \Windows\system32 directory, Windows Explorer would inaccurately report that it consumes 1400 KB of hard disk space." (see: http://support.microsoft.com/kb/2592038 )

– horatio – 2012-03-01T15:01:12.753

@horatio: That causes Explorer to report the size of the Windows folder incorrectly, but explorer doesn't actually use that information to calculate free space, so MSalters is still correct. For example, if you run a command to reduce the size of the sxs folder, you will notice the size of the sxs folder drop significantly, yet your free-space will not change at all. See also

– BlueRaja - Danny Pflughoeft – 2012-03-01T16:11:02.210

If you have a small enough partition, the false reporting WILL interfere with your ability to install programs. Note that the remedy in the link I provided suggests removing unrelated files etc to free up space, and suggests no remedy for the misreporting. – horatio – 2012-03-01T16:18:39.547

also note that your link really only affirms what I am saying: "It’s critical that any path expected by an application appear as a physical file in the file system to support the appropriate loading of the actual file. In this case, the shell is just another application reporting on the files it sees." – horatio – 2012-03-01T16:24:03.893

wouldn't 64 bit asm be larger due to the larger address space? plus some extra instructions/longer op codes? – Cris Stringfellow – 2012-03-01T17:25:47.750

3@CrisStringfellow: no one doubted that. but the effect on the overall size of the iso images is almost nil. the main chunk of the size-increase is caused by delivering 64bit AND 32bit stuff (some apps, lots of dlls [mostly found inside the WinSxS folder in the .iso]). – akira – 2012-03-01T17:36:17.783

I'm getting kind of confused now. Is rob right or not? Can someone please offer a different answer if he's not? – wizlog – 2012-03-02T00:01:12.593

The debate is about how much each factor contributes to the added size of the 64-bit version. For the sake of completeness, I'd still say all three do play at least some part in the increased size. Most of the difference comes from the duplicate applications and libraries. – rob – 2012-03-02T01:05:02.993

Okay i think the size increase in iso is clear cut, but @Konrad Rudolph isn't ASM full of pointer addresses? it's always moving things around in memory, and if an op doesn't reference a register it has to register a pointer. And any kind of complex high level objects (translations) should have lots of pointers hard coded into them right, when in ASM -- what am I missing? – Cris Stringfellow – 2012-03-06T05:24:20.517

@Cris Pointers, yes. But the addresses aren’t stored hard-coded in the binary, they are calculated at runtime. So they have no influence on the executable size (in very rare cases you’d hard-code an address, such as when writing a device driver, and in the special case of the null pointer constant. But this is a tiny, tiny fraction of the overall size of the executable). – Konrad Rudolph – 2012-03-06T09:50:41.137

@KonradRudolph just something worth noting: Since in C (as well as C++) the NULL constant is commonly equal to 0, optimizing compilers will note this, and as per the C-standard, all variables take an initial value of zero. For these variables, the constant values in their opcodes can thus be omitted, and placed into the base segment of the code (as opposed to the data segment, where each variable is defined with an explicit value). This also reduces the size increase of the executable, further supporting your viewpoint. – Breakthrough – 2012-03-07T12:40:15.253

Why is the 64-bit version of Windows bigger than the 32-bit version?

Answers