64 bit Windows neden ayrı bir “Program Files (x86)” klasörüne ihtiyaç duyuyor?


178

Windows'un 64 bit sürümünde "Program Files" klasörünün 64 bit programlar için ve "Program Files (x86)" klasörünün 32 bit programlar için olduğunu biliyorum, ancak bu neden gerekli?

"Gerekli" derken, "neden Microsoft başka bir tasarım kararı vermedi?" Demek istemiyorum. Tabii ki alabilirlerdi. Daha doğrusu, "Neden, 64-bit Windows geçerli tasarımı göz önüne alındığında, 32-bit programların 64-bit programlardan ayrı bir üst düzey klasöre sahip olması gerekir?" Başka bir ifadeyle, "Yeniden yönlendirme mekanizmasından nasıl bir şekilde kaçınsaydım ve her şeyi gerçeğe yüklemeye zorlarsam ne olur C:\Program Files\?"

Süper Kullanıcı'da ve başka yerlerde, "biri 32 bit programlar için, biri 64 bit programlar için" olduğunu iddia eden birçok soru var, ancak bulamadığım hiçbiri neden belirtmiyor. Deneyimlerime göre, 32 bitlik bir programın doğru yere kurulup kurulmadığı önemli görünmüyor .

Windows bir şekilde kendini "Program Files (x86)" dışında çalışan bir programdan farklı gösteriyor mu? "Program Files" yerine "Program Files (x86)" içine yüklenen bir program için tam olarak neyin farklı olduğunu gösteren bir açıklama var mı? Bence meşru bir teknik sebep olmadan Microsoft'un yeni bir klasör tanıtması pek mümkün değil.


13
Sorunuza cevap vermek yerine, şunu sorardım - \ program files \ common files nasıl kullanılır?
sgmoore

8
Tek linerli cevap (ve dolayısıyla bir yorum): mimarisini bilmeden herhangi bir klasörden herhangi bir uygulamayı kolayca çalıştırabildiğiniz için, bu ayrımın zorunlu bir nedeni yoktur . Her iki mimariye sahip uygulamaların çift kurulumunu desteklemek bir kolaylık meselesidir . Bazı durumlarda mutlaka basit bir yeniden derleme olmaları nedeniyle fark yaratır. Asıl sorun, 32 bit uygulamaların 64 bit dll'leri yükleyememesidir, bu nedenle genellikle her iki sürümü de aynı yere yükleyemezsiniz. Diğer alternatif, her uygulama için iki "bin" klasörüne sahip olmaktır.
Sklivvz

1
@Synetech (x86) altında yalnızca x64 binary olan programları yükleyen programlar bile vardı. Bazen korkunç.
sinni800

10
Microsoft'un neden "eski" Program Dosyaları dizinini Program Dosyaları'na (x86) taşımak yerine "64-bit programları" Program Dosyaları (x64) "altına koymadığını her zaman merak etmişimdir
LawrenceC

30
/ Windows / System32 / Windows / SysWOW64 32bit şeyler içerir ederken ..., 64bit içeriğe sahip olduğunu 64 / 32bit farklılaşması hakkında gerçek bir karmaşa
dürtmek

Yanıtlar:


92

Kısa cevap: Eski 32 bit uygulamaların, kalıcı bir karışıklık yaratacak 64 bit uygulamalara çirkin kurallar getirmeden eskisi gibi çalışmaya devam etmesini sağlamak için.

Bu gerekli değil. Her uygulamanın 32-bit DLL'leri ve çalıştırılabilir dosyaları 64-bit DLL'lerden ve yürütülebilir dosyalardan ayırmak için kendi yolunu yaratmasını istemek gibi diğer olası çözümlerden daha uygundur.

Bunun ana nedeni, 64-bit sistemler bile bilmeyen yerlerde 64-bit sistemler bile bilmeyen 32-bit uygulamaları "sadece işe yarar" yapmaktır. 32 bitlik bir uygulama 64 bitlik bir DLL dosyasını yükleyemez, bu nedenle 32 bitlik bir uygulamanın (64 bitlik sistemlere önceden gelebilecek ve bu nedenle 64 bitlik dosyaları hakkında hiçbir fikrinin bulunmamasını sağlayacak bir yöntem gerekli) (var bile) 64-bit DLL bulamazlar, yüklemeyi deneyin, başarısız olun ve ardından bir hata mesajı oluşturun.

Bunun için en basit çözüm sürekli ayrı dizinlerdir. Gerçekten de, tek alternatif, her 64 bit uygulamanın, çalıştırılabilir dosyalarını 32 bitlik bir uygulamanın, bin64bu uygulamanın içindeki bir dizin gibi görünmeyeceği bir yere "gizlemesini" gerektirmesidir . Ancak bu, yalnızca eski uygulamaları desteklemek için 64 bit sistemlerde kalıcı çirkinlik getirecektir.


