لماذا تنقل DLLs 64 بت إلى System32 و DLLS 32 بت إلى SYSWOW64 على Windows 64 بت؟

Question

أود أن أعرف متى نحتاج إلى وضع ملف تحت

C: Windows System32 أو C: Windows SYSWOW64، على نظام Windows 64 بت.

كان لدي اثنين من DLL، واحد لمدة 32 بت، واحد لمدة 64 بت.

منطقيا، اعتقدت أنني سأضع DLL 32 بت تحت C: Windows System32، و DLL 64 بت ضمن C: Windows Syswow64.

لدهشتي، انها على العكس من ذلكفي ال 32-bit واحد يذهب إلى c: windows sysswow64, ، و ال 64Withbit DLL يذهب إلى C: Windows System32.

أشياء مربكة جدا. ما السبب وراء هذا؟

Answer 1

أعتقد أن النية كانت لإعادة تسمية System32، ولكن الكثير من التطبيقات التي ترميزها بجد لهذا المسار، أنه لم يكن من الممكن إزالته.

لم يكن SYSWOW64 مخصصا ل DLLs من أنظمة 64 بت، فهو في الواقع شيء مثل "Windows على نظام التشغيل Windows64"، مما يعني أن البتات تحتاج إلى تشغيل تطبيقات 32 بت على Windows 64bit.

هذه المقالة يشرح قليلا:

"يحتوي نظام التشغيل Windows X64 على دليل System32 يحتوي على DLLS 64 بت dllsbit dlls. يقوم معيد التوجيه لنظام الملفات يقوم بسحر إخفاء دليل System32 الحقيقي لعمليات 32 بت وعرض SYSWOW64 تحت اسم System32. "

تحرير: إذا كنت تتحدث عن مثبت، فأنت حقا لا يجب من الصعب رمز المسار إلى مجلد النظام. بدلا من ذلك، دع Windows يعتني به لك بناء على ما إذا كان برنامج التثبيت الخاص بك يعمل على طبقة المضاهاة أم لا.

Answer 2

يجب أن أضيف: يجب ألا تضع DLL في System32 على أي حال! تعديل التعليمات البرمجية الخاصة بك، تعديل المثبت الخاص بك ... العثور على منزل لبيتك غير الموجودة في أي مكان تحت C: Windows

على سبيل المثال، مثبت الخاص بك يضع DLLs الخاص بك في:

\program files\<your app dir>\

or

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

(ملحوظة: الطريقة التي تفعلها في الواقع هو استخدام البيئة var:٪ programfiles٪ أو٪ programfiles (x86)٪ للعثور على ملفات البرنامج هي .... لا تفترض أنه C: Program Files ....)

ثم تعيين علامة التسجيل:

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

يقرأ التعليمات البرمجية التي تستخدم DLLs التسجيل، ثم يرتبط ديناميكيا إلى DLLs في هذا الموقع.

ما سبق هو الطريقة الذكية للذهاب.

أنت لا تقوم بتثبيت DLLs الخاص بك، أو DLLs من الطرف الثالث في System32 أو syswow64. إذا كان عليك تحميل ثابت، فأنت تضع DLLs في EXE DIR (حيث سيتم العثور عليها). إذا لم تتمكن من التنبؤ إكس Dir (على سبيل المثال، فسيتم استدعاء بعض EXE الأخرى DLL)، فقد تضطر إلى وضع DLL Dir الخاص بك إلى مسار البحث (تجنب هذا إذا كان ذلك على الإطلاق!)

System32 و SYSWOW64 هي ل Windows توفر الملفات ... ليس لأي شخص ملامح. وبعد السبب الوحيد الذي دخل الناس في العادة السيئة لوضع الاشياء هناك لأنه دائما في مسار البحث، والعديد من التطبيقات / الوحدات النمطية تستخدم الارتباط الثابت. (إذن، إذا كنت تستمر بالفعل في ذلك، فإن الخطيئة الحقيقية هي ربط ثابت - هذه هي الخطيئة في التعليمات البرمجية الأصلية والرمز المدار - دائما دائما رابط دائما ديناميكيا دائما!)

Answer 3

ركض في نفس المشكلة وبحوث هذا لبضع دقائق.

تم تدريسها لاستخدام Windows 3.1 و DOS، تذكر تلك الأيام؟ بعد فترة وجيزة من عملت مع أجهزة كمبيوتر Macintosh بدقة لبعض الوقت، ثم بدأت في العودة إلى Windows بعد شراء جهاز X64-BIT.

هناك أسباب فعلية وراء هذه التغييرات (سيقول البعض أهمية تاريخية)، وهذا ضروري للمبرمجين لمواصلة عملهم.

يتم ذكر معظم التغييرات أعلاه:

• Program Files ضد Program Files (x86)

  في بداية ملفات 16 / 86bit كتبت على معالجات Intel 86 '.

• System32 يعني حقا System64 (على نوافذ 64 بت)

  عندما بدأ المطورون في العمل أولا مع Windows7، كانت هناك العديد من مشكلات التوافق حيث توجد تطبيقات أخرى حيث يتم تخزينها.

• SysWOW64 يعني حقا SysWOW32

  أساسا، في اللغة الإنجليزية العادية، وهذا يعني "Windows على النوافذ داخل آلة 64 بت '. وبعد يشير كل مجلد إلى المكان الذي توجد فيه DLLs للتطبيقات التي يرغبون في استخدامها.

