Mengapa Windows 64-bit membutuhkan folder "Program Files (x86)" yang terpisah?


178

Saya tahu bahwa pada Windows versi 64-bit folder "Program Files" adalah untuk program 64-bit dan folder "Program Files (x86)" adalah untuk program 32-bit, tetapi mengapa ini bahkan perlu?

Dengan "perlu", maksud saya bukan "mengapa Microsoft tidak dapat membuat keputusan desain lain?" karena tentu saja mereka bisa. Sebaliknya, maksud saya, "mengapa, mengingat desain Windows 64-bit saat ini, program 32-bit harus memiliki folder tingkat atas yang terpisah dari program 64-bit?" Dengan kata lain, "apa yang salah jika saya entah bagaimana menghindari mekanisme pengalihan dan memaksa semuanya untuk menginstal ke nyata C:\Program Files\?"

Ada banyak pertanyaan tentang Pengguna Super dan di tempat lain yang menyatakan "satu untuk program 32-bit, satu untuk program 64-bit", tetapi tidak ada yang dapat saya berikan alasannya. Dari pengalaman saya, itu tidak tampak untuk peduli apakah program 32-bit dipasang di tempat yang benar atau tidak.

Apakah Windows entah bagaimana menampilkan dirinya secara berbeda ke program yang kehabisan "Program Files (x86)"? Apakah ada deskripsi yang menunjukkan dengan tepat apa yang berbeda untuk program yang diinstal di "Program Files (x86)" dan bukan "Program Files"? Saya pikir itu tidak mungkin bahwa Microsoft akan memperkenalkan folder baru tanpa alasan teknis yang sah.


13
Daripada menjawab pertanyaan Anda, saya akan bertanya - bagaimana Anda menangani \ program file \ file umum?
sgmoore

8
Jawaban satu baris (dan karenanya komentar): karena Anda dapat dengan mudah menjalankan aplikasi apa pun dari folder apa pun tanpa mengetahui arsitekturnya, maka jelas tidak ada alasan wajib untuk pemisahan ini. Ini adalah masalah kenyamanan untuk mendukung pemasangan ganda aplikasi dengan kedua arsitektur . Dalam beberapa kasus itu membuat perbedaan karena mereka tidak selalu mengkompilasi ulang sederhana. Masalah utama adalah aplikasi 32 bit tidak dapat memuat 64 bit dll, jadi Anda biasanya tidak dapat menginstal kedua versi di tempat yang sama. Alternatif lain adalah memiliki dua folder "bin" untuk setiap aplikasi.
Sklivvz

1
@Synetech Saya bahkan punya program instalasi di bawah (x86) hanya untuk memiliki x64 binari .. Terkadang itu mengerikan.
sinni800

10
Saya selalu bertanya-tanya mengapa Microsoft tidak memasukkan program 64-bit dalam "Program Files (x64)" alih-alih * memindahkan "direktori" Program Files Files ke Program Files (x86)
LawrenceC

30
Kekacauan nyata tentang diferensiasi 64 / 32bit adalah bahwa / Windows / System32 mengandung konten 64bit, sementara / Windows / SysWOW64 berisi hal-hal 32bit ...
menyodok

Jawaban:


92

Jawaban singkat: Untuk memastikan aplikasi 32-bit lama terus bekerja dengan cara yang sama seperti sebelumnya tanpa memaksakan aturan jelek pada aplikasi 64-bit yang akan membuat kekacauan permanen.

Itu tidak perlu. Itu hanya lebih nyaman daripada solusi lain yang mungkin seperti mengharuskan setiap aplikasi untuk membuat caranya sendiri untuk memisahkan DLL 32-bit dan executable dari DLL 64-bit dan executable.

Alasan utama adalah untuk membuat aplikasi 32-bit yang bahkan tidak tahu bahwa sistem 64-bit "hanya berfungsi", bahkan jika 64-bit DLL diinstal di tempat-tempat aplikasi mungkin terlihat. Aplikasi 32-bit tidak akan dapat memuat DLL 64-bit, sehingga diperlukan metode untuk memastikan bahwa aplikasi 32-bit (yang mungkin pra-tanggal sistem 64-bit dan dengan demikian tidak tahu file 64-bit bahkan ada) tidak akan menemukan DLL 64-bit, cobalah memuatnya, gagal, dan kemudian menghasilkan pesan kesalahan.

Solusi paling sederhana untuk ini adalah direktori yang terpisah secara konsisten. Sungguh satu-satunya alternatif adalah meminta setiap aplikasi 64-bit untuk "menyembunyikan" file yang dapat dieksekusi di suatu tempat aplikasi 32-bit tidak akan terlihat, seperti bin64direktori di dalam aplikasi itu. Tapi itu akan memaksakan keburukan permanen pada sistem 64-bit hanya untuk mendukung aplikasi warisan.