52
Aynı sistemde 32 bit ve 16 bit programlara izin vermek için bu çemberlerin içinden atlamak zorunda kalmamışlardı. Hiç böyle bir şey gördüğümü hatırlamıyorum ProgramFiles (16). Ayrıca, tam olarak nasıl bir 32-bit program "64-bit bir DLL bulup yüklemeyi deneyin"? Hangi programlar rastgele DLL'leri aramaya gider %programfiles%? Paylaşılan bir DLL ise, WinSxS'e gider; paylaşılmıyorsa, o zaman kendi DLL'lerini yönetmek programcıya kalmıştır. Bununla ilgili kısmı, mantıklı programcılar için bir kolaylık olarak yapılması.
Synetech

30
IIRC Win3.1 bir program dosyaları dizinine sahip değildi (ya da çoğu uygulama bunu görmezden geldi); Sonuç olarak, başlangıçta program dosyalarında sayfalar arayan herhangi bir eski win16 uygulaması olmazdı. Bunun yerine IIRC paylaşılan kütüphaneleri çoğu zaman windows klasörünün kendisinde bir yere böldüler. Windows \ system ve windows \ system32'ye sahip olan Win32 bunun bir eseridir.
Dan Neely,

15
Windows 3.1, uzun dosya adlarını desteklemediği için, bir 'program dosyaları' klasörüne sahip olamazdı.
Darth Egregious

14
@ JarrodRoberson: Tam tersi, çünkü Microsoft uyumluluğun son derece yüksek oranda geriye dönük olduğunu düşünüyor.
David Schwartz

24
@Jarrod: Aslında, her geliştiricinin bildiği gibi, Microsoft uyumluluğa çok fazla değer veriyor . Kelimenin tam anlamıyla, sahip oldukları her API, kaldırmayı reddettiği eski yöntemlere ve genellikle düzeltmeyi reddettikleri ciddi hatalara sahiptir; çünkü bu API için yazılmış eski programları kırmaktan korkarlar. Aynı şey, çoğu API için de geçerlidir, ancak Microsoft’un yakınına yakın hiçbir yerde bu değildir.
BlueRaja - Danny Pflughoeft

65

Bir uygulamanın hem 32 bit hem de 64 bit sürümünü kendi üzerine yazmadan yüklemenizi sağlar.


Ertesi gün bu cevaba ve yorum konusuna baktıktan sonra, cevabımda muhtemel büyük bir gözetim olduğunun farkındayım. Yanlışlıkla programlama arkaplanı aldım ve yorumumda sizden bahsettiğimde kullanıcıyı değil programcıyı kastettim.

Microsoft için çalışmıyorum ve bu klasörlerin arkasındaki gerçek mantığın ne olduğu hakkında hiçbir fikrim yok , ancak bu klasörlere sahip olmanın sebebinin o kadar açık olduğunu düşünüyorum ki bunu tartışmakta hiçbir sorunum yok.

Öyleyse parçalayalım!

  1. Klasörler harika!

    Bir konuda anlaşalım. Klasörler harika! Onlara ihtiyacımız yok, her bir dosyayı sabit sürücünüzün kök dizinine koymak için yeterli dosya ismimiz var, neden klasörlerimiz var?

    Eşyalarımızı sipariş etmemize yardımcı oluyorlar. Ve malzeme sipariş etmek harika. İşleri daha kolay işlememize yardımcı oluyor. Bu özellikle yapı gerektiren bir makine ile çalışırken kullanışlıdır.

  2. Veri ve mantığı ayırmak harika!

    Programlamada sıklıkla bulunan bir paradigma, verileri mantıktan ayırmaktır. Tek bir parçasını istiyorum biliyor nasıl bir şeyler yapmak ve size başka bir bölümüne istediğiniz şeyler yapabiliriz ile .

    Bu dosya sisteminde de bulunur.

    Uygulama için klasör (mantık) ve değerli eşyalarımız (veri) için klasörümüz var:

    Mantık

    • %WINDIR%
    • %PROGRAMFILES%
    • %PROGRAMFILES(x86)%

    Veri

    • %PROGRAMDATA%
    • %HOMEDRIVE%%HOMEPATH%

    Yani, klasörler harika görünüyor ve programları kendi küçük klasörlerine koymak mantıklı geliyor. Ama neden 2 tane var? Neden yükleyicinin bunu ele almasına ve her şeyi bir Programsklasöre koymasına izin vermiyorsun ?

  3. Yükleyiciler sihirli değildir

    Bugün, daha büyük programlarımızı yüklemek için sık sık küçük programlar kullanıyoruz. Bu küçük program yükleyicilerini diyoruz .

    Yükleyiciler sihir değil. Programcılar tarafından yazılmalı ve orada başka herhangi bir uygulama gibi (olası böcek ile) uygulamalardır. Öyleyse hayali bir programcının şu anki sistemle ve onsuz ile karşılaşması gereken duruma bakalım :

    1 Program Files klasörü

    Geliştirici 2 yükleyici tutar. Bir tanesi 32 bit için, diğeri ise uygulamasının 64 bit sürümü için. 32bit yükleyici yazacak C:\Program Files\App\ve 64bit yükleyici yazacak C:\Program Files\App\sixtyfour\.

    2 Program Files klasörü

    Geliştirici 1 yükleyici tutar. Yükleyici hep yazacak %PROGRAMFILES%ve (aslında kullanmak istiyorum, bu durumlar için ortam değişkenleri kullanmayın buna göre yolunu genişletmek için işletim sistemine bağlıdır SHGetKnownFolderPath ile FOLDERID_ProgramFilesdoğru yolunu almak için).
    Her şey otomatik olarak yerini bulur ve desen yüklediğiniz her uygulama ile aynıdır .

  4. Tutarlılık mantıklı

    Bir şey öğrendiğinizde , bu genellikle gözlenen bir davranışın tutarlı olduğu anlamına gelir. Aksi halde, gözlemlemek ve öğrenmek için hiçbir şey yoktur.

    Aynısı küçük dosya sistemimiz için de geçerlidir. Her zaman aynı şeyleri aynı klasörlere koymak mantıklıdır . Bu şekilde, bir şey ararken nereye bakacağımızı bileceğiz.

    32/64 uygulama ayrımı için sistem bu amaca yöneliktir. Uygulamalar, adlarda çakışmalardan, ikili yükleme davranışından ve güvenlikten (bir ölçüde) kaçınmak için 2 konuma ayrılmıştır.

