Ok that was my misconception, 64-bit processes will take a little extra memory, that is a result of the memory pointers being a little bigger to address the larger amount of RAM, but not actual double in size.
saying it uses a "little" extra is an overstatement. Also, last time I checked, the new handle size of 64 bits is double the old one of 32-bits. These are the pointers- NOT the actual data. the actual data being pointed to will still consume the same amount. that 512MB that Office applications allocate for no reason when you start them will still be 512MB. (heh)
Sure, each handle is now 4 bytes larger. Woopdee doo.
AND- this only applies to programs that are compiled to 64-bit. 32-bit programs, which still constitute a vast majority of programs (Office is still purely 32-bit, for example) still use 32-bit handles as they did before, and consume no extra memory then they would running on win32.
Also- Disk space being consumed by a 64-bit compiled application compared to the same application compiled as 32-bit is negligible, except in cases where the author has huge blocks within "#IF WIN32" or #IF WIN64", which would vary the compiled code size.
the PE32+ format (which is used for 64-bit compiled Windows applications) is exactly the same as the PE format; in fact, the PE32+ format has a lot more in common with the PE format then the PE format did with the NE format.
In contrast to the Win32 exception handling, Win64 (both x64 and Itanium versions) uses table-based exception handling. No linked list of try data blocks is built on the stack. Instead, each Win64 executable contains a runtime function table. Each function table entry contains both the starting and ending address for the function, as well as the location of a rich set of data about exception-handling code in the function and the function's stack frame layout. See the IMAGE_RUNTIME_FUNCTION_ENTRY structure in WINNT.H and in the x64 SDK for the nitty-gritty on these structures.
The table-based format used for SEH in win64 is both faster and consumes less memory then the win32 version.
Source:http://msdn.microsoft.com/en-us/magazine/cc300794.aspx
Here's the interesting bit; Any properly written Win32 program should be able to compile as a 64-bit application with no changes. The problem is the same as it was when 32-bit came around- moron programmers who decide, "well, golly gee, this pointer is the same as an INT type, so I'll save myself some typing by using INT instead of HWND or HDC or HANDLE..." and then, big surprise, 32-bit came around MS changed the HWND, HDC, and so on typedefs to now be 32-bit integer types, and whaddya know, the program stopped working.
And at least then they had an excuse- it was the first major switch between bit widths (earlier versions switched between 8-bit and 16-bit, but nobody really cared then), and, the addition of hundreds of new APIs, a completely new interface, and so forth.
the win32 to win64 switch has no such things. they added two functions though- and they are purely to determine if your running on a 64-bit machine from a 32-bit program (IsWOW64Process()).
Vista doubles memory usage requirements over WinXP and Win7 uses much less.
That has absolutely nothing to do with win32 versus win64 memory consumption. And Windows 7 does not use much less then windows Vista.
What will increase with 64-bit Windows is the amount of drive space needed for the operating system with a compatibility layer in place.
Yeah, almost 0.1 percent of my hard drive is consumed by my syswow64 folder. Hard drive space consumption is completely inconsequential. the disk space used by windows has increased a lot from the early days, but people seem to ignore the fact that nowadays games are coming on 3 disc-DVD sets and taking upwards of 60GB of disk space when they used to fit on a floppy disk. Dunno why the creators of those games don't get yelled at.
On the other hand, consider that all the compatibility stuff for 16-bit applications has now been completely eradicated.
