Poglej prejšnjo temo :: Poglej naslednjo temo |
Avtor |
Sporočilo |
trot Administrator foruma
Pridružen/-a: 15.12. 2006, 15:34 Prispevkov: 15166
|
Objavljeno: 28 Nov 2012 10:49 Naslov sporočila: Zakaj 64-bitni sistem potrebujete dodatn mapo |
|
|
Zakaj 64-bitni operacijski sistem Windows potrebujete dodatne "Program Files (x86) mapo"?
Če trenutno uporabljate vsak 64-bitno različico operacijskega sistema Windows ste morda opazili, da sta dva "Program Files" mape, ena za 64-bitne in ena za 32-bitne aplikacije. Zakaj Windows morali, da jih bodo razdelili? Berite naprej za prikaz, zakaj.
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.
So let’s break it down!
Folders are awesome!Let’s agree on something. Folders are great! We don’t need them, we have enough possible file names to put every single file on the root of your hard drive, so why have folders at all?Well, they help us order our stuff. And ordering stuff is great. It helps us to process things more easily. This is especially useful when working with a machine that requires structure.
Separating data and logic is great!A paradigm often found in programming, is to separate data from logic. You want one part thatknows how to do something and you want another part you can do something with.This is also found in the file system.
We have folders for application (logic) and folders for our valuables (data):
Logic
%WINDIR%
%PROGRAMFILES%
%PROGRAMFILES(x86)%
Data
%PROGRAMDATA%
%HOMEDRIVE%%HOMEPATH%
So, it seems like folders are awesome and it makes sense to put programs in their own little folder. But why have 2? Why not let the installer handle that and put everything into one Programsfolder?
Installers aren’t magicToday, we often use small programs to install our larger programs. We call these small programsinstallers.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:
1 Program Files folder
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\.
2 Program Files folders
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.
Consistency makes senseWhen you learn something, that usually implies that an observed behavior was consistent. Otherwise there is really nothing to observe and learn.The same is true for our little file system. It makes sense to always put the same stuff into the same folders. That way, we’ll know where to look when we’re looking for something.
The system for 32/64 application distinction furthers this goal. Applications are separated into 2 locations to avoid conflicts in names, binary loading behavior and security (to some extent).
I still don’t get it. This seems useless
You should never forget one thing. People are incredibly stupid. This includes users, super users and especially programmers.
This is why we need stuff like file system redirection to even make our systems usable.
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!
All these requests by 32bit application are redirected into the 32bit counterparts to avoid application crashes.
We need some fixed folder names to build such a system. If there is no folder structure to support this redirection, then how are you going to make it work?
Okay, now I get it. But why not use C:\Program Files\x86\ then?
Now we’re getting philosophical…
What would go wrong if I somehow avoided the redirection mechanism and forced everything to install to the real C:\Program Files\?
Most likely nothing (as long as other applications don’t depend on a fixed location for that application).
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.
Yeah, but I mean, like, ALL applications!
What would happen if I put both diesel and gas into my car?
What would happen if I try to use both alternating and direct current on the same line?
What would happen if I keep both my cat and my fish in the same aquarium?
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.
Zakaj 64-bitni operacijski sistem Windows potrebujete dodatne "Program Files (x86) mapo"? _________________ www.google.si |
|
Nazaj na vrh |
|
|
|
|
Ne, ne moreš dodajati novih tem v tem forumu Ne, ne moreš odgovarjati na teme v tem forumu Ne, ne moreš urejati svojih prispevkov v tem forumu Ne, ne moreš brisati svojih prispevkov v tem forumu Ne ne moreš glasovati v anketi v tem forumu
|
Powered by phpBB © 2001, 2002 phpBB Group
|