Hala anlamadım. Bu işe yaramaz görünüyor

Bir şeyi asla unutmamalısın. İnsanlar inanılmaz derecede aptal. Bu, kullanıcıları, süper kullanıcıları ve özellikle programcıları içerir.

Bu nedenle , sistemlerimizi kullanılabilir hale getirmek için bile dosya sistemi yeniden yönlendirmesi gibi şeylere ihtiyacımız var .

Programcılar oraya girecek ve yüklenmeye çalışacak C:\Windows\system32\awesome.dllve 32 veya 64 bit sistemde çalışıp çalışmadıklarını umursamayacaklar. 64bit DLL dosyasını yüklemeye çalışırlar ve basitçe çökmesine neden olurlar. Bazı programcılar Office DLL kullanmak isterler, sorun değil, nerede bulacaklarını biliyorlar! C:\Program Files\Microsoft\Office\14.0\wizards.dll... ve başka bir kaza!

32bit uygulama tarafından yapılan tüm bu talepler, uygulama çökmelerini önlemek için 32bit meslektaşlarına yönlendirilir .

Böyle bir sistemi inşa etmek için bazı sabit klasör isimlerine ihtiyacımız var. Bu yönlendirmeyi destekleyen klasör yapısı yoksa, nasıl çalışmasını sağlayabilirsiniz?

Tamam, şimdi anladım. Ama neden o zaman kullanmıyorsun C:\Program Files\x86\?

Şimdi felsefi oluyoruz ...

Yeniden yönlendirme mekanizmasından bir şekilde kaçınıp her şeyi gerçeğe yüklemeye zorlarsam ne yanlış gider C:\Program Files\?

Büyük olasılıkla hiçbir şey (diğer uygulamalar bu uygulama için sabit bir yere bağlı olmadıkça).

WOW64'ni içine mekanizma kanca CreateProcesso 32 veya 64 bit ise çalıştırılabilir görüntü üzerinde (yürütülebilir klasör adını denetimi daha sofistike) ve daha sofistike gerçekleştirecek çekler belirlemek için.

Evet, ama TÜM uygulamalar demek istiyorum!

  • Arabama hem dizel hem de gaz koyarsam ne olur ?
  • Aynı hatta hem alternatif hem de doğru akımı kullanmaya çalışırsam ne olur ?
  • Ben tutmak ne olur hem aynı akvaryumda kedimi ve benim balık?

Bazı sorular cevap gerektirmez. Yapılması amaçlanmadı, yapma. Burada kazanılacak bir şey yok. Böyle bir değişikliğin neden olabileceği sorunların miktarı, birisinin bu konuda görebileceği olası yararlardan her zaman ağır basacaktır.


3
Yine de asıl sebep bu mu? Uygulamayı C:\Program Files\App32ve 'ye kuramaz C:\Program Files\App64mıyım?
Stephen Jennings

4
@StephenJennings: Ancak bu kararı elle vermenizi gerektirir. Şimdi çalışma şekli işlemin otomatik olması, çünkü bir uygulama SHGetSpecialFolderPathyükleme konumunu belirlemek için Windows aradığında hangi klasörü sağlayacağını biliyor .
Der Hochstapler

