سؤال لماذا يحتاج الإصدار 64 بت من Windows إلى مجلد "ملفات البرامج" (x86) المنفصل؟


وأنا أعلم أنه في إصدار 64 بت من نظام التشغيل Windows ، يكون مجلد "ملفات البرامج" مخصصًا لبرامج 64 بت ، بينما يكون المجلد "ملفات البرامج (x86)" مخصصًا لبرامج 32 بت ، لماذا هذا ضروري؟

حسب "ضروري" ، لا أقصد "لماذا لم تكن مايكروسوفت قد اتخذت أي قرارات تصميمية أخرى؟" لأنه بالطبع يمكن أن يكون. بدلاً من ذلك ، أعني ، "لماذا ، نظراً للتصميم الحالي لنظام Windows ذي 64 بت ، يجب أن تحتوي البرامج ذات 32 بت على مجلد مستوى أعلى منفصل من برامج 64 بت؟" بعبارة أخرى ، "ما من شأنه أن يخطئ إذا قمت بطريقة ما بتجنب آلية إعادة التوجيه وأجبرت كل شيء على التثبيت إلى الحقيقي C:\Program Files\؟ "

هناك الكثير من الأسئلة حول Super User وفي أي مكان آخر تؤكد أن "واحد هو برامج 32 بت ، واحد لبرنامج 64 بت" ، ولكن لا شيء يمكنني أن أجد السبب. من تجربتي ، لا بدا لتحديد ما إذا تم تثبيت برنامج 32 بت في المكان الصحيح أم لا.

هل يقدم Windows بطريقة ما نفسه بشكل مختلف لبرنامج ينفد من "Program Files (x86)"؟ هل هناك وصف يوضح بالضبط ما هو مختلف لبرنامج مثبت في "Program Files (x86)" بدلاً من "Program Files"؟ أعتقد أنه من غير المحتمل أن تقوم Microsoft بتقديم مجلد جديد بدون سبب تقني شرعي.


175
2018-06-27 17:19


الأصل


بدلاً من الإجابة عن سؤالك ، أود أن أسأل - كيف تتعامل مع الملفات \ الملفات \ الملفات الشائعة؟ - sgmoore
الإجابة أحادية الخطوط (وبالتالي تعليق): بما أنه يمكنك تشغيل أي تطبيق بسهولة من أي مجلد دون معرفة بنيته ، فمن الواضح أنه لا يوجد إلزامي سبب هذا الفصل. إنها مسألة ملاءمة لدعم عمليات التثبيت المزدوجة للتطبيقات مع كل من البنيان. في بعض الحالات ، تحدث فرقا لأنها ليست بالضرورة إعادة ترتيب بسيطة. تكمن المشكلة الرئيسية في أن تطبيقات 32 بت لا تستطيع تحميل ملفات 64 بت ، لذا لا يمكنك تثبيت كلا الإصدارين في نفس المكان. البديل الآخر هو وجود مجلدين "بن" لكل تطبيق. - Sklivvz
Synetech حتى أنني قمت بتثبيت برامج تحت (x86) فقط للحصول على x64 ثنائيات .. إنه أمر مروع في بعض الأحيان. - sinni800
لقد تساءلت دائمًا لماذا لم تضع Microsoft برامج 64 بت في "Program Files (x64)" بدلاً من نقل مجلد "Program Files" القديم إلى Program Files (x86) - LawrenceC
الفوضى الحقيقية حول التمايز 64 / 32bit هي أن / Windows / System32 يحتوي على 64 بت ، بينما يحتوي Windows / SysWOW64 على 32 بت ... - poke


الأجوبة:


إجابة مختصرة: لضمان استمرار استخدام تطبيقات 32 بت القديمة بالطريقة نفسها التي اعتادوا عليها دون فرض القواعد القبيحة على تطبيقات 64 بت التي من شأنها أن تخلق فوضى دائمة.

ليست ضرورية. إنها أكثر ملاءمة من الحلول الممكنة الأخرى مثل تتطلب كل تطبيق لإنشاء طريقه الخاص لفصل DLLs 32 بت والملفات التنفيذية من DLLs 64 بت والملفات التنفيذية.

السبب الرئيسي هو جعل التطبيقات 32 بت التي لا تعرف حتى أنظمة 64 بت موجودة "فقط العمل" ، حتى إذا تم تثبيت DLL 64 بت في أماكن قد تبدو التطبيقات. لن يتمكن تطبيق 32 بت من تحميل ملف DLL ذي 64 بت ، لذلك كانت هناك حاجة إلى طريقة للتأكد من أن تطبيق 32 بت (والذي قد يكون قبل نظام 64 بت ، وبالتالي ليس لديه أي ملفات 64 بت حتى وجدت) لن تجد DLL 64 بت ، في محاولة لتحميله ، تفشل ، ثم قم بإنشاء رسالة خطأ.

