الملخص:
في نظام التشغيل Windows 11، هناك تصميم أربك المستخدمين لفترة طويلة: في نظام 64 بت، يقوم C:WindowsSystem32 فعليًا بتخزين ملفات نظام 64 بت، بينما يقوم الدليل C:WindowsSysWOW64 الذي يحمل الرقم "64" في الاسم بتخزين ملفات 32 بت بدلاً من ذلك. بالنسبة للمستخدمين الذين لا يعرفون تاريخ Windows، قد يبدو نظام التسمية هذا معكوسًا تمامًا.
قام مهندسو Microsoft مؤخرًا بشرح الأسباب الكامنة وراء هذا التصميم مرة أخرى. الجواب ليس أن مايكروسوفت ببساطة عكست أسماء الدليل، بل لتجنب كسر الكثير من البرامج التي اعتمدت على المسارات القديمة. عندما تم ترحيل Windows من بنية 32 بت إلى بنية 64 بت، اختار الاحتفاظ باسم دليل System32 المستخدم على نطاق واسع بالفعل، ثم استخدم آلية إعادة توجيه نظام الملفات للسماح لبرامج 32 بت بالوصول تلقائيًا إلى مجموعة أخرى من ملفات النظام.
نشر Windows Last مقالًا بتاريخ 20 أكتوبر 2026، والذي عرض هذه المشكلة وشرح الآلية ذات الصلة بالتزامن مع المستندات الفنية الرسمية لشركة Microsoft. وأشار التقرير إلى أن هذا التصميم يعكس بشكل كامل إصرار ويندوز طويل الأمد على توافق البرامج: حتى لو لم تعد طريقة التسمية القديمة بديهية، طالما أن التعديلات السريعة قد تتسبب في عدم قدرة عدد كبير من البرامج على التشغيل، فإن مايكروسوفت تميل إلى الاحتفاظ بالبنية الأصلية وحل المشكلة من خلال طبقة التوافق.
لفهم هذا التصميم، يتعين عليك العودة إلى الأيام الأولى لنظام Windows.
في عصر Windows 16 بت، تم تخزين ملفات النظام بشكل أساسي في دليل C:WindowsSystem. عندما أطلقت مايكروسوفت نظام التشغيل Windows 32 بت، كان النظام يحتاج إلى دليل جديد لاستيعاب ملفات النظام 32 بت، لذلك تم استخدام C:WindowsSystem32. يرتبط "32" بالفعل ببنية النظام 32 بت في ذلك الوقت.
ولكن عندما ظهر نظام التشغيل Windows 64 بت، أصبحت الأمور معقدة. قام عدد كبير من البرامج ببرمجة System32 في كود البرنامج واستخدم هذا المسار مباشرة للوصول إلى ملفات النظام بدلاً من الحصول على دليل النظام الصحيح ديناميكيًا من خلال واجهة النظام التي يوفرها Windows.
إذا قامت Microsoft بإعادة تسمية System32 مباشرة إلى System64 عند تشغيل Windows 64 بت، فقد لا تتمكن العديد من البرامج القديمة والمثبتات والبرامج النصية الدفعية من العثور على ملفات النظام التي تحتاجها. حتى إذا قام المطورون بإعادة ترجمة البرنامج، فقد لا يتمكنون من إصلاح جميع المسارات المشفرة في الوقت المناسب.
والأمر الأكثر إزعاجًا هو أن بعض البرامج لا تزال تقرأ مكونات النظام المقابلة من System32 افتراضيًا بعد ترقيتها إلى إصدار 64 بت. إذا قامت Microsoft بتغيير System32 لتخزين ملفات 32 بت فقط، فلن تتمكن برامج 64 بت هذه من تحميل مكتبات الارتباط الديناميكي المطلوبة بشكل طبيعي.
لذلك، قررت Microsoft أخيرًا الاحتفاظ بالاسم التاريخي System32 والسماح لها بتخزين الملفات التي تتوافق مع البنية الأصلية لنظام التشغيل في Windows 64 بت. بالنسبة للإصدار السائد x64 من نظام التشغيل Windows 11، فهذا يعني أن System32 يقوم بتخزين الإصدار 64 بت من مكونات النظام، بينما يتم وضع الإصدار 32 بت في دليل آخر.
هذا الدليل هو SysWOW64.
WOW64 هو اختصار لـ "Windows 32 بت على Windows 64 بت"، وهي آلية توافق لتشغيل تطبيقات Windows 32 بت على Windows 64 بت. يشير الرقم "64" في SysWOW64 إلى بيئة Windows 64 بت الموجودة فيه، وليس أن الملف نفسه هو 64 بت. بمعنى آخر، يصف الاسم النظام الأساسي الذي تستهدفه آلية التوافق، وليس عدد البتات في الملف الثنائي في الدليل.
أوضح ريموند تشين، كبير مهندسي مايكروسوفت، ذات مرة في مقال فني أن الرقم "32" في System32 أصبح تدريجيًا اسمًا قديمًا تاريخيًا، تمامًا مثل بعض الأسماء التجارية، حتى لو لم تعد تعكس المعنى الأصلي بالكامل، ستظل محفوظة بسبب الاستخدام طويل المدى.
إذا كان من الممكن إعادة تصميم النظام بأكمله، فهو يعتقد أن اسم الدليل الأكثر مثالية قد يكون شيئًا مثل SysExec، والذي يُستخدم لتخزين الملفات القابلة للتنفيذ التي تتوافق مع بنية النظام الحالية. لكن نظام Windows موجود منذ عقود، وكان System32 منذ فترة طويلة مسارًا ثابتًا يعتمد عليه عدد لا يحصى من البرامج، لذا فإن المخاطر المحتملة لتغيير الاسم تفوق بكثير فوائد التسمية.
بالإضافة إلى تسمية الدليل، يحتاج Windows 64 بت أيضًا إلى حل مشكلة أكثر عملية: لا يمكن لبرامج 32 بت تحميل مكتبات الارتباط الديناميكي 64 بت مباشرة، ولا تستطيع برامج 64 بت تحميل مكتبات الارتباط الديناميكي 32 بت مباشرة.
على سبيل المثال، يعد kernel32.dll مكونًا مهمًا لنظام Windows. يمكن العثور على الملفات التي تحمل نفس الاسم في System32 وSysWOW64، ولكن يتم تجميعها لبنيات مختلفة ولا يمكن تبادلها ببساطة. عندما قام Windows Last بفحص هذين الدليلين في نظام Windows 11 26H2، وجد أيضًا اختلافات في حجم الملفات المقابلة.
إذا قام برنامج 32 بت بتحميل الإصدار 64 بت مباشرة في System32، فقد لا يتمكن من التشغيل بسبب البنية الثنائية غير المتوافقة. لتجنب هذا الموقف، قدم Windows معيد توجيه نظام الملفات WOW64.
في نظام التشغيل Windows 64 بت، عندما يحاول برنامج 32 بت الوصول إلى C:WindowsSystem32، يقوم النظام عادةً بإعادة توجيه طلب الوصول تلقائيًا إلى C:WindowsSysWOW64. هذه العملية شفافة بشكل أساسي بالنسبة للبرنامج نفسه، فهو لا يزال يعتقد أنه يصل إلى System32، ويجد نظام التشغيل الملف 32 بت الصحيح له خلف الكواليس.
تنص وثائق Microsoft الرسمية بوضوح على أن دليل System32 في Windows 64 بت محجوز لتطبيقات 64 بت، وأن WOW64 مسؤول عن إعادة توجيه وصول برامج 32 بت إلى بعض مسارات النظام إلى أدلة 32 بت المقابلة.
لا تتضمن هذه الآلية مكتبة الارتباط الديناميكي للنظام فحسب، بل تؤثر أيضًا على بعض أدوات النظام. على سبيل المثال، عندما يصل برنامج 32 بت إلى أدوات معينة في دليل Windows، قد تتم إعادة توجيهه إلى الإصدار المقابل في SysWOW64. وهذا يمنع برامج 32 بت من إساءة استخدام أدوات 64 بت أو إجراء عمليات غير صحيحة إذا كانت بنية نظام التشغيل غير متطابقة.
يعالج WOW64 أيضًا مشكلات التوافق مثل الوصول إلى السجل ومسارات تثبيت البرنامج. بالنسبة لتطبيقات 32 بت، يمكن لنظام التشغيل Windows توفير عرض تسجيل منفصل، والموقع النموذجي هو HKEY_LOCAL_MACHINESoftwareWow6432Node. عادةً ما يقوم النظام أيضًا بتوجيه مسار ملفات البرامج لبرامج 32 بت إلى C:Program Files (x86)، بحيث يمكن إدارة البرامج ذات البنى المختلفة بشكل منفصل قدر الإمكان.
تشكل هذه الآليات معًا جزءًا من نظام التوافق مع Windows، مما يسمح لعدد كبير من البرامج المكتوبة لإصدارات Windows 32 بت المبكرة بمواصلة العمل على نظام التشغيل Windows 11 64 بت، دون أن يضطر المطورون إلى إعادة كتابة كافة التعليمات البرمجية لكل برنامج قديم.
ومع ذلك، يمكن أن تؤدي إعادة توجيه نظام الملفات أيضًا إلى بعض المواقف التي يمكن أن تربك المطورين بسهولة.
على سبيل المثال، موجه الأوامر 32 بت وموجه الأوامر 64 بت، حتى إذا كانا يستخدمان المسار المتطابق ظاهريًا للوصول إلى C:WindowsSystem32kernel32.dll، فقد تكون الملفات الفعلية التي تم الحصول عليها مختلفة. عادةً ما تتم إعادة توجيه الأول إلى SysWOW64، بينما يصل الأخير إلى System32 مباشرةً.
ذكر مات بيتريك، وهو عضو سابق في فريق Microsoft Visual Studio، في مقالة فنية أنه قضى وقتًا أيضًا في استكشاف المشكلة وإصلاحها لأنه حصل على نتائج مربكة عندما قام موجه أوامر 32 بت بإدراج ملفات بنفس الاسم في دليلين. يوضح هذا أنه على الرغم من أن إعادة توجيه نظام الملفات يمكن أن تحافظ على توافق البرامج، إلا أنها تجعل تصحيح أخطاء النظام وعمل التطوير أكثر تعقيدًا.
لحل بعض المواقف الخاصة، توفر Microsoft أيضًا مسارًا افتراضيًا يسمى Sysnative. إذا كان برنامج 32 بت يحتاج حقًا إلى الوصول إلى دليل System32 الأصلي لنظام التشغيل Windows 64 بت، فيمكنه استخدام C:WindowsSysnative لتجاوز إعادة توجيه نظام الملفات المعتادة.
تجدر الإشارة إلى أن Sysnative ليس مجلدًا حقيقيًا على القرص، ولكنه مسار مستعار تم توفيره خصيصًا بواسطة Windows. لا يمكن لتطبيقات 64 بت استخدام هذا الاسم المستعار مثل برامج 32 بت، لذلك عندما يبحث المستخدمون عن Sysnative مباشرة في File Explorer، قد يجدون أن النظام يطالبهم بأن المسار غير موجود.
تدرج Microsoft أيضًا عددًا من أدلة System32 الفرعية التي لا تتأثر بإعادة التوجيه العادية لنظام الملفات، بما في ذلك:
C:WindowsSystem32catroot
C:WindowsSystem32catroot2
C:WindowsSystem32driverstore
C:WindowsSystem32driversetc
C:WindowsSystem32logfiles
C:WindowsSystem32spool
تتضمن هذه الدلائل وظائف مثل دلائل مكونات النظام وتخزين برامج التشغيل وملفات تكوين الشبكة والتسجيل والطباعة. تسرد وثائق Microsoft مسارات الاستثناءات هذه بوضوح، ولكنها لا تقدم شرحًا موحدًا لأسباب التصميم المحددة لكل استثناء. يعتقد Windows Last أن بعض هذه الدلائل قد تحتوي على بيانات تحتاج إلى الوصول إليها بشكل مشترك بواسطة برامج ذات بنيات مختلفة، مثل ملف المضيفين في برامج التشغيل وما إلى ذلك.
بالإضافة إلى النظام الأساسي x64، شهدت آلية توافق Windows على بنية Arm أيضًا تصميمًا مشابهًا متعدد الدلائل.
في بعض أنظمة Windows on Arm المبكرة، تستخدم برامج 32 بت x86 SysWOW64، بينما يمكن لبرامج Arm 32 بت الوصول إلى مكونات النظام المقابلة من خلال SysArm32. نظرًا لأن منصة Arm تحتاج إلى التعامل مع مشكلات التوافق بين بنيات مجموعة التعليمات المختلفة، يستخدم Windows أيضًا آليات المحاكاة والتحويل المقابلة.
ومع ذلك، ذكرت أحدث وثائق تطوير Arm من Microsoft أن Windows on Arm لن يدعم بعد الآن تطبيقات Arm 32 بت، وستتم أيضًا إزالة ثنائيات النظام ذات الصلة من دليل SysArm32. في الوقت نفسه، لا يزال من الممكن تشغيل تطبيقات x86 العادية من خلال آلية التوافق، ويتم دعم بعض برامج x86 بواسطة تقنية محاكاة Prism.
يوضح هذا أيضًا أن نظام التوافق مع Windows ليس ثابتًا تمامًا. مع تغير الأنظمة الأساسية للأجهزة والأنظمة البيئية للبرامج، ستستمر Microsoft في التخلص التدريجي من الدعم لبعض البنى القديمة، ولكن بالنسبة للتطبيقات التي لا تزال مستخدمة على نطاق واسع، ستحاول الشركة الحفاظ على التوافق قدر الإمكان.
من وجهة نظر فنية، فإن تسمية System32 وSysWOW64 ليست في الواقع بديهية بدرجة كافية. بالنسبة للمستخدمين العاديين، من الطبيعي أن يعتقدوا أن ملفات 64 بت مخزنة في الدليل عندما يرون "64". ولكن في نظام التشغيل Windows، تعكس أسماء الدليل التاريخ وليس مجموعة من القواعد المصممة من الألف إلى الياء لمتابعة الحدس.
السبب الأساسي وراء عدم قيام Microsoft بإعادة تسمية الدليلين ببساطة هو التوافق. يحتاج Windows إلى تشغيل الكثير من البرامج التاريخية، وقد تعتمد هذه البرامج على مسارات ثابتة وواجهات نظام قديمة وتخطيطات ملفات ثنائية محددة. قد يؤدي تعديل هذه البنى التحتية بشكل متهور إلى فشل تثبيت البرامج، وحدوث خلل في أدوات النظام، وحتى التأثير على العمليات التجارية التي تعتمد على المكونات القديمة.
لذلك، اختارت Microsoft حل المشكلة من خلال آليات مثل إعادة توجيه نظام الملفات، وإعادة توجيه التسجيل، والمسارات الافتراضية، بدلاً من إعادة بناء نظام تسمية الدليل بالكامل.
هذا التصميم ليس مثاليًا، ولكنه يعكس اختلافًا مهمًا في مسار تطوير Windows وأنظمة التشغيل الأخرى: يحتاج Windows دائمًا إلى إيجاد توازن بين التحديث المستمر والتوافق مع البرامج القديمة لعقود من الزمن. إن التسمية المعكوسة ظاهريًا لـ System32 وSysWOW64 هي أثر نموذجي تركته استراتيجية التوافق طويلة المدى هذه.
التعليقات