6
@ Synetech: Neden %PROGRAMFILES%ilk etapta kurmak ? Neden 32bit sürümünü kullanıcı masaüstüne ve 64 bit'i Geri Dönüşüm Kutusu'na koymuyorsunuz? Sadece yapılabileceği için, bunun iyi bir fikir olduğu anlamına gelmez. Üzgünüm, nedenini takip etmiyorum.
Der Hochstapler

4
@Synetech: Evet, nasıl yapılabileceğine dair mükemmel bir örnek verdiniz. Nasıl yapılabileceğine dair mükemmel bir diğer örnek, şu an gerçekten yapıldığı yöntemdir . Sadece% PROGRAMFILES% 'e bir dosya yazmak ve doğru klasöre ulaşacağından emin olmak bir şeydir. Kendiniz için hangi klasörün hangisinin doğru olduğunu kontrol etmek başka bir şeydir. Eski yaklaşımın faydasını göremiyorsanız, sizi ikna edemem. Soru, neden 2 klasörün olduğu idi. Bence cevabım bu açıdan gayet makul.
Der Hochstapler

3
@OliverSalzburg, Hayır oldukça. İki klasör neden sorudur gerekli olmadığı, neden vardır . Aslında onu bile kızdırdı: bu neden gerekli? Neden gerekli olduğunu açıklamamışsınız ve verdiğim örnek (ve hatta kendi alaycı örneğiniz bile) , olduğu gibi yapılması gerekmediğini gösteriyor .
Synetech

14

TL; DR:

Özetlemek gerekirse, hayır gerekli değildir ; onlar olabilir tek bir klasör kullanmış ve hayır, Windows, bir yerden veya başka çalıştırılıyor bir programa farklı kendini belli etmez.


Eh, herkes bu konudaki düşüncelerini atıyor gibi görünüyor, bu yüzden 2 my 'ime atıyorum. Diğerleri zaten üzere sebeplere zannettiği neden Microsoft programlarının 32-bit ve 64-bit sürümleri için ayrı üst düzey klasör oluşturmak için seçti, bu yüzden o kısmı bırakacağım (iyi neden o kadar olduğunu David'in açıklama oldu programcılara kolaylık). Tabii ki o zaman bile, bu neden gerekli olsa bile doğrudan soruyu tam olarak ele almıyor. , hangi cevap olduğu tahmin edilmektedir: öyle değil .

Bunun yerine, sorunun ana gövdesine değineceğim

Windows bir şekilde kendini "Program Files (x86)" dışında çalışan bir programdan farklı gösteriyor mu?

Pek değil, ama programın yeri olabilir davranışını etkilemez, ama düşündüğün olur bir şekilde.

Bir programı çalıştırdığınızda, Windows çalıştırılacağı bir ortam oluşturur (yalnızca ortam değişkenlerini değil, bellek, adresleme vb. Anlamında). Bu ortam yürütülebilir dosyanın içeriğine bağlıdır (32 bit ve 64 bit programlar dahili olarak farklılık gösterir). 64 bit sistemde 32 bit program çalıştırdığınızda, 32 bit ortam taklit eden 32 bit alt sistemde çalışır. Bu denir WoW64 (WoW64 açılımı Windows'un 64 bit Windows ) ve 16 bit uygulamalar kullanarak XP çalışacağı bu şekline benzer NTVDM .

İle veya yönetici ayrıcalıkları olmayan bir program çalıştırdığınızda, bu nasıl çalıştırdığını etkiler, ancak konum olmalıdır (örneğin bazı sürücüler gibi konum bağımlılık bazı örnekler olmasına rağmen) bunu etkilemez.

(Ben farklı bir bilgisayar kullanıyorum, bu yüzden benim tarayıcı geçmişine güvenemez adımlarımı sarfınazar, ancak diğer gün cevaplarken bu SU soruyu ben de bitti bu SO soru bana neden Google PROCESSOR_ARCHITEW6432 yol bu SO soru ve bu Microsoft blog yazısı .)

Yol boyunca bir yerlerde, envirnoment değişkeninin %processor_architecutre% komut istemini nereden çalıştırdığınıza bağlı olarak farklı sonuçlar verdiği hakkında bir StackOverflow gönderisini okudum (tam alıntıyı bulmaya çalışacağım).

Yanıt, komut isteminin 32 bit veya 64 bit sürümünün çalıştırılmasından kaynaklanıyordu (yani, System32\veya SysWoW64\). Başka bir deyişle, konum programın davranışını etkiliyor gibi görünse de , bunun nedeni yalnızca programın farklı sürümleri olduğudur, çünkü Windows klasörü özel bir şekilde ele alır.

Yürütülebilir dosyanın içeriğini 32-bit veya 64-bit olup olmadığını dikte, bu mantıklıdır, bu yüzden 32 bit ve 64 bit aynı programın kopyasını (örneğin hem koyabilirsiniz foobar32.exeve foobar64.exesizi aynı klasörde) ve Bunları uygulayın, doğru yüklenecekler (64-bit sürüm doğal olarak çalıştırılacak ve 32-bit sürüm WoW64 öykünme katmanında çalıştırılacak).

FreePascal DOS ve Windows iki sürümünü yüklemek için izin verir ve aynı klasörde gidin: %programfiles%\FreePascal. O (çalıştırılabilir dosyaları tutarak farklı mimarileri yönetir .exe, .sys, .dll, .ovrvb kaynak dosyaları,) bu da 32 ve için yapılması olamayacağını hiçbir teknik neden yoktur ayrı klasörlerde, vs.) ve resimler gibi kaynak dosya paylaşımı Bir programın 64 bit sürümleri. David'in dediği gibi, programcı için ayrı tutulursa daha kolaydır (örneğin, yalnızca bir dosya grubu gibi görünmesini sağlamak için değişkenler kullanmak vb.)