أبسط حل لهذا هو أدلة منفصلة باستمرار. حقا البديل الوحيد هو أن تطلب كل تطبيق 64 بت "إخفاء" ملفاتها التنفيذية في مكان ما لن تبدو تطبيق 32 بت ، مثل bin64 دليل داخل هذا التطبيق. لكن ذلك من شأنه فرض قبح دائم على أنظمة 64 بت فقط لدعم التطبيقات القديمة.


89
2018-06-27 18:18



لم يكن لديهم للقفز من خلال هذه الأطواق للسماح لبرامج 32 بت و 16 بت على نفس النظام. لا أذكر من أي وقت مضى رؤية ProgramFiles (16)أو بعض بالإضافة إلى ذلك ، كيف بالضبط برنامج 32 بت "العثور على DLL 64 بت ثم محاولة تحميل"؟ ما هي البرامج تذهب حول الصيد ل DLLs عشوائي في %programfiles%؟ إذا كان DLL مشترك ، فإنه يذهب في WinSxS. إذا لم تتم مشاركتها ، فذلك متروك للمبرمج لإدارة ملفات DLL الخاصة بها. الجزء المتعلق به يتم القيام به كوسيلة راحة للمبرمجين معقولة رغم ذلك. - Synetech
IIRC Win3.1 لم يكن لديك دليل ملفات البرنامج (أو معظم التطبيقات تجاهلها) ؛ نتيجة لذلك لن يكون هناك أي تطبيقات win16 قديمة تبحث عن الأشياء في ملفات البرنامج لتبدأ. وبدلاً من ذلك ، كانت المكتبات المشتركة IIRC غالبًا في مكان ما في مجلد النوافذ نفسه. Win32 وجود windows \ system و windows \ system32 هو قطعة أثرية من ذلك. - Dan Neely
Windows 3.1 لم يدعم أسماء الملفات الطويلة ، لذا لن يكون قادراً على وجود مجلد "ملفات البرنامج". - Darth Egregious
@ JarrodRoberson: على العكس تمامًا ، يرجع ذلك إلى أن Microsoft تعيد التوافق إلى حد كبير للغاية. - David Schwartz
@ Jarrod: في الواقع ، كما يعرف كل مطوّر برامج ، تعيد Microsoft التوافق إلى الخلف جدا إلى حد كبير. حرفيا كل API لديهم طرق تراث يرفضون إزالتها ، وغالبا جدي يرفضون إصلاح ، لأنهم يخافون من كسر البرامج القديمة التي كانت مكتوبة لتلك API. وينطبق الشيء نفسه على معظم واجهات برمجة التطبيقات ، ولكن ليس في أي مكان بالقرب من أجهزة مايكروسوفت. - BlueRaja - Danny Pflughoeft


يسمح لك بتثبيت كل من الإصدار 32 بت و 64 بت من تطبيق دون الكتابة فوق نفسها.


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

أنا لا أعمل لشركة مايكروسوفت وليس لدي أي فكرة عن ما حقيقة السبب وراء هذه المجلدات ، ولكن أعتقد أن سبب وجود هذه المجلدات واضح جدا بحيث لا توجد مشكلة في القول.

لذلك دعونا كسرها!

  1. المجلدات هي رائعة!

    دعونا نتفق على شيء ما. المجلدات هي رائعة! نحن لا نحتاج إليها ، لدينا أسماء ملفات كافية لوضع كل ملف على جذر القرص الصلب ، فلماذا لديك مجلدات على الإطلاق؟

    حسنًا ، فهم يساعدوننا في طلب أشياءنا. وترتيب الاشياء امر رائع. يساعدنا على معالجة الأشياء بسهولة أكبر. هذا مفيد بشكل خاص عند العمل مع جهاز يتطلب بنية.

  2. فصل البيانات والمنطق أمر رائع!

    نموذج في كثير من الأحيان وجدت في البرمجة ، هو فصل البيانات من المنطق. تريد جزء واحد ذلك يعرف ماذا لفعل شيء ما وتريد جزء آخر لك يمكنه فعل شيء ما مع


65
2018-06-27 17:31



