Mengapa DLL 64-bit pergi ke System32 dan DLL 32-bit ke SysWoW64 di Windows 64-bit?


227

Saya ingin tahu kapan kita perlu meletakkan file di bawah

C: \ Windows \ System32 atau C: \ Windows \ SysWOW64, pada sistem windows 64-bit.

Saya punya dua DLL, satu untuk 32-bit, satu untuk 64-bit.

Secara logis, saya pikir saya akan menempatkan DLL 32-bit di bawah C: \ Windows \ System32, dan DLL 64-bit di bawah C: \ Windows \ SysWOW64.

Yang mengejutkan saya, itu sebaliknya ! Yang 32- bit masuk ke C: \ Windows \ SysWOW 64 , dan DLL 64- bit masuk ke C: \ Windows \ System 32 .

Hal yang sangat membingungkan. Apa alasan di balik ini?


2
Juga, ini: Windows terlihat di direktori kerja saat ini serta di PATH sistem. Tidak ada cara untuk menentukan sebaliknya. Oh, tunggu, ada. Anda dapat menyematkan jalur pencarian di DLL Anda. Itu adalah bidang yang panjangnya 8 byte. Iya. 8 karakter.
Jeroen Baert

Ini tampaknya tidak benar pada Windows 7. Menjalankan file pada DLL di file system32 C: \ Windows \ system32 \ user32.dll C: \ Windows \ system32 \ user32.dll; PE32 yang dapat dieksekusi untuk MS Windows (DLL) (GUI) Intel 80386 32-bit Tetapi untuk DLL 64-bit, ia mencetak PE32 + yang dapat dieksekusi untuk MS Windows (DLL) (konsol) Perakitan Mono / .Net. Perhatikan bahwa DLL ini bukan .Net majelis. Ini adalah DLL asli.
user877329


11
Wawancara dengan mantan Microsoft . (Untuk penjelasan serius tentang bagaimana hal ini terjadi, lihat jawaban ini .)
Tgr

superuser.com/a/157301/241386 "Mundur alasan kompatibilitas. Banyak aplikasi mengasumsikan hal-hal yang seharusnya tidak mereka anggap dan jalur hard-code"
phuclv

Jawaban:


225

Saya percaya maksudnya adalah untuk mengubah nama System32, tetapi begitu banyak aplikasi yang dikodekan untuk jalur itu, sehingga tidak layak untuk menghapusnya.

SysWoW64 tidak dimaksudkan untuk dll dari sistem 64-bit, itu sebenarnya sesuatu seperti "Windows on Windows64", yang berarti bit yang Anda butuhkan untuk menjalankan aplikasi 32bit pada windows 64bit.

Artikel ini sedikit menjelaskan:

"Windows x64 memiliki System32 direktori yang berisi 64-bit DLL (sic!). Dengan demikian proses asli dengan bitness 64 menemukan DLL" mereka "di mana mereka mengharapkannya: dalam folder System32. Direktori kedua, SysWOW64, berisi 32 -bit DLL. Redirector sistem file melakukan keajaiban menyembunyikan direktori System32 nyata untuk proses 32-bit dan menunjukkan SysWOW64 dengan nama System32. "

Sunting: Jika Anda berbicara tentang penginstal, Anda seharusnya tidak membuat hard-path path ke folder sistem. Sebagai gantinya, biarkan Windows yang menanganinya untuk Anda berdasarkan apakah installer Anda berjalan pada lapisan emulasi atau tidak.


27
Ugh, aku baru saja bertemu dengan keanehan ini hari ini. Betapa menyesatkan hal yang telah mereka lakukan.
Andy White

16
Berlari ke hari ini juga ... sangat membingungkan - Glut 32-bit dll masuk ke / SysWOW64, Glut 64-bit dll masuk ke / System32. Seseorang harus menuliskannya. Di internet.
Jeroen Baert