Aşağı intikam oylama! Muahahaha! sigh
Synetech

Aşağı oy garip: \. Btw iyi açıklamak +1.
avirk

11

Başka bir neden, programların çoğunun, programlarının yüklendiği yeri işaret etmek için% PROGRAMFILES% gibi çevresel değişkenleri kullanmasıdır. 64 bit programlar için normal yere gider. 32 bit programlar için bunu yeni Program Files (x86)klasöre yönlendirecektir .

Her ne kadar, en azından Visual Studio'daki yeni .Net ile birlikte, şimdi bunun için gerekli olan tüm gereksinimi ortadan kaldıran App.Local değişkenine sahipler.


4
Bu açıklamıyor. Ortam değişkenini tam olarak kim kullanıyor ve neden bir programın 32 bit mi yoksa 64 bit mi olmasını umursuyor?
Synetech

4
@Synetech - Programların yazarı ortam değişkenini kullanır. Bunun umursayacağı şey, borçlara yapılan atıflardan kaynaklanıyor. 64 bitlik bir işlem içinde 32 bitlik bir dll yükleyemezsiniz ve bunun tersi de geçerlidir.
Ramhound

1
Ve nasıl %programfiles%, %programfiles(x86)%ya %programw6432%orada bir fark? Paylaşılan DLL'ler, WinSxS dizininin tamamına gider ve paylaşılmayan tüm DLL dosyaları çalıştırılabilir dosyada bulunur. Bu sadece bir sebepten dolayı aynı programın hem 32-bit hem de 64-bit sürümlerinin yüklü olması ve bunun ardından 32-bit DLL'lerin 32-bit çalıştırılabilir ve 64-bit DLL ile tutulması önemli olacaktır. 64 bit çalıştırılabilir. Bunu şöyle yapabilirsiniz: %programfiles%\CoolApp\bin\32ve% programfiles% \ CoolApp \ bin \ 64`, neden üst düzey klasörler ayrı?
Synetech

@ Synetech Tabii ki; % programfiles% yaklaşık bir süredir. 64 bitlik bir bilgisayara 32 bitlik bir program yüklerseniz, bir yere sahip olmak bu 32 bitlik uygulama için sorunlara neden olur. WoW yine de% programfile% 'i 32 bit uygulamalar için (x86) versiyonuna ve 64 için x86 olmayan versiyona yönlendirebilir.
Andy

Bence insanlar bu kadar karışık olmazlardı, dolaylı bir yönlendirme
olmasaydı

8

Microsoft'un 32-bit'den 64-bit'e bu geçişe olan çözümü çoğu 32-bit uygulama için eski destek eklemek olmuştur. Başka bir deyişle, çoğu 32 bit uygulama 64 bit işletim ortamında çalışacaktır. 64 bit mimaride çalışan diğer işletim sistemlerinin 32 bit uygulamaları hiçbir zaman yükleyemeyeceğini veya çalıştıramayacağını unutmayın.

Geçişi kolaylaştırmak için Microsoft, tüm 32 bit uygulamanın, normal Program Dosyaları klasöründeki gerçek 64 bit uygulamalarla karıştırılmak yerine varsayılan olarak Program Dosyaları (x86) klasörüne yüklenmesi gerektiğini belirlemiştir.

Kaynak

"Yeniden yönlendirme mekanizmasından bir şekilde kaçınsaydım ve her şeyi gerçek C: \ Program Files \ 'a yüklemeye zorladıysam ne yanlış gidecekti?"

Hiçbir şey değil. İki program dizini yalnızca kuruluşlar içindir ya da Internet Explorer gibi iki sürümü 32 bit ve 64 bit sürümü olan programları ayrı tutmak içindir. Ancak "Program Files" a bir 32 bit program ve "Program Files x86" da 64 bit bir program yükleyebilirsiniz ve hiçbir şey olmayacak, program aynı şekilde çalışacaktır.

Wiki diyor ki:

Bazı uygulama yükleyicileri, yükleme yolu konumundaki boşlukları reddeder. 32 bit sistemler için, Program Files klasörünün kısa adı Progra ~ 1'dir . 64 bit sistemler için, 64 bit Program Files klasörünün kısa adı Progra ~ 1'dir (32 bit sistemlerde olduğu gibi); 32 bit Program Files (x86) klasörünün kısa adı şimdi Progra ~ 2 iken .


1
Hehe. Güzel makale. Bu yazıya yapılan yorumlar tam olarak buradakine benziyor. Daha da kötüsü, bu makale iki yıldan uzun bir zaman önceydi, ki bu sorunun yeni olmadığını ve hâlâ otoriter olarak cevaplanamıyorsa, o zaman sanırım hiçbir zaman cevap vermeyeceğini (Windows ekibinden birileri çalmadığı sürece) sanırım. Oh, sanırım hepimiz endişelenmeyi bırakmalıyız ve bombayı sevmeyi öğrenmeliyiz, yani onunla yaşamayı. +1 Makaleye dikkat çekmek ve bu sorunun çok uzun zamandır bulunduğunu göstermek için.
Synetech

1
@ Synetech teşekkürler! Evet, makale bağlantısını koymanın ardındaki fikir seninkiyle aynı. Bu çok eski bir soru ama IDK neden insanların henüz bulamadıklarını soruyor. Bununla birlikte, MS bu problem için bir KB veya Belge
yazmalıdır

Evet, özellikle normal kullanıcılar bile merak eden sadece geliştiriciler olmadığı için merak etmelidirler. Ne yazık ki Microsoft'un belgeleri genellikle çok iyi değildir.
Synetech

@ Synetech yup! MS belgeleri çoğu zaman berbattır. Ama evet, onlar da iyi makaleler yazdılar ve sayılabilir olduklarından eminim;)
avirk

6

Bunun nedeni, geliştiriciler için bir programı 64 bit'e yükseltmeyi kolaylaştırmaktır. 32-bit modunda derlerken programı bir dizinde, 64-bit modunda derlerken başka bir dizinde kontrol etmek için herhangi bir özel kod yazmaları gerekmez; onlar sadece kontrol eder C:\Program Filesve 32 bit modunda çalışırken, bu otomatik olarak C:\Program Files (x86)64 bit Windows tarafından değiştirilir . Benzer şekilde, kayıt defteri girdileri, 32 bit ve 64 bit programlar arasında izole edilir.

Bu, derleme modunu yalnızca fazla düşünmeden 64-bit olarak değiştiren bilinmeyen geliştiricilerin çatışmasını önler ve kullanıcıların hem 32- hem de 64-bit sürümlerini kurmasını isteyen geliştiriciler için çok fazla çalışma yapılmasını önler yazılımı aynı anda.


Fakat neden herhangi bir program her iki versiyonun aynı anda kurulmasına izin vermek istesin ki? Bir örnek: Photoshop ve IE, yerel .dll dosyalarına sahip uzantılara sahiptir. Aynı işlemde karışık 32 ve 64 bit kodunuz olamaz, bu nedenle 32 bit sürüm için bir eklenti 64 bit sürümle kullanılamaz ve bunun tersi de geçerlidir. Bu nedenle, Photoshop / IE'nin her iki sürümün de yüklenmesine izin vermek veya varolan eklentilerin devasa tabanını kırma riski vardır.


2
+1 En azından ortalama kullanıcıların neden her iki sürüme de sahip olacağının altında yatan soruyu yanıtladınız.
Synetech

5

"Program Files (x86)" üzerinde çalışan programlar, WOW64 alt sistemini kullanır (Windows 64- bit'te Windows 32-bit, x32 uygulamalarını x64 mimarisi sistemi üzerinde çalıştırmayı amaçlayan bir dizi sürücü ve API'dir):

WoW64 alt sistemi, Windows'un tüm 64 bit sürümlerinde benzer arayüzlere sahip hafif bir uyumluluk katmanı içerir. 64 bit sistemde değiştirilmemiş 32 bit Windows uygulamalarını çalıştırmak için gereken arabirimleri sağlayan 32 bit ortam oluşturmayı amaçlamaktadır. Teknik olarak, WoW64 üç dinamik bağlantı kitaplığı (DLL) kullanılarak uygulanır:

  • Wow64.dll, işaretçi ve çağrı yığını manipülasyonları dahil, 32-bit ve 64-bit çağrıları arasında çeviri yapan Windows NT çekirdeğinin çekirdek arayüzü
  • 32 bit uygulamalar için uygun giriş noktalarını sağlayan Wow64win.dll
  • İşlemciyi 32-bit'den 64-bit moduna geçirme Wow64cpu.dll

64 bit sistemin 32 bit uygulamaları "taklit etmesi" gerekir, bu nedenle Windows'un iki Program Dosyası klasörünü "ayırması" gerekir.


7
Ama neden farklı klasörlere koymak zorunda? Windows zaten PE başlığına bakarak bir yürütülebilir dosyanın yapısını tam olarak belirleyebiliyor. Yürütülebilir dosyayı yüklediğinde neden uygun ortamı yükleyemiyor?
Synetech

1
Bir program açarken Microsoft'a iki program sürümünden hangi mimariyi istediklerini kullanıcılara kolayca göstermenin sadece bir seçenek olduğunu düşünüyorum. Yani, bu iki klasör olmasaydı ve kullanıcılar için şeffaf olsaydı (otomatik olarak değişirse), 32 veya 64 bit bir uygulama çalıştırıp çalıştırmayacağını bile bilmiyorlardı, hatta hangi programı açacaklarını bile bilmiyorlardı. 64 bit üzerinde çalışıyorsa ..
Diogo

1
IE'nin 64-bit sürümü korkunç olduğu için bir üne sahiptir.
Samuel Edwin Ward

1
MS, bellek kısıtlamalarını aşacak kadar büyük veri kümeleriyle çalışmadığınız sürece office32 kullanılmasını önerir. Office64 ile çalışmak için ikili eklentileri yeniden derleme gerekliliğine inanıyorum; Normal kullanım durumlarında herhangi bir yarar sağlamayacak şekilde kombine kararın arkasında.
Dan Neely,

1
Açıkça Program Dosyaları (x86) klasörüne kurulmuş bir 64 bit programın mükemmel şekilde çalışacağını düşünüyorum (ve bunun tersi). Windows, yürütülebilir dosyanın nasıl işleneceğini belirlemek için klasör konumunu kullanmaz.
Harry Johnston,

5

Buradaki ve İnternet'teki cevapların biraz değişmesi ilginçtir. Bu önemli soruya doğru bir cevap bulmak zor oldu. İnternette sunulan yanlış bilgilerin bir kısmı karışıklığa yol açıyor gibi görünmektedir.

Önemli miktarda araştırma yaptım ve doğru olduğuna inandığım aşağıdaki sonucu çıkardım:

  • Bir uygulamanın nerede saklandığı farketmez. Çalışma zamanında, Windows uygulamanın 32 bit mi yoksa 64 bit mi olduğunu belirler ve otomatik olarak uygun DLL ve kayıt defteri bölümünü kullanır.

Bu otomatik olarak gerçekleşir ve uygulamanın depolandığı yerden bağımsızdır. Ayrı 32 bit ve 64 bit klasörlere sahip olmanın hızı, güvenilirliği veya başka bir işlevsel yararı yoktur.

İki klasöre varsayılan ayırmanın tek nedeni ('Program Dosyaları' ve 'Program Dosyaları (x86)'), aynı programın iki sürümüne (32 bit ve 64 bit sürüm) sahip olmanız durumunda örtüşen dosyaları ayrı tutmanın basit bir yolu. Bu durumda bile, tüm dosya adları benzersiz olduğu sürece, sonuçta aynı klasörde var olabilirler.

Yukarıdaki sonuca bir uyarı vardır ve bu kötü kodlanmış uygulamalardan biridir. Bir uygulamanın içine kodlanmış herhangi bir yolu varsa, yalnızca bu yolu kullanır. Kural olarak, yollar asla bir uygulamaya kodlanmamalıdır, ancak bazen bir programcı bu hatayı yapar. Bu durumda, program kodlanmış yolu kullanacaktır; Uygulamanın yüklendiği dizin, dosyaları aradığı yeri etkilemez.


3

Klasörleri ayırmak, yerel 64 bit uygulamaları ve WoW64'ü gerektiren bilgisayarları ayrı tutmayı mümkün kılar .

Bu yararlı olabilir - @OliverSalzburg'un daha önce belirttiği gibi - bir web tarayıcısının hem 64 bit hem de 32 bit'ini (örneğin) yüklemek istiyorsanız, çünkü bazı eklentiler ve eklentiler yalnızca bir tanesi için kullanılabilir. iki.

Klasörleri ayırmak , kayıt defteri yeniden yönlendirmesi gibi teknikleri kullanarak bu ayırmayı otomatik yapar .

Bir yükleyicinin, örneğin RegQueryValueEx kullanarak kayıt defterini okuyarak program dosyaları klasörünü belirlemeye çalıştığını varsayalım .

Her durumda, kayıt defteri anahtarını okumaya çalışır.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion

hangi normalde işaret eder C:\Program Files.

Ancak, yükleyici 32 bit uygulama ise, kayıt defteri yeniden yönlendirmesi kayıt defteri anahtarına neden olur

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion

bunun yerine, normalde işaret eder C:\Program Files (x86).

Bu özel klasör adlarının neden kullanıldığına yalnızca bu seçimi yapan kişiler tarafından cevap verilebilir. İsterseniz varsayılan klasörlerin adlarını her zaman değiştirebilirsiniz.

Windows bir şekilde kendini "Program Files (x86)" dışında çalışan bir programdan farklı gösteriyor mu?

Şüpheliyim. Çoğu yükleyici, özel bir yükleme klasörü seçmenize izin verir; bu nedenle, bir programın nereye yüklendiği önemli değildir .


Üzgünüm "yasak" ile "izin" i karıştırdım
Wernfried Domscheit

3

Buradaki karışıklığa inanamıyorum .. öncelikle tam zamanlı bir geliştiriciyim.

MS, bir DLL dosyasının hem eski 32 bit uygulamalar hem de 64 bit uygulamalar tarafından kullanıldığı durumu çözmek için bunu yaptı. Eski yöntem değiştirilemedi (System32, Program Files vb.) Çünkü bu, yeniden derlenemeyen eski programları kırar.

Böylece MS 64-bit belirli programları, derlemeleri ve kütüphaneleri depolamak için bir klasör yarattı, böylece yeni programlar uygun kütüphanelere bağlanabildi ve eski programlar normal olarak çalışmaya devam etti.

Bu haliyle, .NET DLL'leri aynı makinedeki diğer sürümlerle bir arada bulunabilir. Örneğin, Library.1.0.1, Library.1.0.2, Library 1.1.0, vs.'ye sahip olabilirsiniz. Bu sadece belirli bir bit boyutu içindir (32 veya 64). Ayrı klasörler kullanılmıyorsa, her derlemenin 32 ve 64 bit sürümüne sahip olması gerekir. Bu, zaten aynı derlemenin birden çok sürümünü içeren bir dizini ciddi şekilde karıştırır.

Bunların hepsi geliştirici şeyler. Bir kullanıcı olarak sadece Windows 7 64'te 32-bit bir programla çalışırken başa çıkmam gerekiyor. Ve 32-bit bir sürümü ve aynı uygulamayı 64-bit olarak çalıştırmayı tercih ediyorum. 64-bit'te derlemem gereken 32-bit bir uygulama üzerinde çalışırken tek yaptığım derleyiciye bunu söylemektir. Dll isimleri ve her şey aynı kalır.

Bunun Windows 95 / 98'de bulunmamasının nedeni, sistemlerin 32 bit çalışma zamanı simüle ettiği; Orijinal bir 32 bit işletim sistemi değildi. "Thunking" adında bir şeyle 32 bitlik uygulamada numara yaptı.

İşte iyi bir tanım: http://searchwinit.techtarget.com/definition/thunk


1
Nasıl ProgramFiles(x86)` avoid clutter? There are still both 32- and 64-bit versions of files, so avoiding clutter doesn't make sense. There is no difference between putting them in \ 32 \ blah` veya \blah\32; iki şekilde de ayrılırlar. Herhangi bir şey varsa, mevcut yol uygulamanın bileşenlerini ayırır (ve aynı zamanda birkaç uygulama CommonFileskaynaklar için kullandığı için bunları gereksiz yere çoğaltır . Ayrıca, uygulamaları DLL'lerini ortak bir kovaya atıyormuş gibi görünmesini sağlarsınız. Bir uygulamanın saklanması yeterince kolaydır. - 32-bit exes ile 32-bit dll ve 64-bit exes ile 64-bit dll
Synetech