هل هذا هو السبب الأصلي ، على الرغم من؟ لا يمكنني فقط تثبيت التطبيق على C:\Program Files\App32 و C:\Program Files\App64؟ - Stephen Jennings
@ StephenJennings: ولكن هذا يتطلب منك اتخاذ القرار يدويًا. الطريقة التي تعمل بها الآن هي أن العملية تلقائية ، لأن Windows يعرف المجلد المطلوب توفيره عند استدعاء التطبيق SHGetSpecialFolderPath لتحديد موقع التثبيت. - Der Hochstapler
Synetech: لماذا التثبيت في %PROGRAMFILES% في المقام الأول؟ لماذا لا تضع الإصدار 32bit على سطح المكتب للمستخدمين و 64 بت في سلة المهملات؟ فقط لأنه يمكن القيام به ، لا يعني أنها فكرة جيدة. عذرا ، أنا لا أتبع المنطق الخاص بك. - Der Hochstapler
Synetech: نعم ، لقد أعطيت مثالًا جيدًا تمامًا لكيفية القيام بذلك. مثال جيد آخر على كيفية القيام به هو الطريقة هو في الواقع يجري في الوقت الحالي. ببساطة كتابة ملف إلى٪ PROGRAMFILES٪ والتأكد من أن الأمر سينتهي في المجلد الصحيح شيء واحد. التحقق لنفسك أي مجلد هو صيح واحد هو آخر. إذا كنت لا ترى فائدة النهج السابق ، فلن أتمكن من إقناعك. كان السؤال لماذا هناك 2 مجلدات. أعتقد أن إجابتي معقولة للغاية في هذا الصدد. - Der Hochstapler
OliverSalzburg، No quite. السؤال هو لماذا يوجد مجلدان مطلوبليس لماذا هناك هي. في الواقع ، حتى أنه جريء: لماذا هذا ضروري؟ أنت لم توضح سبب ذلك ضروري والمثال الذي أعطيته (وحتى مثال السخرية الخاص بك) فقط أظهر أنه لا يفعل ذلك يملك يجب القيام به على ما هو عليه. - Synetech


TL، DR:

لتلخيص ، لا ، ليس كذلك ضروري. هم استطاع استخدام مجلد واحد ، ولا ، لا يقدم Windows نفسه بشكل مختلف عن برنامج يتم تشغيله من موقع أو آخر.


حسنا ، يبدو أن الجميع يلقون بآرائهم حول هذا ، لذا سأرمي في 2 ¢. آخرون قد تخمين بالفعل على الأسباب ل لماذا ا اختارت Microsoft إنشاء مجلدات منفصلة من المستوى الأعلى للإصدارات 32 بت و 64 بت من البرامج ، لذلك سأترك هذا الجزء (كان السبب الأفضل هو تفسير ديفيد أنه مناسب للمبرمجين). وبالطبع حتى ذلك الحين ، فإنه لا يعالج السؤال المباشر لماذا هذا ضروري؟، والتي يفترض أن الجواب: ليست كذلك.

بدلاً من ذلك ، سوف أخاطب الجزء الرئيسي من السؤال

هل يقدم Windows بطريقة ما نفسه بشكل مختلف لبرنامج ينفد من "Program Files (x86)"؟

ليس حقا ، ولكن موقع البرنامج يستطيع تؤثر على السلوك ، ولكن ليس بالطريقة التي تفكر بها.

عند تشغيل أحد البرامج ، يقوم Windows بإعداد بيئة لتشغيله (أعني من حيث الذاكرة والعنونة وما إلى ذلك وليس فقط متغيرات البيئة). تعتمد هذه البيئة على محتويات الملف القابل للتنفيذ (تختلف برامج 32 بت و 64 بت داخليًا). عند تشغيل برنامج 32 بت على نظام 64 بت ، يتم تشغيله في النظام الفرعي 32 بت الذي يحاكي بيئة 32 بت. يدعي WOW64 (WoW64 لتقف عليه ويندوز على ويندوز 64 بت) وتشبه كيفية تشغيل التطبيقات ذات 16 بت في XP باستخدام NTVDM.

عندما تقوم بتشغيل برنامج مع أو بدون امتيازات المسؤول ، فإنه يؤثر على كيفية تشغيله ، ولكن الموقع ينبغي لا تؤثر عليه (على الرغم من وجود بعض الأمثلة على تبعية الموقع مثل بعض برامج التشغيل على سبيل المثال).

(أستخدم جهاز كمبيوتر مختلفًا ، لذا لا يمكنني الاعتماد على سجل المتصفح الخاص بي للتراجع عن خطواتي ، ولكن في اليوم الآخر أثناء الإجابة هذا سؤال سو انتهى بي الأمر في هذا سؤال SO مما تسبب لي Google PROCESSOR_ARCHITEW6432مما يؤدي إلى هذا سؤال SO و هذا بلوق بلوق مايكروسوفت.)