52
Mereka tidak harus melewati rintangan ini untuk memungkinkan program 32-bit dan 16-bit pada sistem yang sama. Saya tidak ingat pernah melihat ProgramFiles (16)atau semacamnya. Selain itu, bagaimana tepatnya program 32-bit "menemukan DLL 64-bit dan mencoba memuatnya"? Program apa yang digunakan untuk mencari DLL acak %programfiles%? Jika itu adalah DLL bersama, maka itu berjalan di WinSxS; jika tidak dibagikan, maka tergantung pada pemrogram untuk mengelola DLL mereka sendiri. Bagian tentang hal itu dilakukan sebagai kenyamanan bagi programmer yang masuk akal.
Synetech

30
IIRC Win3.1 tidak memiliki direktori file program (atau sebagian besar aplikasi mengabaikannya); sebagai hasilnya tidak akan ada aplikasi win16 warisan yang mencari hal-hal dalam file program untuk memulai. Sebaliknya perpustakaan IIRC bersama sering plonked di suatu tempat di folder windows itu sendiri. Win32 memiliki windows \ system dan windows \ system32 adalah artefak dari itu.
Dan Neely

15
Windows 3.1 tidak mendukung nama file yang panjang, sehingga tidak akan bisa memiliki folder 'file program'.
Darth Egregious

14
@JarrodRoberson: Justru sebaliknya, itu karena Microsoft menghargai kompatibilitas yang sangat tinggi.
David Schwartz

24
@Jarrod: Sebenarnya, seperti yang diketahui setiap pengembang, Microsoft menghargai kompatibilitas terlalu tinggi. Secara harfiah setiap API yang mereka miliki memiliki metode lama yang tidak ingin mereka hapus, dan seringkali bug serius yang mereka tolak untuk diperbaiki, karena mereka takut merusak program lama yang ditulis untuk API itu. Hal yang sama berlaku untuk sebagian besar API, tetapi tidak untuk mendekati Microsoft.
BlueRaja - Danny Pflughoeft

65

Ini memungkinkan Anda untuk menginstal versi aplikasi 32bit dan 64bit tanpa itu menimpa sendiri.


Setelah melihat utas jawaban dan komentar ini pada hari berikutnya, saya menyadari kemungkinan kekeliruan besar dalam jawaban saya. Saya salah mengambil latar belakang pemrograman dan ketika saya berbicara tentang Anda di komentar saya, saya tidak bermaksud pengguna, tetapi programmer.

Saya tidak bekerja untuk Microsoft dan saya tidak tahu apa alasan sebenarnya di balik folder-folder ini, tetapi saya pikir alasan untuk memiliki folder-folder ini sangat jelas sehingga saya tidak punya masalah untuk memperdebatkannya.

Jadi mari kita jabarkan!

  1. Folder itu luar biasa!

    Mari kita sepakati sesuatu. Folder itu bagus! Kami tidak membutuhkannya, kami memiliki cukup banyak nama file untuk meletakkan setiap file di root hard drive Anda, jadi mengapa ada folder sama sekali?

    Ya, mereka membantu kami memesan barang-barang kami. Dan memesan barang sangat bagus. Ini membantu kita untuk memproses berbagai hal dengan lebih mudah. Ini sangat berguna ketika bekerja dengan mesin yang membutuhkan struktur.

  2. Memisahkan data dan logika itu hebat!

    Paradigma yang sering ditemukan dalam pemrograman, adalah memisahkan data dari logika. Anda ingin satu bagian yang tahu bagaimana melakukan sesuatu dan Anda ingin bagian lain Anda bisa melakukan sesuatu dengan .

    Ini juga ditemukan di sistem file.

    Kami memiliki folder untuk aplikasi (logika) dan folder untuk barang-barang berharga kami (data):

    Logika

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

    Data

    • %PROGRAMDATA%
    • %HOMEDRIVE%%HOMEPATH%

    Jadi, sepertinya folder itu mengagumkan dan masuk akal untuk meletakkan program di folder kecil mereka sendiri. Tapi mengapa harus 2? Mengapa tidak membiarkan pemasang yang menangani itu dan memasukkan semuanya ke dalam satu Programsfolder?

  3. Pemasang bukanlah keajaiban

    Saat ini, kami sering menggunakan program kecil untuk menginstal program kami yang lebih besar. Kami menyebutnya penginstal program kecil ini .

    Pemasang bukanlah keajaiban. Mereka harus ditulis oleh programmer dan merupakan aplikasi (dengan kemungkinan bug) seperti aplikasi lain di luar sana. Jadi mari kita lihat situasi yang harus dihadapi oleh programmer imajiner dengan dan tanpa sistem saat ini:

    1 folder File Program

    Pengembang memiliki 2 installer. Satu untuk 32bit dan satu untuk versi 64bit aplikasinya. Pemasang 32bit akan menulis C:\Program Files\App\dan installer 64bit akan menulis C:\Program Files\App\sixtyfour\.

    2 folder File Program

    Pengembang memelihara 1 pemasang. Pemasang akan selalu menulis %PROGRAMFILES%dan bergantung pada sistem operasi untuk memperluas jalur yang sesuai (Anda sebenarnya tidak menggunakan variabel lingkungan untuk kasus ini, Anda akan menggunakan SHGetKnownFolderPath dengan FOLDERID_ProgramFilesuntuk mengambil jalur yang benar).
    Semuanya menemukan tempat itu secara otomatis dan polanya identik dengan setiap aplikasi yang Anda instal .

  4. Konsistensi masuk akal

    Ketika Anda mempelajari sesuatu, itu biasanya menyiratkan bahwa perilaku yang diamati konsisten. Kalau tidak, tidak ada yang perlu diamati dan dipelajari.

    Hal yang sama berlaku untuk sistem file kecil kami. Masuk akal untuk selalu memasukkan barang yang sama ke folder yang sama. Dengan begitu, kita akan tahu ke mana harus mencari ketika kita sedang mencari sesuatu.

    Sistem untuk perbedaan aplikasi 32/64 lebih jauh dari tujuan ini. Aplikasi dipisahkan menjadi 2 lokasi untuk menghindari konflik dalam nama, perilaku pemuatan biner dan keamanan (sampai batas tertentu).