8
Berita baiknya adalah, sebagai contoh jenius rekayasa Microsoft, ini cukup banyak mendokumentasikan diri.
Spike0xff

8
Satu hal yang tidak saya dapatkan adalah, jika sistem file dapat mengatakan bahwa itu adalah aplikasi 32 bit dan mengarahkannya ke SysWOW64folder, mengapa mereka tidak dapat mendeteksi aplikasi 64 bit dan mengalihkan ke System64?!
Cole Johnson

6
System32 adalah versi Windows 32 bit dari Sistem DLL. Sistem adalah versi 16 bit. Perusahaan yang sama yang memberi kami Windows 8 memberi kami SysWow64 untuk DLL 32 bit dan System32 untuk DLL 64bit ketika dijalankan pada OS 64bit. Dalam sistem 64 bit, folder Sistem masih merupakan sampah 16 bit lama, hanya System32 tidak 32bit seperti yang disarankan, dan barang 32 bit ada di direktori Sistem dengan 64 nama. Saya gagal melihat bagaimana ini membantu siapa pun. itu merumitkan banyak hal, dan menghancurkan segalanya. Semua untuk menyelamatkan orang dari mengadaptasi hard-coded "System32" ke "System64" ketika mengkonversi ke 64bit. Idiocy
Armand

26

Saya harus menambahkan: Anda tidak harus menempatkan dll Anda ke \ system32 \ toh! Ubah kode Anda, modifikasi pemasang Anda ... temukan rumah untuk bit Anda yang TIDAK berada di bawah c: \ windows \

Sebagai contoh, installer Anda menempatkan dll Anda ke:

\program files\<your app dir>\

or

\program files\common files\<your app name>\

( Catatan : Cara Anda benar-benar melakukan ini adalah dengan menggunakan lingkungan var:% ProgramFiles% atau% ProgramFiles (x86)% untuk menemukan di mana File Program .... Anda tidak menganggap itu c: \ program file \ .. ..)

dan kemudian menetapkan tag registri:

HKLM\software\<your app name>
-- dllLocation

Kode yang menggunakan dll Anda membaca registri, lalu secara dinamis menautkan ke dll di lokasi itu.

Di atas adalah cara cerdas untuk melakukannya.

Anda tidak pernah menginstal dll, atau pihak ketiga dll ke \ system32 \ atau \ syswow64. Jika Anda harus memuat secara statis, Anda meletakkan dll Anda di dir exe Anda (di mana mereka akan ditemukan). Jika Anda tidak dapat memprediksi dir exe (mis. Exe lain akan memanggil dll Anda), Anda mungkin harus meletakkan dir dll Anda ke jalur pencarian (hindari ini jika sama sekali poss!)

system32 dan syswow64 untuk file yang disediakan Windows ... bukan untuk siapa pun file lain . Satu-satunya alasan orang memiliki kebiasaan buruk menaruh barang di sana adalah karena selalu ada di jalur pencarian, dan banyak aplikasi / modul menggunakan tautan statis. (Jadi, jika Anda benar-benar melakukannya, dosa sebenarnya adalah tautan statis - ini adalah dosa dalam kode asli dan kode terkelola - selalu selalu selalu terhubung secara dinamis!)


9
+1 ... tapi saya akan menambahkan bahwa Anda harus menggunakan variabel seperti% PROGRAMFILES% bukan \ Program Files \
Rod MacPherson

Pada hari-hari XP, itu adalah praktik umum (dan disarankan) bagi pengembang untuk menggunakan registri untuk hal-hal seperti itu. Dengan Windows 7, ini tidak lagi benar! Untuk alasan UAC, beberapa sesi pengguna, dll. Registri pada Windows 7 harus digunakan dengan hemat dan dengan kebijaksanaan oleh pengembang.
ryyker

@RodMacPherson Respons saya telah ditingkatkan untuk mempertimbangkan saran Anda. Anda benar!
Jonesome Reinstate Monica