في مكان ما على طول الطريق ، وأنا أقرأ مشاركة StackOverflow عن كيفية المتغير envirnoment %processor_architecutre%  يعطي نتائج مختلفة حسب المكان الذي تقوم بتشغيل موجه الأوامر منه (سأحاول العثور على اقتباس دقيق).

تحولت الإجابة لتكون مستحقة سواء تم تشغيل الإصدار 32 بت أو 64 بت من موجه الأوامر (أي من System32\ أو SysWoW64\). وبعبارة أخرى ، في حين أن الموقع يبدو ان يؤثر على سلوك البرنامج ، لأنه فقط بسبب وجود إصدارات مختلفة من البرنامج ، ليس لأن Windows يعامل المجلد بطريقة خاصة.

هذا منطقي لأن محتويات الملف القابل للتنفيذ تملي ما إذا كانت 32 بت أو 64 بت ، لذا يمكنك وضع كل من نسخة 32 بت و 64 بت من نفس البرنامج (على سبيل المثال ، foobar32.exe و foobar64.exe) في نفس المجلد وعند تنفيذها ، سيتم تحميلها بشكل صحيح (سيتم تشغيل الإصدار 64 بت بشكل أصلي وسيتم تشغيل الإصدار 32 بت في طبقة مضاهاة WoW64).

FreePascal يسمح لك بتثبيت كل من إصدارات DOS و Windows ويذهب في نفس المجلد: %programfiles%\FreePascal. يدير المعماريات المختلفة عن طريق حفظ الملفات القابلة للتنفيذ (.exe، .sys، .dll، .ovr، وما إلى ذلك) في مجلدات منفصلة ومشاركة ملفات الموارد مثل الصور وملفات المصدر ، وما إلى ذلك) لا يوجد سبب تقني أنه لا يمكن القيام بذلك أيضًا للإصدارات 32 و 64 بت من البرنامج. مثل ديفيد قال ، إنه من الأسهل للمبرمج إذا تم إبقاؤه منفصلاً (أي باستخدام المتغيرات لجعلها تبدو وكأنها هناك مجموعة واحدة فقط من الملفات ، إلخ.)


15
2018-06-27 19:23



الانتقام من التصويت! Muahahaha! تنهد - Synetech
تسجيلي الغريب: \. راجع للشغل جيد شرح +1. - avirk


سبب آخر هو أن معظم البرامج المستخدمة في استخدام المتغيرات البيئية مثل٪ PROGRAMFILES٪ للإشارة إلى مكان تثبيت البرنامج الخاص بهم. لبرامج 64 بت ، فإنه يذهب إلى المكان الطبيعي. بالنسبة لبرامج 32 بت ، ستقوم بإعادة توجيه ذلك إلى البرامج الجديدة Program Files (x86) مجلد.

على الرغم من ذلك ، على الأقل مع الأشياء .Net الجديدة في Visual Studio ، لديهم الآن المتغير App.Local الذي يلغي الحاجة الكاملة لهذا.


11
2018-06-27 17:36