Saya masih belum mengerti. Ini sepertinya tidak berguna

Anda seharusnya tidak pernah melupakan satu hal. Orang-orang sangat bodoh. Ini termasuk pengguna, pengguna super dan terutama programmer.

Inilah sebabnya mengapa kita memerlukan hal-hal seperti pengalihan sistem file bahkan untuk membuat sistem kita dapat digunakan.

Programmer hanya akan masuk ke sana dan mencoba memuat C:\Windows\system32\awesome.dlldan tidak peduli apakah mereka berjalan pada sistem 32 atau 64 bit. Mereka akan mencoba memuat DLL 64bit dan hanya crash. Beberapa programmer ingin menggunakan Office DLL, tidak masalah, mereka tahu di mana menemukannya! C:\Program Files\Microsoft\Office\14.0\wizards.dll... dan kecelakaan lain!

Semua permintaan dengan aplikasi 32bit ini dialihkan ke mitra 32bit untuk menghindari crash aplikasi.

Kami membutuhkan beberapa nama folder tetap untuk membangun sistem seperti itu. Jika tidak ada struktur folder untuk mendukung pengalihan ini, lalu bagaimana Anda membuatnya bekerja?

Oke, sekarang saya mengerti. Tapi mengapa tidak menggunakannya C:\Program Files\x86\?

Sekarang kita semakin filosofis ...

Apa yang salah jika saya entah bagaimana menghindari mekanisme pengalihan dan memaksa semuanya untuk menginstal ke nyata C:\Program Files\?

Kemungkinan besar tidak ada (selama aplikasi lain tidak bergantung pada lokasi tetap untuk aplikasi itu).

The WOW64 mekanisme kait ke CreateProcessdan akan melakukan yang lebih canggih (lebih canggih daripada memeriksa nama folder executable) pemeriksaan pada gambar dieksekusi untuk menentukan apakah itu adalah 32 atau 64 bit.

Ya, tapi maksud saya, seperti, SEMUA aplikasi!

  • Apa yang akan terjadi jika saya meletakkan kedua diesel dan gas ke dalam mobil saya?
  • Apa yang akan terjadi jika saya mencoba untuk menggunakan kedua bolak dan arus searah pada baris yang sama?
  • Apa yang akan terjadi jika saya tetap baik kucing saya dan saya ikan dalam akuarium yang sama?

Beberapa pertanyaan tidak memerlukan jawaban. Itu tidak dimaksudkan untuk dilakukan, jangan lakukan itu. Tidak ada yang bisa diperoleh di sini. Jumlah masalah yang bisa disebabkan oleh perubahan seperti itu akan selalu lebih besar daripada manfaat apa pun yang bisa dilihat seseorang dalam hal ini.


3
Apakah itu alasan awalnya? Tidak bisakah saya hanya menginstal aplikasi ke C:\Program Files\App32dan C:\Program Files\App64?
Stephen Jennings

4
@StephenJennings: Tapi itu mengharuskan Anda untuk membuat keputusan secara manual. Cara kerjanya sekarang adalah prosesnya otomatis, karena Windows tahu folder apa yang harus disediakan saat aplikasi memanggil SHGetSpecialFolderPathuntuk menentukan lokasi pemasangan.
Der Hochstapler

6
@ Sinetech: Mengapa menginstal ke %PROGRAMFILES%dalam di tempat pertama? Mengapa tidak memasukkan versi 32bit di desktop pengguna dan 64bit ke Keranjang Sampah? Hanya karena itu bisa dilakukan, bukan berarti itu ide yang bagus. Maaf, saya tidak mengikuti alasan Anda.
Der Hochstapler