Oh, ve 95/98 gelince, kim bu konuda bir şey söyledi? XP bile 16 bitlik bir alt sisteme (NTVDM) sahipti.
Synetech

Bir açıklama istediğini düşünmüştüm. Çok az uygulama CommonFiles kullanıyor mu? Burada girişleri olan 35 farklı uygulamam var. Paylaşılan bileşenleri saklamak için System32 dizininden daha güvenli bir yer. Bunu birkaç uygulamanın kullandığı ifadesi tartışmalıdır. Sizden alıntı: “Aynı sistemde 32-bit ve 16-bit programlara izin vermek için bu çemberlerin içinden atlamak zorunda kalmamışlardı. Bununla ilgili kısmı, mantıklı programcılar için bir kolaylık olarak yapılması. ” Evet, programcılar yapar. Ne de olsa uygulamaları yazıyoruz.
Jason Locke

Ha?
Synetech

Sadece bunu tekrar okuyun .. cevaplarında daha iyi olduğunu söyledi - superuser.com/a/442253/142951 . Bir geliştirici değilseniz, amacı göremeyebilirsiniz.
Jason Locke,

0

Hiç gerekli değil. Örneğin çalışan bilgisayarımda, her bir uygulamayı C:\MyPrograms\kendi IT departmanımız tarafından kurulan uygulamalardan ayırmalarını sağlamak için klasöre yüklüyorum.

Elbette bu, bir uygulamanın her iki versiyonunu da (32 ve 64 bit) kurmamı engelliyor, ancak bu benim durumumda sorun değil.

Ne zaman bir program başlatmak, her zaman ilk DLL C:\Windows\System32\ntdll.dllyürütülür. Bu DLL, programınızın 32 bit veya 64 bit bir uygulama olup olmadığını belirler. Buna bağlı olarak, WoW64zaten birkaç cevapta kime yönlendirildiğinize yönlendirilirsiniz .

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.