هذا لا يفسر ذلك. من الذي يستخدم بالضبط متغير البيئة ولماذا يهتم إذا كان البرنامج 32 بت أو 64 بت؟ - Synetech
Synetech - يستخدم مؤلف البرامج متغير البيئة. أما السبب في أنها تهتم هو بسبب إشارات إلى dlls. لا يمكنك تحميل dll 32 بت ضمن عملية 64 بت والعكس بالعكس. - Ramhound
وكيف %programfiles%، %programfiles(x86)%أو %programw6432% تحدث فرقا هناك؟ أي DLLs المشتركة انتقل إلى الدليل WinSxS واحد وهو أي DLLs غير مشتركة هناك حق مع الملف القابل للتنفيذ. هذا يهم فقط إذا كان لديك إصدارات 32 بت و 64 بت من نفس البرنامج لسبب ما ، ومن ثم ، يمكنك الاحتفاظ DLLs 32 بت مع الملف التنفيذي 32 بت و DLL 64 بت برنامج 64 بت قابل للتنفيذ. يمكنك فعل ذلك كما يلي: %programfiles%\CoolApp\bin\32 و٪ programfiles٪ \ CoolApp \ bin \ 64` ، لماذا مجلدات المستوى الأعلى منفصلة؟ - Synetech
تضمين التغريدة ردًا علىSynetech ٪ programfiles٪ تم منذ فترة. إذا قمت بتثبيت برنامج 32 بت على كمبيوتر 64 بت ، فإن وجود مكان واحد قد يتسبب في حدوث مشكلات في تطبيق 32 بت هذا. WoW على الرغم من أنه يمكن إعادة توجيه٪ programfile٪ إلى الإصدار (x 86) لتطبيقات 32 بت و الإصدار x 86 لـ 64. - Andy
أعتقد أن الناس لن يكونوا مرتبكين ، إذا لم يكن هناك إعادة توجيه ضمني - kommradHomer


كان حل Microsoft لهذا النقل من 32 بت إلى 64 بت هو إضافة دعم قديم لمعظم تطبيقات 32 بت. بمعنى آخر ، تعمل معظم تطبيقات 32 بت في بيئة التشغيل 64 بت. ضع في اعتبارك أن أنظمة التشغيل الأخرى التي تعمل على بنية 64 بت لا يمكنها تحميل أو تشغيل تطبيقات 32 بت على الإطلاق.

للمساعدة في جعل عملية النقل أسهل ، قامت Microsoft بتعيين أن كافة تطبيقات 32 بت ، يجب أن يتم تحميلها بشكل افتراضي في مجلد Program Files (x86) بدلاً من أن يتم خلطها مع تطبيقات true 64-bit في المجلد Program Files العادي.

مصدر 

"ما الذي قد يحدث خطأً إذا قمت بطريقة ما بتجنب آلية إعادة التوجيه وأجبرت كل شيء على التثبيت إلى C: \ Program Files \؟" 

لا شيئ. دلائل البرنامج اثنين فقط للمؤسسة ، أو للاحتفاظ بالبرامج التي لها إصداران إصدار منفصل 32 بت و 64 بت منفصل ، مثل Internet Explorer. ولكن يمكنك تثبيت برنامج 32 بت في "Program Files" وبرنامج 64 بت في "Program Files x86" ولن يحدث أي شيء سيقوم البرنامج بتشغيل نفسه.

ويكي يقول:

يرفض بعض مثبتات التطبيق المسافات داخل موقع مسار التثبيت. بالنسبة لأنظمة 32 بت ، يكون الاسم المختصر لمجلد Program Files هو PROGRA ~ 1. بالنسبة للأنظمة 64 بت ، يكون الاسم المختصر لمجلد Program Files ذي 64 بت هو Progra ~ 1 (كما هو الحال في أنظمة 32 بت) ؛ بينما الاسم القصير لمجلد ملفات البرامج (x86) ذو 32 بت هو الآن PROGRA ~ 2.


8
2018-06-28 16:28



الكالينجيون. مقال جميل. التعليقات على هذه المادة تبدو سليمة تمامًا كتلك الموجودة هنا. والأسوأ من ذلك ، أن هذه المقالة كانت منذ أكثر من عامين ، والتي تظهر فقط أن هذا السؤال ليس جديدًا وإذا لم يكن بالإمكان الإجابة عليه بشكل رسمي ، فعندئذ أعتقد أنه لن يحدث أبدًا (ما لم يكن هناك شخص ينتمي إلى فريق Windows). حسناً ، أفترض أننا يجب أن نتوقف عن القلق وأن نتعلم كيف نحب القنبلة ، أعني أن أعيش معها. +1 للإشارة إلى المقالة وإظهار أن هذا السؤال كان موجودًا منذ فترة طويلة. - Synetech
Synetech شكرا! نعم ، الفكرة وراء وضع رابط المقالة هي نفسها التي حصلت عليها. هذا سؤال وقت قديم جدًا ولكن IDK لم يتمكن الناس من الحصول عليه حتى الآن. ومع ذلك يجب على MS كتابة KB أو وثائق لهذه المشكلة :) - avirk
نعم ، يجب عليهم ، لا سيما أنهم ليسوا فقط مطورين يسألون ، حتى المستخدمين العاديين يتساءلون عن ذلك. لسوء الحظ ، لا تكون وثائق Microsoft جيدة كثيرًا. - Synetech
Synetech yup! تمتص وثائق MS معظم الوقت. ولكن نعم لقد كتبوا بعض المقالات الجيدة وأنا متأكد من أنهم محصنون ؛) - avirk


والسبب في ذلك هو جعل ترقية برنامج إلى 64 بت أسهل للمطورين. ليس لديهم كتابة أي تعليمات برمجية مخصصة للتحقق من البرنامج في دليل واحد عند التحويل البرمجي في وضع 32 بت وفي دليل آخر عند التحويل البرمجي في وضع 64 بت؛ انهم فقط تحقق C:\Program Filesوعند التشغيل تحت وضع 32 بت ، يتم تغيير هذا تلقائيًا إلى C:\Program Files (x86) من قبل 64 بت ويندوز. وبالمثل ، يتم عزل إدخالات التسجيل بين برامج 32 بت و 64 بت.

هذا يمنع حدوث تعارضات من المطورين غير المعروفين الذين يغيرون طريقة تجميعهم إلى 64 بت دون وضع الكثير من التفكير فيها ، ويمنع عملًا هائلاً للمطورين الذين يريدون أن يتمكن المستخدمون من تثبيت إصدارات 32 و 64 بت من البرنامج في وقت واحد.


ولكن لماذا يريد أي برنامج السماح بتثبيت الإصدارين في وقت واحد؟ مثال واحد: Photoshop و IE بهما ملحقات هي dll الأصلية. لا يمكن أن يكون لديك كود 32 و 64 بت مختلط في نفس العملية ، لذلك لا يمكن استخدام الملحق للإصدار 32 بت مع الإصدار 64 بت ، والعكس صحيح. وهكذا ، فوتوشوب / آي إي يملك للسماح بتثبيت كلا الإصدارين ، أو المخاطرة بخرق قاعدة ضخمة من الإضافات الموجودة.


6
2018-06-27 18:48



+1 على الأقل تناولت السؤال الأساسي حول سبب امتلاك المستخدمين العاديين للإصدارين. - Synetech


البرامج التي يتم تشغيلها على "ملفات البرامج (x86)" تستخدم WOW64 النظام الفرعي (Windows 32 بت على Windows 64 بت هو مجموعة من برامج التشغيل وواجهة برمجة التطبيقات التي تنوي تشغيل تطبيقات x32 عبر نظام هندسة x64):

يتضمن النظام الفرعي WoW64 طبقة توافق خفيفة الوزن   يحتوي على واجهات مماثلة على كافة إصدارات 64 بت من Windows. انها تهدف الى   إنشاء بيئة 32 بت يوفر الواجهات المطلوبة   تشغيل تطبيقات Windows غير معدل 32 بت على نظام 64 بت.   من الناحية الفنية ، يتم تنفيذ WoW64 باستخدام ثلاث مكتبات الارتباط الديناميكي   (دلس):

  • Wow64.dll ، الواجهة الأساسية إلى Windows NT kernel يترجم بين مكالمات 32 بت و 64 بت ، بما في ذلك المؤشر والاستدعاء   التلاعب المكدس
  • Wow64win.dll ، والذي يوفر نقاط الإدخال المناسبة لتطبيقات 32 بت
  • Wow64cpu.dll ، والتي تعتني تبديل المعالج من وضع 32 بت إلى 64 بت

يحتاج نظام 64 بت إلى "محاكاة" 32 بت ، وهذا هو السبب في حاجة Windows إلى "فصل" مجلدي ملفات البرنامج.


5
2018-06-27 17:32



ولكن لماذا يجب وضعها في مجلدات مختلفة؟ Windows بالفعل قادر بشكل كامل على تحديد بنية الملف القابل للتنفيذ بالنظر إلى رأس PE. لماذا لا يمكن تحميل البيئة المناسبة عند تحميل الملف القابل للتنفيذ؟ - Synetech
أعتقد أنه مجرد خيار من مايكروسوفت لإظهار للمستخدمين بسهولة البنية التي يريدونها من إصدارين من البرنامج عند فتح البرنامج. أعني ، إذا لم يكن هناك هذين المجلدين وإذا كان شفافًا للمستخدمين (إذا تم التبديل تلقائيًا) ، فلن يعرفوا ما إذا كانوا يشغلون تطبيق 32 أو 64 بت ، حتى لو كانوا لا يعرفون أي برنامج سيتم فتحه إذا كان يعمل على 64 بت .. - Diogo
الإصدار 64 بت من IE لديه سمعة لكونه فظيع. - Samuel Edwin Ward
توصي MS باستخدام office32 ما لم تكن تعمل مع مجموعات بيانات كبيرة بما يكفي لتجاوز قيود الذاكرة. وأعتقد أن الحاجة إلى إعادة تجميع أدونس ثنائي للعمل مع office64. جنبا إلى جنب مع عدم إعطاء أي فوائد في حالات الاستخدام العادي هو وراء القرار. - Dan Neely
أعتقد أنك ستجد أن برنامج 64 بت مثبت بشكل صريح في المجلد Program Files (x86) سيعمل بشكل طبيعي (وفي معظم الحالات ، والعكس بالعكس). لا يستخدم Windows موقع المجلد لتحديد كيفية التعامل مع الملف التنفيذي. - Harry Johnston


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

لقد أجريت قدرًا كبيرًا من الأبحاث ، واستنتجت النتيجة التالية ، والتي أعتقد أنها دقيقة:

  • لا يوجد فرق عند تخزين التطبيق. في وقت التشغيل ، سيحدد Windows ما إذا كان التطبيق هو 32 بت أو 64 بت ويستخدم تلقائيًا قسم DLL و التسجيل المناسب.

يحدث هذا تلقائيًا ، وهو مستقل عن مكان تخزين التطبيق. لا توجد سرعة أو اعتمادية أو فائدة وظيفية أخرى لوجود مجلدات منفصلة 32 بت و 64 بت.

السبب الوحيد للفصل الافتراضي إلى مجلدين ("ملفات البرنامج" و "ملفات البرامج (x86)") هو أنه إذا كان لديك إصداران من نفس البرنامج (إصدار 32 بت و 64 بت) ، فإنه يوفر طريقة بسيطة للحفاظ على تداخل الملفات منفصلة. حتى في هذه الحالة ، طالما كانت جميع أسماء الملفات فريدة من نوعها ، يمكن أن تكون موجودة بالفعل في نفس المجلد دون أي عواقب.

هناك تحذير إلى الاستنتاج أعلاه ، وهذا هو واحد من تطبيقات مشفرة بشكل سيئ. إذا كان التطبيق يحتوي على أي مسارات مضمنة في داخله ، فسيستخدم هذا المسار فقط. كقاعدة عامة ، لا يجب أبداً أن يتم ضم المسارات إلى تطبيق ، ولكن أحيانًا ما يقوم المبرمج بهذا الخطأ. في هذه الحالة ، سيستخدم البرنامج مسار hardcoded. لن يؤثر الدليل الذي تم فيه تثبيت التطبيق على المكان الذي يبحث فيه بالفعل عن الملفات.


5
2017-10-16 19:57





وجود مجلدات منفصلة يجعل من الممكن للحفاظ على التطبيقات الأصلية 64 بت و thos التي تتطلب WOW64 بعيدا، بمعزل، على حد.

هذا يمكن أن يكون مفيدا - كما OliverSalzburg وأشار بالفعل - إذا كنت ترغب في تثبيت كل من 64 بت و 32 بت من متصفح الويب (على سبيل المثال) ، لأن بعض المكونات الإضافية والوظائف الإضافية قد لا تتوفر إلا لأحد هذين المتصفحين.

الاضطرار إلى فصل المجلدات يجعل هذا الفصل تلقائيباستخدام تقنيات مثل إعادة توجيه التسجيل.

لنفترض أن أحد المثبتات يحاول تحديد مجلد ملفات البرنامج عن طريق قراءة السجل باستخدام ، على سبيل المثال ، RegQueryValueEx.

في أي حال ، فإنه يحاول قراءة مفتاح التسجيل

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion

والتي تشير عادة إلى C:\Program Files.

ومع ذلك ، إذا كان المثبت تطبيق 32 بت ، سيؤدي إعادة توجيه التسجيل إلى مفتاح regitry

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion

أن تقرأ بدلا من ذلك ، وهو ما يشير عادة إلى C:\Program Files (x86).

لماذا هذه بصفة خاصة يمكن استخدام أسماء المجلدات فقط من قبل الأشخاص الذين قاموا بهذا الاختيار. يمكنك دائمًا تغيير أسماء المجلدات الافتراضية إذا كنت ترغب في ذلك.

هل يقدم Windows بطريقة ما نفسه بشكل مختلف لبرنامج ينفد من "Program Files (x86)"؟

اشك به. يسمح لك معظم المثبتين باختيار مجلد تثبيت مخصص ، لذلك لا يهم أين يتم تثبيت البرنامج.


3
2018-06-27 18:40



عذرا أنا مختلطة "تصريح" مع "معاذ" - Wernfried Domscheit


لا أستطيع أن أصدق الارتباك هنا .. أولا أنا مطور بدوام كامل.

فعلت MS هذا لحل الحالة حيث يتم استخدام DLL من قبل كل من تطبيقات 32 بت القديمة والتطبيقات 64 بت الجديدة. لا يمكن تغيير الطريقة القديمة (System32 ، ملفات البرامج ، إلخ) لأن ذلك سيؤدي إلى تعطيل البرامج القديمة التي لا يمكن إعادة تجميعها.

لذا أنشأت MS مجلدًا لتخزين 64 بت من البرامج والجمعيات والمكتبات بحيث يمكن ربط البرامج الجديدة بالمكتبات المناسبة ، وستستمر البرامج القديمة في العمل بشكل طبيعي.

كما هو الحال ، يمكن أن تتعايش ملفات .Net DLL مع إصدارات أخرى على نفس الجهاز. على سبيل المثال ، يمكن أن يكون لديك Library.1.0.1 ، Library.1.0.2 ، مكتبة 1.1.0 ، إلخ. وهذا فقط لحجم بت محدد (32 أو 64). إذا لم يتم استخدام مجلدات منفصلة ، فكل مجموعة تحتاج إلى إصدار 32 بت و 64 بت. سيؤدي ذلك إلى حدوث فوضى شديدة في دليل يحتوي بالفعل على إصدارات متعددة من نفس التجميع.

هذا هو كل الاشياء المطور. باعتباري مستخدمًا ، لا بد لي من التعامل معه فقط عندما أعمل مع برنامج 32 بت على Windows 7 64. وأنا أفضل امتلاك القدرة على تشغيل إصدار 32 بت ونفس التطبيق في 64 بت كذلك. عندما أعمل على تطبيق 32 بت أحتاج إلى ترجمة في 64 بت ، كل ما أفعله هو إخبار المترجم بذلك. أسماء Dll وكل شيء آخر يبقى على حاله.

السبب غير موجود في نظام التشغيل Windows 95/98 هو أن تلك الأنظمة تحاكي وقت التشغيل 32 بت. لم يكن نظام تشغيل أصلي 32 بت. انها تزييت تنفيذ 32 بت بشيء يدعى "thunking".

هنا تعريف جيد: http://searchwinit.techtarget.com/definition/thunk


3
2018-06-28 14:43



كيف 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` أو \blah\32. في كلتا الحالتين ، يتم فصلهم. إذا كان هناك أي شيء ، فإن الطريقة الحالية تفصل مكونات التطبيق (وتكررها أيضًا دون داعٍ نظرًا لاستخدام بعض التطبيقات CommonFiles للموارد ومثل هذا. الى جانب ذلك ، يمكنك جعل الصوت يبدو كما لو أن التطبيقات تفريغ DLLs الخاصة بهم في دلو مشترك. من السهل بدرجة كافية الاحتفاظ بملفات DLL ذات 32 بت الخاصة بالتطبيق من خلال ملفات ex-32-bit وملفات DLL ذات 64-بت مع exes 64-bit. - Synetech
أوه ، وبالنسبة لـ95/98 ، من قال أي شيء عن ذلك؟ كان حتى XP نظام فرعي 16 بت (NTVDM). - Synetech
اعتقدت أنك تريد تفسيرا بعض التطبيقات تستخدم CommonFiles؟ لدي 35 تطبيقًا مختلفًا لها مداخل. إنه مكان آمن لتخزين المكونات المشتركة من دليل System32. بيانك أن بعض التطبيقات تستخدم هذا هو قابل للنقاش. نقلا عنك: "لم يكن لديهم للقفز من خلال هذه الأطواق للسماح لبرامج 32 بت و 16 بت على نفس النظام. لا أذكر من أي وقت مضى رؤية ProgramFiles (16) أو بعض مثل [...] الجزء المتعلق به يجري القيام به كوسيلة راحة للمبرمجين على الرغم من معقول ". حسنا ، نعم .. المبرمجين يفعلون. نكتب التطبيقات بعد كل شيء. - Jason Locke
هاه؟ - Synetech
فقط أعيد قراءة هذا .. قاله بشكل أفضل في ردوده - superuser.com/a/442253/142951. إذا لم تكن مطورًا ، فقد لا ترى الغرض. - Jason Locke


ليس من الضروري على الإطلاق. على سبيل المثال على جهاز الكمبيوتر الخاص بي ، أقوم بتثبيت كل تطبيق في المجلد C:\MyPrograms\ من أجل فصلها عن التطبيقات التي تم تثبيتها بواسطة قسم تقنية المعلومات لدينا.

بالطبع ، هذا يمنعني من تثبيت كلا الإصدارين (32 و 64 بت) من تطبيق واحد ، ولكن هذه ليست مشكلة في حالتي.

كلما قمت بتشغيل البرنامج ، ثم دائما أول DLL C:\Windows\System32\ntdll.dll يتم تنفيذ. يحدد هذا DLL ما إذا كان البرنامج الخاص بك هو تطبيق 32 أو 64 بت. اعتمادا على ذلك يتم إعادة توجيهك إلى WoW64 التي ورد ذكرها في عدة إجابات بالفعل.


0
2018-05-08 08:40