فيما يلي روابطان بكل المعلومات الأساسية التي تحتاجها:

• MSDN ملف معيد التوجيه

• شرح SYSWOW64.

نأمل أن يكون هذا يمهد الامور!

Answer 4

System32 هو المكان الذي وضعه Windows تاريخيا جميع dlls 32bit، وكان النظام ل DLL 16 بت. عندما أنشأت Microsoft نظام التشغيل 64 بت، كل شخص أعرفه من المتوقع أن يقيم الملفات الموجودة تحت System64، لكن Microsoft قررت أنه أصبح منطقي أكثر لوضع ملفات 64bit ضمن System32. والسبب الوحيد الذي تمكنت من العثور عليه، هو أنهم يريدون كل ما كان 32bit للعمل في نظام Windows 64bit w / o الحاجة إلى تغيير أي شيء في البرامج - فقط إعادة ترجمة، ويتم ذلك. الطريقة التي يحلها هذا، بحيث لا يزال من الممكن تشغيل تطبيقات 32 بتسير، إنشاء نظام فرعي 32 بت Windows يسمى Windows32 على نظام Windows64. على هذا النحو، تم إنشاء اختصار SYSWOW64 لدليل النظام للنظام الفرعي 32 بت. SYS قصيرة للنظام، و WOW64 قصيرة ل Windows32Onwindows64.
نظرا لأن Windows 16 مفصل بالفعل من Windows 32، لم تكن هناك حاجة لنظام التشغيل Windows 16 على معادلات Windows 64. ضمن النظام الفرعي 32 بت، عندما يذهب البرنامج إلى استخدام الملفات من دليل System32، فإنهم يحصلون في الواقع على الملفات من دليل SYSWOW64. لكن العملية معيبة.

إنه تصميم فظيع. وفي تجربتي، اضطررت إلى إجراء المزيد من التغييرات في كتابة تطبيقات 64 بت، والتي ببساطة تغيير دليل SYSTEM32 لقراءة SYSTEM64 كان من شأنه أن يكون تغييرا صغيرا للغاية، وتم تهدف توجيه توجيهات مترجم مسبقا إلى التعامل معها.

Answer 5

قام أشخاص آخرون بالفعل بعمل جيد في شرح هذا البلاغة Ridiculus ... وأعتقد أن كريس هوفمان فعل وظيفة أفضل هنا: https://www.howtogeek.com/326509/whats-the-difference-between-system32-and-syswow64-folders- windows/

بلدي اثنين من الأفكار:

1. كلنا نجعل جميع أخطاء غبية قصيرة النظر في الحياة. عندما تسمى Microsoft (في ذلك الوقت) دليل Win32 DLL "System32"، فإنه منطقي في ذلك الوقت ... لقد لم يأخذوا في الاعتبار ما سيحدث إذا / عند إصدار 64 بت (أو 12 بت) من نظام التشغيل الخاصة بهم تم تطويره لاحقا - وسيسبب مشكلة التوافق المتخلص الهائل مثل هذا الاسم الدليل. بعد فوات الأوان دائما 20-20، لذلك لا أستطيع إلقاء اللوم عليهم (أكثر من اللازم) مثل هذا الخطأ. ... ومع ذلك ... عندما قامت Microsoft في وقت لاحق بتطوير نظام التشغيل 64 بت، حتى مع فائدة الفقر، لماذا يا لماذا لن يجعلوا ليس فقط الخطأ بالضبط نفس البصر مرة أخرى ولكن يجعلها أسوأ من خلال إعطاء عن قصد هذا اسم مضلل؟ عار عليهم!!! لماذا لا يطلق على الأقل في الواقع الدليل "Syswin32onwin64" لتجنب الارتباك؟!؟ وما يحدث عندما ينتج في النهاية نظام تشغيل 128 بت ... إذن، أين سيقومون بوضع DLL DLL من 32 بت و 64 بت و 128 بت؟!

2. كل هذا المنطق لا يزال يبدو معيبا تماما بالنسبة لي. على إصدارات 32 بت من Windows، يحتوي SYSTEM32 على DLLs 32 بت؛ على إصدارات 64 بت من Windows، يحتوي SYSTEM32 على DLLS 64 بت ... بحيث لا يتعين على المطورين إجراء تغييرات التعليمات البرمجية، صحيحة؟ المشكلة في هذا المنطق هي أن هؤلاء المطورين إما الآن جعل تطبيقات 64 بت تحتاج إلى DLLS 64 بت أو أنها تجعل تطبيقات 32 بت تحتاج إلى DLLs 32 بت ... في كلتا الحالتين، لا تزال مثبتة؟ أعني، إذا كان لا يزالون يستخدمون تطبيقا 32 بت، لأنه يعمل الآن على نوافذ 64 بت، فسيحتاجون الآن إلى إجراء تغيير رمز للعثور على / مرجع نفسه في نفس OL "32 بت DLL المستخدمة قبل (موجود الآن في SYSWOW64). أو، إذا كانوا يعملون على تطبيق 64 بت، فسوف يحتاجون إلى إعادة كتابة التطبيق القديم الخاص بهم لنظام التشغيل الجديد على أي حال ... لذلك كان هناك حاجة إلى إعادة ترجمة / إعادة بناء على أي حال !!!

مايكروسوفت تؤلمني في بعض الأحيان.