Setelah beberapa pertimbangan, saya pikir ini menjawab pertanyaan yang lebih baik - "Kapan kita perlu menempatkan file di bawah% SYSTEMROOT%". Tidak pernah. Jawaban ini tidak memuaskan rasa ingin tahu tentang folder syswow64, tapi itu yang benar-benar perlu dibaca oleh pengembang.
Thomas

7

Mengalami masalah yang sama dan meneliti ini selama beberapa menit.

Saya diajari menggunakan Windows 3.1 dan DOS, ingat masa itu? Tidak lama setelah saya bekerja dengan komputer Macintosh secara ketat selama beberapa waktu, kemudian mulai bergoyang kembali ke Windows setelah membeli mesin x64-bit.

Ada alasan aktual di balik perubahan ini (beberapa akan mengatakan signifikansi historis), yang penting bagi programmer untuk melanjutkan pekerjaan mereka.

Sebagian besar perubahan disebutkan di atas:

  • Program Files vs. Program Files (x86)

    Pada awalnya file 16 / 86bit ditulis, prosesor Intel '86'.

  • System32 sangat berarti System64 (pada Windows 64-bit)

    Ketika pengembang pertama kali mulai bekerja dengan Windows7, ada beberapa masalah kompatibilitas di mana aplikasi lain disimpan.

  • SysWOW64 sangat berarti SysWOW32

    Pada dasarnya, dalam bahasa Inggris yang sederhana, ini berarti 'Windows pada Windows dalam mesin 64-bit' . Setiap folder menunjukkan di mana DLL berada untuk aplikasi yang ingin mereka gunakan.

Berikut adalah dua tautan dengan semua info dasar yang Anda butuhkan:

Semoga ini beres!


4
Jika Anda ingin dianggap serius, Anda mungkin harus mengurangi gaul dan meningkatkan tata bahasa. Juga, Anda mungkin ingin menyusun jawaban Anda sedikit lagi, gunakan paragraf.
Klas Mellbourn

2
@Crispy membersihkan jawabannya. Di masa depan, Anda harus mempertimbangkan apa yang disarankan oleh Klas dan memformat respons Anda untuk meningkatkan peluang upvote. :)
RekindledPhoenix

OP perlu sepenuhnya ditulis ulang, atau bahkan dihapus. Ini menyesatkan dan tidak terlalu berguna.
Jonesome Reinstate Monica