4
@ Sinetech: Ya, Anda memang memberikan contoh yang sangat baik tentang bagaimana hal itu bisa dilakukan. Contoh lain yang sangat baik tentang bagaimana hal itu bisa dilakukan adalah cara yang sebenarnya sedang dilakukan sekarang. Cukup menulis file ke% PROGRAMFILES% dan memastikan bahwa file itu akan berakhir di folder yang benar adalah satu hal. Memeriksa sendiri folder mana yang benar adalah yang lain. Jika Anda benar-benar tidak melihat manfaat dari pendekatan sebelumnya, maka saya tidak akan dapat meyakinkan Anda. Pertanyaannya adalah mengapa ada 2 folder. Saya pikir jawaban saya sangat masuk akal dalam hal itu.
Der Hochstapler

3
@ OliverSalzburg, Tidak cukup. Pertanyaannya adalah mengapa dua folder yang diperlukan , tidak mengapa ada yang . Bahkan, dia bahkan berani: mengapa ini perlu? Anda tidak menjelaskan mengapa diperlukan dan contoh yang saya berikan (dan bahkan contoh sarkastik Anda sendiri) hanya menunjukkan bahwa itu tidak memiliki harus dilakukan dengan cara itu.
Synetech

14

TL; DR:

Singkatnya, tidak, itu tidak perlu ; mereka bisa menggunakan satu folder, dan tidak, Windows tidak menampilkan dirinya secara berbeda ke program yang dijalankan dari satu lokasi atau yang lain.


Yah, semua orang tampaknya memberikan pendapat mereka tentang ini, jadi saya akan melemparkan 2 ¢ saya. Yang lain telah menduga tentang alasan mengapa Microsoft memilih untuk membuat folder tingkat atas terpisah untuk versi 32-bit dan 64-bit program, jadi saya akan meninggalkan bagian itu (alasan terbaik adalah penjelasan David bahwa itu adalah sebagai kenyamanan bagi programmer). Tentu saja, itu tidak menjawab pertanyaan langsung mengapa ini perlu? , yang jawabannya mungkin: tidak .

Sebagai gantinya, saya akan membahas bagian utama dari pertanyaan

Apakah Windows entah bagaimana menampilkan dirinya secara berbeda ke program yang kehabisan "Program Files (x86)"?

Tidak juga, tetapi lokasi program dapat memengaruhi perilaku, tetapi tidak dengan cara yang Anda pikirkan.

Ketika Anda menjalankan suatu program, Windows mengatur lingkungan untuk menjalankannya (maksud saya dalam hal memori, pengalamatan, dll., Bukan hanya variabel lingkungan). Lingkungan ini tergantung pada konten yang dapat dieksekusi (program 32-bit dan 64-bit berbeda secara internal). Ketika Anda menjalankan program 32-bit pada sistem 64-bit, itu berjalan di subsistem 32-bit yang mengemulasi lingkungan 32-bit. Ini disebut WoW64 (WoW64 adalah singkatan dari Windows pada Windows 64-bit ) dan mirip dengan bagaimana aplikasi 16-bit dijalankan di XP menggunakan NTVDM .

Ketika Anda menjalankan sebuah program dengan atau tanpa hak admin, itu memengaruhi cara kerjanya, tetapi lokasi seharusnya tidak memengaruhinya (meskipun ada beberapa contoh ketergantungan lokasi seperti beberapa driver misalnya).

(Saya menggunakan komputer yang berbeda, jadi saya tidak bisa mengandalkan riwayat browser saya untuk melacak langkah saya, tetapi beberapa hari yang lalu ketika menjawab pertanyaan SU ini saya berakhir di pertanyaan SO ini yang menyebabkan saya ke Google PROCESSOR_ARCHITEW6432 yang mengarah ke pertanyaan SO ini dan posting blog Microsoft ini .)

Di suatu tempat di sepanjang jalan, saya membaca posting StackOverflow tentang bagaimana variabel envirnoment %processor_architecutre% memberikan hasil yang berbeda tergantung di mana Anda menjalankan command-prompt dari (saya akan mencoba untuk menemukan kutipan yang tepat).

Jawabannya ternyata karena apakah versi 32-bit atau 64-bit prompt perintah dijalankan (yaitu, dari System32\atau SysWoW64\). Dengan kata lain, sementara lokasi tampaknya mempengaruhi perilaku program, itu hanya karena ada beberapa versi program, bukan karena Windows memperlakukan folder dengan cara khusus.

Ini masuk akal karena isi file yang dapat dieksekusi menentukan apakah itu 32-bit atau 64-bit, sehingga Anda bisa meletakkan salinan 32-bit dan 64-bit dari program yang sama (misalnya, foobar32.exedan foobar64.exe) di folder yang sama dan ketika Anda jalankan mereka, mereka akan dimuat dengan benar (versi 64-bit akan dijalankan secara asli dan yang 32-bit akan dijalankan di lapisan emulasi WoW64).

