[Windows 7 Ultimate Sp1 64-bit Torrent
Rancul Ratha
Computers running 64-bit versions of Windows generally have more resources such as processing power and memory, than their 32-bit predecessors. Also, 64-bit applications can access more memory than 32-bit applications (up to 18.4 million Petabytes). Therefore, if your scenarios include large files and/or working with large data sets and your computer is running 64-bit version of Windows, 64-bit is the right choice when:
You're using add-ins with Outlook, Excel, or other Office apps. While 32-bit applications can work with add-ins, they can use up a system's available virtual address space. With 64-bit apps, you have up to 128 TB of virtual address space which the app and any add-ins running the same process can share. With 32-bit apps, you might get as little as 2 GB of virtual address space which in many cases isn't enough and can cause the app to stop responding or crash.
You have 32-bit MAPI applications for Outlook. With a growing number of 64-bit Outlookcustomers, rebuilding 32-bit MAPI applications, add-ins, or macros for 64-bit Outlook is the recommended option, but if needed you can continue to run them with 32-bit Outlook only, as well. To learn about preparing Outlook applications for both 32-bit and 64-bit platforms, see Building MAPI Applications on 32-Bit and 64-Bit Platforms and the Outlook MAPI Reference.
Upgrading from the 32-bit version to the 64-bit version of Windows requires that you reformat your hard disk, install the 64-bit version of Windows, and then reinstall everything else that you had on your device.
To install a 64-bit version of Windows, you need a CPU that's capable of running a 64-bit version of Windows. The benefits of using a 64-bit operating system are most apparent when you have a large amount of random access memory (RAM) installed on your computer, typically 4 GB of RAM or more. In such cases, because a 64-bit operating system can handle large amounts of memory more efficiently than a 32-bit operating system, a 64-bit system can be more responsive when running several programs at the same time and switching between them frequently.
I know that on a 64-bit version of Windows the "Program Files" folder is for 64-bit programs and the "Program Files (x86)" folder is for 32-bit programs, but why is this even necessary?
By "necessary", I don't mean "why could Microsoft not have made any other design decisions?" because of course they could have. Rather, I mean, "why, given the current design of 64-bit Windows, must 32-bit programs have a separate top-level folder from 64-bit programs?" Put another way, "what would go wrong if I somehow avoided the redirection mechanism and forced everything to install to the real C:\Program Files\?"
There are plenty of questions on Super User and elsewhere that assert "one is for 32-bit programs, one is for 64-bit programs", but none that I can find give the reason. From my experience, it doesn't seem to matter whether a 32-bit program is installed in the correct place or not.
Does Windows somehow present itself differently to a program running out of "Program Files (x86)"? Is there a description that shows exactly what's different for a program installed in "Program Files (x86)" instead of "Program Files"? I think it's unlikely that Microsoft would introduce a new folder without a legitimate technical reason.
It is not necessary. It's just more convenient than other possible solutions such as requiring every application to create its own way to separate 32-bit DLLs and executables from 64-bit DLLs and executables.
The main reason is to make 32-bit applications that don't even know 64-bit systems exist "just work", even if 64-bit DLLs are installed in places the applications might look. A 32-bit application won't be able to load a 64-bit DLL, so a method was needed to ensure that a 32-bit application (that might pre-date 64-bit systems and thus have no idea 64-bit files even exist) wouldn't find a 64-bit DLL, try to load it, fail, and then generate an error message.
The simplest solution to this is consistently separate directories. Really the only alternative is to require every 64-bit application to "hide" its executable files somewhere a 32-bit application wouldn't look, such as a bin64 directory inside that application. But that would impose permanent ugliness on 64-bit systems just to support legacy applications.
After looking at this answer and comment thread the next day, I realize a possible major oversight in my answer. I falsely assumed a programming background and when I was talking about you in my comments, I didn't mean the user, but the programmer.
I don't work for Microsoft and I have no clue what the real reasoning behind these folders is, but I think the reason to have these folders is so obvious that I have no problem arguing it.
A paradigm often found in programming, is to separate data from logic. You want one part that knows how to do something and you want another part you can do something with.
Installers aren't magic. They have to be written by programmers and are applications (with possible bugs) like any other application out there. So let's look at the situation an imaginary programmer would have to face with and without the current system:
The developer maintains 2 installers. One for the 32bit and one for the 64bit version of his application. The 32bit installer will write to C:\Program Files\App\ and the 64bit installer will write to C:\Program Files\App\sixtyfour\.
The developer maintains 1 installer. The installer will always write to %PROGRAMFILES% and depend on the operating system to expand the path accordingly (you actually don't use environment variables for these cases, you'd use SHGetKnownFolderPath with FOLDERID_ProgramFiles to retrieve the correct path).
Everything finds it's place automatically and the pattern is identical with every application you install.
Programmers will just go in there and try to load C:\Windows\system32\awesome.dll and not care about if they're running on a 32 or 64 bit system. They would try to load the 64bit DLL and simply crash. Some programmers want to use some Office DLL, no problem, they know where to find it! C:\Program Files\Microsoft\Office\14.0\wizards.dll... and another crash!
The WOW64 mechanism hooks into CreateProcess and will perform more sophisticated (more sophisticated than checking the folder name of the executable) checks on the executable image to determine if it is 32 or 64 bit.
Some questions don't require answers. It is not intended to be done, don't do it. There is nothing to be gained here. The amount of problems such a change could cause will always outweigh any possible benefits someone could see in this.
Well, everybody seems to be throwing in their opinions on this, so I'll toss in my 2. Others have already conjectured on the reasons as to why Microsoft chose to create separate top-level folders for 32-bit and 64-bit versions of programs, so I'll leave that part (the best reason was David's explanation that it is as a convenience to programmers). Of course even then, it doesn't quite address the direct question why is this even necessary?, to which the answer is presumably: it's not.
When you run a program, Windows sets up an environment in which to run it (I mean in terms of memory, addressing, etc., not just environment variables). This environment depends on the contents of the executable (32-bit and 64-bit programs differ internally). When you run a 32-bit program on a 64-bit system, it runs in the 32-bit subsystem which emulates a 32-bit environment. It is called WoW64 (WoW64 stands for Windows on Windows 64-bit) and is similar to how 16-bit apps would be run in XP using the NTVDM.
When you run a program with or without admin privileges, it affects how it runs, but the location should not affect it (though there are some examples of location dependency like some drivers for example).
(I am using a different computer, so I cannot rely on my browser history to backtrack my steps, but the other day while answering this SU question I ended up at this SO question which caused me to Google PROCESSOR_ARCHITEW6432 which lead to this SO question and this Microsoft blog posting.)
Somewhere along the way, I read a StackOverflow post about how the envirnoment variable %processor_architecutre% gives different results depending on where you run the command-prompt from (I'll try to find the exact quote).
The answer turned out to be due whether the 32-bit or 64-bit version of the command prompt was run (i.e., from System32\ or SysWoW64\). In other words, while the location seems to affect the program's behavior, it is only because there are different versions of the program, not because Windows treats the folder in a special way.
This makes sense because the executable file's contents dictate whether it is 32-bit or 64-bit, so you could put both a 32-bit and 64-bit copy of the same program (e.g., foobar32.exe and foobar64.exe) in the same folder and when you execute them, they will be loaded correctly (the 64-bit version will be run natively and the 32-bit one will be run in the WoW64 emulation layer).
795a8134c1