5
SysWOW64 sebenarnya adalah singkatan dari: [Sys] tem [W] indows 32-bit [o] n [W] indows [64] -bit dengan demikian singkatan dari SysWoW64 (yang benar-benar tidak masuk akal, dan Microsoft telah meninggalkan System32 untuk barang 32bit , dan menciptakan System64, benar-benar tidak akan ada masalah kompatibilitas. Apa yang dilakukan Microsoft di kotak pasir WoW adalah membuat pengalihan dalam memori dari akses 32bit ke System32 sebagai permintaan ke SysWoW64 ... bagaimana ini tidak lebih rumit daripada sekadar mengekspos sistem file di mentah tanpa harus memetakannya secara ajaib untuk platform yang berbeda? Seperti disebutkan dalam komentar sebelumnya - Idiocy.
Armand

1
Jawaban membawa lebih banyak kesalahpahaman daripada kejelasan tentang pertanyaan, komentar Armands adalah penjelasan yang baik.
nahab

5

System32 adalah tempat Windows secara historis menempatkan semua DLL 32bit, dan System adalah untuk DLL 16bit. Ketika microsoft menciptakan OS 64 bit, semua orang yang saya tahu diharapkan file berada di bawah System64, tetapi Microsoft memutuskan lebih masuk akal untuk meletakkan file 64bit di bawah System32. Satu-satunya alasan saya dapat menemukan, adalah bahwa mereka menginginkan semua yang 32bit bekerja di Windows 64bit tanpa harus mengubah apa pun dalam program - hanya mengkompilasi ulang, dan itu dilakukan. Cara mereka memecahkan ini, sehingga aplikasi 32bit masih dapat berjalan, adalah dengan membuat subsistem windows 32bit yang disebut Windows32 Pada Windows64. Dengan demikian, akronim SysWOW64 diciptakan untuk direktori Sistem subsistem 32bit. Sys adalah kependekan dari System, dan WOW64 adalah kependekan dari Windows32OnWindows64.
Karena windows 16 sudah dipisahkan dari Windows 32, maka tidak perlu untuk kesetaraan Windows 16 Pada Windows 64. Di dalam subsistem 32bit, ketika sebuah program menggunakan file dari direktori system32, mereka sebenarnya mendapatkan file dari direktori SysWOW64. Namun prosesnya cacat.

Ini desain yang mengerikan. Dan dalam pengalaman saya, saya harus melakukan lebih banyak perubahan untuk menulis aplikasi 64bit, yang hanya mengubah direktori System32 untuk membaca System64 akan menjadi perubahan yang sangat kecil, dan salah satu yang akan ditangani oleh arahan pra-kompiler.


2

Orang lain telah melakukan pekerjaan yang baik untuk menjelaskan teka-teki ridiculus ini ... dan saya pikir Chris Hoffman melakukan pekerjaan yang lebih baik di sini: https://www.howtogeek.com/326509/whats-the-difference-between-the- system32-and-syswow64-folder-in-windows /

Dua pemikiran saya:

  1. Kita semua membuat kesalahan bodoh dalam hidup. Ketika Microsoft menamai direktori Win32 DLL (System32 ") pada saat itu, masuk akal pada saat itu ... mereka tidak mempertimbangkan apa yang akan terjadi jika / ketika versi 64-bit (atau 128-bit) OS mereka dikembangkan kemudian - dan masalah kompatibilitas mundur besar-besaran seperti nama direktori akan menyebabkan. Hindsight selalu 20-20, jadi saya tidak bisa menyalahkan mereka (terlalu banyak) untuk kesalahan seperti itu. ... NAMUN ... Ketika Microsoft kemudian mengembangkan sistem operasi 64-bit mereka, bahkan dengan manfaat melihat ke belakang, mengapa oh mengapa mereka membuat tidak hanya kesalahan berpandangan pendek yang sama LAGI tetapi membuatnya lebih buruk dengan TUJUAN memberikan secara penuh itu nama yang menyesatkan?!? Malu pada mereka!!! Mengapa TIDAK SETIDAKNYA sebenarnya menamai direktori "SysWin32OnWin64" untuk menghindari kebingungan ?! ? Dan apa yang terjadi ketika mereka akhirnya menghasilkan OS 128-bit ... lalu di mana mereka akan meletakkan DLL 32-bit, 64-bit, dan 128-bit?!?

  2. Semua logika ini tampaknya masih benar-benar cacat bagi saya. Pada Windows versi 32-bit, System32 berisi DLL 32-bit; pada Windows versi 64-bit, System32 mengandung DLL 64-bit ... sehingga pengembang tidak perlu membuat perubahan kode, benar? Masalah dengan logika ini adalah bahwa para pengembang sekarang membuat aplikasi 64-bit yang membutuhkan DLL 64-bit atau mereka membuat aplikasi 32-bit yang membutuhkan DLL 32-bit ... bagaimanapun juga, bukankah mereka masih kacau? Maksud saya, jika mereka masih membuat aplikasi 32-bit, untuk itu sekarang dapat berjalan di Windows 64-bit, mereka sekarang harus membuat perubahan kode untuk menemukan / referensi DLL 32-bit yang sama mereka digunakan sebelumnya (sekarang terletak di SysWOW64). Atau, jika mereka bekerja pada aplikasi 64-bit, mereka harus menulis ulang aplikasi lama mereka untuk OS baru ... jadi rekompilasi / pembangunan kembali akan tetap diperlukan !!

Microsoft terkadang menyakitiku.

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.