FreePascal memungkinkan Anda untuk menginstal versi kedua DOS dan Windows dan mereka pergi dalam folder yang sama: %programfiles%\FreePascal. Ia mengatur arsitektur yang berbeda dengan menjaga file executable ( .exe, .sys, .dll, .ovr, dll) dalam folder terpisah dan berbagi file sumber daya seperti gambar, sumber-file, dll) Tidak ada alasan teknis yang ini tidak bisa juga dilakukan untuk 32 dan Versi program 64-bit. Seperti yang David katakan, akan lebih mudah bagi programmer jika mereka disimpan secara terpisah (yaitu, menggunakan variabel untuk membuatnya terlihat seperti hanya ada satu set file, dll.)


Balas dendam dengan memilih! Muahahaha! sigh
Synetech

Pilih-aneh aneh: \. BTW bagus menjelaskan +1.
avirk

11

Alasan lain adalah bahwa sebagian besar program digunakan untuk menggunakan variabel lingkungan seperti% PROGRAMFILES% untuk menunjukkan di mana program mereka diinstal. Untuk program 64 bit, ia pergi ke tempat normal. Untuk program 32 bit, itu akan mengarahkannya ke Program Files (x86)folder baru .

Meskipun, setidaknya dengan. Net hal baru di Visual Studio, mereka sekarang memiliki variabel App.Local yang menghilangkan seluruh kebutuhan untuk ini.


4
Itu tidak menjelaskannya. Siapa sebenarnya yang menggunakan variabel lingkungan dan mengapa itu peduli apakah suatu program 32-bit atau 64-bit?
Synetech

4
@ Sinetech - Penulis program menggunakan variabel lingkungan. Adapun alasan itu akan peduli adalah karena referensi ke dll. Anda tidak dapat memuat dll 32-bit dalam proses 64-bit dan sebaliknya.
Ramhound

