57

The difference in size for the Windows 8 Consumer Preview ISO images, between the 64 bit and the 32 versions is 800 Mb or a difference of 24%.

I've never seen a difference so large.

Why is there such a big difference?

Sathyajith Bhat
  • 61,800
wizlog
  • 13,335

3 Answers3

77

There are several reasons for the size discrepancy:

  1. 64-bit Windows contains a translation layer (Windows 32-bit on Windows 64-bit, or "WoW64") that allows it to run 32-bit software.
  2. 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.
  3. 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.

Breakthrough
  • 34,497
rob
  • 14,228
  • 4
    its 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 Mar 01 '12 at 09:51
  • 27
    I 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 Mar 01 '12 at 10:10
  • 10
    For (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 Mar 01 '12 at 12:19
  • 3
    @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 Mar 01 '12 at 12:29
  • @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 Mar 01 '12 at 13:42
  • 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 Mar 01 '12 at 14:37
  • @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 Mar 01 '12 at 14:53
  • 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 Mar 01 '12 at 14:57
  • "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 Mar 01 '12 at 15:01
  • @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 Mar 01 '12 at 16:11
  • 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 Mar 01 '12 at 16:18
  • 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 Mar 01 '12 at 16:24
  • wouldn't 64 bit asm be larger due to the larger address space? plus some extra instructions/longer op codes? – Cris Stringfellow Mar 01 '12 at 17:25
  • 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 Mar 01 '12 at 17:36
  • I'm getting kind of confused now. Is rob right or not? Can someone please offer a different answer if he's not? – wizlog Mar 02 '12 at 00:01
  • 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 Mar 02 '12 at 01:05
  • 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 Mar 06 '12 at 05:24
  • @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 Mar 06 '12 at 09:50
  • @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 Mar 07 '12 at 12:40
11

In 64bit-versions, Microsoft deploys additional software. For example, there are two versions of Internet Explorer (64 and 32bit). Another example is the whole runtime system for Win32-applications.
Also, binary code will get bigger. Probably the sum of this these makes the big difference.

Community
  • 1
HCL
  • 649
2

64-bit versions is generally bigger that 32-bit version for a couple of reasons.

The first thing to consider is the type of compiler and the runtime environment where the software executes. If the software is built with a compiler that produces native code and runs without a runtime environment, it is possible to see small differences in generated code size, which is related to larger instruction set in CISC processors.

Second, if the software is compiled to run under a runtime environment, such as .NET, you will not see any size differences, since the compiler generates the same (intermediate) code.

Finally, the 64-bit version of Windows contains the complete 64-bit version with some of the 32-bit version counterparts. This is required since some software is 32-bit and need to run without modification in Windows 64-bit.

Chris Mylonas
  • 21