1
Dan bagaimana %programfiles%, %programfiles(x86)%atau %programw6432%membuat perbedaan di sana? Setiap DLL yang dibagikan masuk ke direktori WinSxS tunggal, dan setiap DLL yang tidak dibagikan ada di sana dengan executable. Ini hanya masalah jika karena alasan tertentu Anda menginstal versi 32-bit dan 64-bit dari program yang sama, dan bahkan kemudian, Anda akan menjaga DLL 32-bit dengan 32-bit yang dapat dieksekusi dan DLL 64-bit dengan 64-bit yang dapat dieksekusi. Anda dapat melakukannya seperti ini: %programfiles%\CoolApp\bin\32dan% programfile% \ CoolApp \ bin \ 64`, mengapa memisahkan folder tingkat atas?
Synetech

@ Synetech Tentu tidak; % programfiles% sudah ada sejak lama. Jika Anda menginstal program 32 bit pada komputer 64 bit, memiliki satu tempat akan menyebabkan masalah untuk aplikasi 32 bit itu. WoW dapat mengarahkan% programfile% ke versi (x86) untuk aplikasi 32 bit, dan versi non-x86 untuk 64.
Andy

saya pikir orang tidak akan begitu bingung, jika tidak ada pengalihan implisit
kommradHomer

8

Solusi Microsoft untuk transisi ini dari 32-bit ke 64-bit adalah menambahkan dukungan lawas untuk sebagian besar aplikasi 32-bit. Dengan kata lain, sebagian besar aplikasi 32-bit akan berfungsi di lingkungan operasi 64-bit. Perlu diingat bahwa sistem operasi lain yang beroperasi pada arsitektur 64-bit tidak dapat memuat atau menjalankan aplikasi 32-bit sama sekali.

Untuk membantu mempermudah transisi, Microsoft telah menetapkan bahwa semua aplikasi 32-bit harus, secara default, dimuat ke folder Program Files (x86) daripada dicampur dengan aplikasi 64-bit yang sebenarnya dalam folder Program Files biasa.

Sumber

"Apa yang salah jika saya menghindari mekanisme pengalihan dan memaksa semuanya menginstal ke C: \ Program Files \" yang asli? "

Tidak ada. Kedua direktori program hanya untuk organisasi, atau untuk menjaga program yang memiliki dua versi terpisah versi 32-bit dan 64-bit, seperti Internet Explorer. Tetapi Anda dapat menginstal program 32-bit di "Program Files" dan program 64-bit di "Program Files x86" dan tidak akan terjadi apa-apa program akan menjalankan hal yang sama.

Wiki mengatakan:

Beberapa penginstal aplikasi menolak spasi di dalam lokasi jalur instal. Untuk sistem 32-bit, nama pendek untuk folder Program Files adalah Progra ~ 1 . Untuk sistem 64-bit, nama pendek untuk folder Program Files 64-bit adalah Progra ~ 1 (sama seperti pada sistem 32-bit); sedangkan nama pendek untuk folder Program Files (x86) 32-bit sekarang adalah Progra ~ 2 .


1
Hehe. Artikel yang bagus. Komentar untuk artikel itu terdengar persis seperti yang ada di sini. Lebih buruk lagi, artikel itu berasal dari lebih dari dua tahun yang lalu, yang hanya menunjukkan bahwa pertanyaan ini bukan hal baru dan jika masih belum dapat dijawab secara otoritatif, maka saya rasa tidak akan pernah (kecuali seseorang dari tim Windows berdebat). Oh well, saya kira kita semua harus berhenti khawatir dan belajar untuk mencintai bom, eh, maksud saya hidup dengan itu. +1 Untuk menunjukkan artikel dan menunjukkan bahwa pertanyaan ini sudah ada sejak lama.
Synetech

1
@ Synetech, terima kasih! Ya, ide di balik menempatkan tautan artikel sama dengan yang Anda dapatkan. Ini adalah pertanyaan waktu yang sangat lama tetapi IDK mengapa orang belum mendapatkannya. Namun MS harus menulis KB atau Dokumentasi untuk masalah ini :)
avirk

Ya mereka harus, terutama karena itu bukan hanya pengembang yang bertanya, bahkan pengguna biasa bertanya-tanya tentang hal itu. Sayangnya dokumentasi Microsoft tidak sering terlalu bagus.
Synetech

@Synetech ya! Dokumentasi MS menyebalkan sebagian besar waktu. Tapi ya mereka telah menulis beberapa artikel bagus juga dan saya cukup yakin mereka dapat dihitung;)
avirk

6

Alasannya adalah untuk membuat peningkatan program menjadi 64-bit lebih mudah bagi pengembang. Mereka tidak harus menulis kode khusus apa pun untuk memeriksa program di satu direktori ketika kompilasi dalam mode 32-bit dan di direktori lain ketika kompilasi dalam mode 64-bit; mereka hanya memeriksa C:\Program Files, dan ketika berjalan dalam mode 32-bit, ini secara otomatis akan diubah C:\Program Files (x86)oleh Windows 64-bit. Demikian pula, entri registri terisolasi antara program 32-bit dan 64-bit.

Ini mencegah konflik dari pengembang yang tidak mengetahui yang baru saja mengubah mode kompilasi mereka menjadi 64-bit tanpa banyak memikirkannya, dan mencegah sejumlah besar pekerjaan untuk pengembang yang ingin pengguna dapat menginstal versi 32-dan 64-bit dari mereka perangkat lunak secara bersamaan.


Tetapi mengapa ada program yang ingin memungkinkan kedua versi diinstal secara bersamaan? Salah satu contoh: Photoshop dan IE memiliki ekstensi yang asli. Dll. Anda tidak dapat memiliki kode 32-dan 64-bit yang dicampur dalam proses yang sama, jadi addon untuk versi 32-bit tidak dapat digunakan dengan versi 64-bit, dan sebaliknya. Jadi, Photoshop / IE harus mengizinkan kedua versi diinstal, atau berisiko menghancurkan basis besar add-on yang ada.


2
+1 Paling tidak Anda menjawab pertanyaan mendasar mengapa pengguna rata-rata memiliki kedua versi.
Synetech

5

Program yang berjalan pada "Program Files (x86)" menggunakan subsistem WOW64 (Windows 32-bit pada Windows 64-bit adalah seperangkat driver dan API yang bermaksud menjalankan aplikasi x32 melalui sistem arsitektur x64):

Subsistem WoW64 terdiri dari lapisan kompatibilitas ringan yang memiliki antarmuka serupa pada semua versi Windows 64-bit. Ini bertujuan untuk menciptakan lingkungan 32-bit yang menyediakan antarmuka yang diperlukan untuk menjalankan aplikasi Windows 32-bit yang tidak dimodifikasi pada sistem 64-bit. Secara teknis, WoW64 diimplementasikan menggunakan tiga dynamic-link libraries (DLLs):

  • Wow64.dll, antarmuka inti ke kernel Windows NT yang menerjemahkan antara panggilan 32-bit dan 64-bit, termasuk manipulasi penunjuk dan tumpukan
  • Wow64win.dll, yang menyediakan titik masuk yang sesuai untuk aplikasi 32-bit
  • Wow64cpu.dll, yang menangani pergantian prosesor dari mode 32-bit ke 64-bit

Sistem 64 bit perlu "meniru" aplikasi 32 bit, itulah alasan mengapa Windows perlu "memisahkan" dua folder Program Files.


7
Tetapi mengapa harus meletakkannya di folder yang berbeda? Windows sudah sepenuhnya mampu menentukan arsitektur yang dapat dieksekusi dengan melihat header PE. Mengapa ia tidak dapat memuat lingkungan yang sesuai ketika memuat yang dapat dieksekusi?
Synetech

1
Saya pikir itu hanya pilihan dari Microsoft untuk dengan mudah menunjukkan kepada pengguna arsitektur mana yang mereka inginkan dari dua versi program saat membuka program. Maksud saya, jika tidak ada dua folder ini dan apakah itu transparan untuk pengguna (jika beralih secara otomatis), mereka tidak akan tahu apakah menjalankan aplikasi 32 atau 64 bit, bahkan, mereka tidak akan tahu program mana yang harus dibuka jika berjalan pada 64 bit ..
Diogo

1
Versi 64-bit dari IE memiliki reputasi sebagai mengerikan.
Samuel Edwin Ward

1
MS merekomendasikan untuk menggunakan office32 kecuali jika Anda bekerja dengan kumpulan data yang cukup besar untuk melampaui batasan memori. Saya percaya perlunya mengkompilasi ulang addon biner untuk bekerja dengan office64; dikombinasikan dengan tidak memberikan manfaat dalam kasus penggunaan normal ada di belakang keputusan.
Dan Neely

1
Saya pikir Anda akan menemukan bahwa program 64-bit yang diinstal secara eksplisit ke folder Program Files (x86) akan berfungsi dengan normal (dan, dalam banyak kasus, sebaliknya). Windows tidak menggunakan lokasi folder untuk menentukan cara memperlakukan yang dapat dieksekusi.
Harry Johnston

5

Sangat menarik bahwa jawaban di sini dan di internet sedikit berbeda. Menemukan jawaban yang akurat untuk pertanyaan penting ini merupakan tantangan. Tampaknya ada sedikit informasi palsu yang disajikan di internet, yang menyebabkan kebingungan.

Saya telah melakukan sejumlah besar penelitian, dan telah menarik kesimpulan berikut, yang saya yakini akurat:

  • Tidak ada bedanya di mana aplikasi disimpan. Saat runtime, Windows akan menentukan apakah aplikasi tersebut 32-bit atau 64-bit dan secara otomatis menggunakan bagian DLL dan registri yang sesuai.

Ini terjadi secara otomatis, dan tidak tergantung tempat penyimpanan aplikasi. Tidak ada kecepatan, keandalan, atau manfaat fungsional lainnya untuk memiliki folder 32-bit dan 64-bit yang terpisah.

Satu-satunya alasan pemisahan standar menjadi dua folder ('Program Files' dan 'Program Files (x86)') adalah bahwa jika Anda memiliki dua versi program yang sama (versi 32-bit dan 64-bit), ia menyediakan cara sederhana untuk menjaga file yang tumpang tindih terpisah. Bahkan dalam kasus ini, selama semua nama file unik, mereka sebenarnya bisa ada di folder yang sama tanpa konsekuensi apa pun.

Ada peringatan untuk kesimpulan di atas, dan itu adalah salah satu aplikasi yang tidak memiliki kode. Jika suatu aplikasi memiliki jalur yang di-hardcod ke dalamnya, itu hanya akan menggunakan jalur itu. Sebagai aturan, path seharusnya tidak pernah di-hardcode ke dalam suatu aplikasi, tetapi kadang-kadang seorang programmer akan membuat kesalahan ini. Dalam hal ini, program akan menggunakan jalur hardcoded; direktori tempat aplikasi diinstal tidak akan memengaruhi tempat sebenarnya mencari file.


3

Harus memisahkan folder memungkinkan untuk menjaga aplikasi 64-bit asli dan thos yang memerlukan WoW64 terpisah.

Ini bisa berguna - seperti yang sudah ditunjukkan oleh @OliverSalzburg - jika Anda ingin menginstal browser web 64-bit dan 32-bit (misalnya), karena beberapa plug-in dan add-on mungkin hanya tersedia untuk salah satu dari keduanya

Harus memisahkan folder membuat pemisahan ini otomatis , menggunakan teknik seperti pengalihan registri .

Misalkan penginstal mencoba menentukan folder file program dengan membaca registri dengan menggunakan, misalnya, RegQueryValueEx .

Bagaimanapun, ia mencoba membaca kunci registri

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion

yang biasanya menunjuk ke C:\Program Files.

Namun, jika penginstal adalah aplikasi 32-bit, pengalihan registri akan menyebabkan kunci regitry

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion

untuk dibaca, yang biasanya menunjuk ke C:\Program Files (x86).

Mengapa nama folder khusus ini digunakan hanya dapat dijawab oleh orang-orang yang membuat pilihan ini. Anda selalu dapat mengubah nama folder default jika Anda mau.

Apakah Windows entah bagaimana menampilkan dirinya secara berbeda ke program yang kehabisan "Program Files (x86)"?

Aku meragukan itu. Sebagian besar penginstal mengizinkan Anda untuk memilih folder penginstalan khusus, jadi tidak masalah di mana program diinstal.


Maaf saya mencampur "izin" dengan "melarang"
Wernfried Domscheit

3

Saya tidak percaya kebingungan di sini .. pertama saya adalah pengembang penuh waktu.

MS melakukan ini untuk menyelesaikan kasus di mana DLL digunakan oleh aplikasi 32-bit yang lebih lama dan aplikasi 64-bit yang lebih baru. Metode yang lebih lama tidak dapat diubah (System32, Program Files, dll.) Karena itu akan merusak program lama yang tidak dapat dikompilasi ulang.

Jadi MS membuat folder untuk menyimpan program, majelis, dan pustaka 64-bit tertentu sehingga program baru dapat terhubung ke pustaka yang tepat, dan program yang lebih lama akan terus bekerja seperti biasa.

Seperti berdiri, .LL Net dapat hidup berdampingan dengan versi lain pada mesin yang sama. Misalnya, Anda dapat memiliki Library.1.0.1, Library.1.0.2, Library 1.1.0, dll. Dan ini hanya untuk ukuran bit tertentu (32 atau 64). Jika folder terpisah tidak digunakan, maka setiap unit harus memiliki versi 32 dan 64 bit. Ini akan sangat mengacaukan direktori yang sudah berisi banyak versi dari rakitan yang sama.

Ini semua hal pengembang. Sebagai pengguna saya hanya harus menghadapinya ketika saya bekerja dengan program 32-bit pada Windows 7 64. Dan saya lebih suka memiliki kemampuan untuk menjalankan versi 32-bit dan aplikasi yang sama dalam 64-bit juga. Ketika saya sedang mengerjakan aplikasi 32-bit yang harus saya kompilasi dalam 64-bit, yang saya lakukan hanyalah memberi tahu kompiler untuk melakukannya. Nama Dll dan yang lainnya tetap sama.

Alasan ini tidak ada pada Windows 95/98 adalah sistem yang disimulasikan runtime 32-bit; itu bukan sistem operasi 32-bit asli. Itu memalsukan eksekusi 32-bit dengan sesuatu yang bernama "thunking".

Berikut definisi yang bagus: http://searchwinit.techtarget.com/definition/thunk


1
Bagaimana 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` atau \blah\32; Bagaimanapun, mereka dipisahkan. Jika ada, cara saat ini memisahkan komponen aplikasi (dan juga menduplikasinya secara tidak perlu karena beberapa aplikasi menggunakan CommonFilessumber daya dan semacamnya. Selain itu, Anda membuatnya terdengar seolah-olah aplikasi membuang DLL mereka dalam keranjang bersama. Cukup mudah untuk menyimpan aplikasi DLL 32-bit dengan ongkos 32-bit dan DLL 64-bit dengan ongkos 64-bit
Synetech

Oh, dan untuk 95/98, siapa yang mengatakan sesuatu tentang itu? Bahkan XP memiliki subsistem 16-bit (NTVDM).
Synetech

Saya pikir Anda ingin penjelasan. Beberapa aplikasi menggunakan CommonFiles? Saya memiliki 35 aplikasi berbeda yang memiliki entri di sana. Ini adalah tempat yang lebih aman untuk menyimpan komponen bersama daripada direktori System32. Pernyataan Anda bahwa beberapa aplikasi menggunakan ini masih bisa diperdebatkan. Mengutip Anda: "Mereka tidak harus melewati rintangan ini untuk memungkinkan program 32-bit dan 16-bit pada sistem yang sama. Saya tidak ingat pernah melihat ProgramFiles (16) atau semacamnya [...] Bagian tentang hal itu dilakukan sebagai kenyamanan bagi programmer yang masuk akal. " Ya, ya .. programmer melakukannya. Kami menulis aplikasi setelah semua.
Jason Locke

Ya?
Synetech

Baca kembali ini .. katanya lebih baik dalam balasannya - superuser.com/a/442253/142951 . Jika Anda bukan pengembang, Anda mungkin tidak melihat tujuannya.
Jason Locke

0

Tidak perlu sama sekali. Sebagai contoh di komputer saya yang bekerja, saya menginstal setiap aplikasi dalam folder C:\MyPrograms\untuk memisahkannya dari aplikasi yang diinstal oleh departemen TI kami.

Tentu saja, ini mencegah saya untuk menginstal kedua versi (32 dan 64 bit) dari satu aplikasi, tetapi ini tidak ada masalah dalam kasus saya.

Setiap kali Anda meluncurkan program, maka selalu DLL pertama C:\Windows\System32\ntdll.dlldieksekusi. DLL ini menentukan apakah program Anda adalah aplikasi 32 atau 64 bit. Tergantung pada bahwa Anda diarahkan ke WoW64yang sudah disebutkan dalam beberapa jawaban.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.