شركة كومورا سوفت ذ.م.م.
تواصل معنا
القائمة

هل تعمل تطبيقات الأعمال على Windows بإصدار Arm؟ ── واقع محاكاة x64 (Prism) ومكتبات DLL وCOM الأصليّة

· آخر تحديث: · · Windows on Arm, Arm64, محاكاة x64, التكامل الأصلي, P/Invoke, COM, برامج التشغيل, C#, .NET, تطوير Windows, الاستشارات التقنية

«الحاسوب الجديد الذي سنعتمده الشهر المقبل من نوع يُدعى Copilot+ PC، فهل يعمل عليه نظامنا للأعمال؟» ── مع تزايد اعتماد الشركات لأجهزة الحاسوب المزوَّدة بمعالج Snapdragon، يتلقّى المزيد من شركات التطوير ومسؤولي الأنظمة الداخليّة هذا السؤال. تقول الكتالوجات: «التطبيقات القائمة أيضاً تعمل عبر المحاكاة». لكنّ تطبيق الأعمال الخاصّ بشركتك يستدعي، خلف شاشة C#، مكتبة DLL أصليّة مزوَّدة من طرف ثالث عبر P/Invoke، والتقارير تمرّ عبر مكوّن COM، وفوق ذلك، توجد برامج تشغيل لأجهزة مخصَّصة. والحقيقة أنّه من الصعب الإجابة فوراً عن سؤال «هل يعمل؟».

الجواب أوّلاً: «التطبيق نفسه يعمل في معظم الأحيان. الخطر يكمن في ما يحيط به». فمحاكاة Windows 11 تتولّى شيفرة وضع المستخدم من نوع x86/x64 بدقّة عالية نسبيّاً، في حين يوجد بوضوح «نطاق خارج تغطية المحاكاة» يشمل برامج التشغيل، وامتدادات القشرة، ومزج الأبنية (Architectures) داخل العمليّة الواحدة. وهذا النطاق الخارج عن التغطية هو بالضبط المجال الذي درجت تطبيقات الأعمال على استخدامه.

في هذا المقال، نستعرض آليّة محاكاة Windows on Arm وحدودها، والمبدأ الأساسيّ القاضي بعدم إمكانيّة مزج x64 وArm64 داخل عمليّة واحدة، ومشكلة التركيبات الخاصّة بتطبيقات .NET، وحتّى الخطوات العمليّة للتحقّق من «هل يعمل تطبيق شركتنا على جهاز Arm؟»، في حدود ما يمكن التحقّق منه عبر Microsoft Learn.

1. الخلاصة أوّلاً

  • تعمل تطبيقات .NET المُدارة (Managed) الخالصة، وتطبيقات سطح المكتب العاديّة من نوع x86/x64، تقريباً بالكامل عبر محاكاة Windows 11 بإصدار Arm. المحاكاة مدمجة في نظام التشغيل، ولا تحتاج إلى تعديل التطبيق أو مكوّنات إضافيّة.1
  • تتولّى المحاكاة شيفرة وضع المستخدم فقط. برامج تشغيل وضع النواة لا تُحاكى، وArm64 الأصيل حتميّ لها. كما يجب أن تطابق برامج تشغيل UMDF وبرامج تشغيل الطابعات بنية نظام التشغيل هي أيضاً.23
  • امتدادات القشرة، ومحرّرات الإدخال (IME)، والتقنيات المساعدة (Assistive Technology)، أي «مكتبات DLL تُحمَّل في عمليّات أخرى مثل Explorer»، تحتاج أيضاً إعادة ترجمة (Recompile) إلى Arm64 مطابق للنظام. لا تنجدها المحاكاة.4
  • لا يمكن مزج x64 وArm64 داخل عمليّة واحدة. فعمليّة x64/Arm64EC يمكنها تحميل ثنائيّات x64 وArm64EC فقط، وعمليّة Arm64 يمكنها تحميل ثنائيّات Arm64 فقط. لا يمكن استدعاء DLL من نوع Arm64 من ملفّ exe من نوع x64، ولا العكس.5
  • الآليّتان اللتان تجاوزان هذا القيد في ملفّ واحد هما Arm64EC (شيفرة Arm64 أصيلة يمكن مزجها مع x64 داخل العمليّة نفسها) وArm64X (ثنائيّ يجمع Arm64 وArm64EC في ملفّ PE واحد، ويمكن تحميله في أيّ من العمليّتين). خادم COM داخل العمليّة (In-process Server) أو الإضافة (Plugin) التي تُستدعى من كلا البنيتين هما ميدان استخدام Arm64X.56
  • يدعم .NET رسميّاً Arm64، ويمكن النشر (Publish) الأصيل عبر RID المسمّى win-arm64. لكن عند تشغيل تطبيق AnyCPU على بيئة تشغيل .NET من نوع Arm64، تعمل العمليّة كـArm64، فتحدث مشكلة تركيبيّة وهي أنّ استدعاء مكتبة DLL أصليّة موجودة بصيغة x64 فقط عبر P/Invoke يفشل في التحميل.785
  • يمكن تجهيز بيئة الاختبار، إلى جانب جهاز فعليّ (كـ Copilot+ PC)، عبر جهاز افتراضيّ (VM) من نوع Windows 11 Arm64 على Azure، أو ملفّ ISO لـ Windows 11 Arm64 القابل للاستخدام على Hyper-V فوق جهاز Arm أو جهاز Mac بمعالج Apple Silicon. ※ لا يمكن إنشاء جهاز افتراضيّ Arm64 على Hyper-V الخاصّ بجهاز x64.910

2. ما هو Windows بإصدار Arm ── الحواسيب المزوَّدة بمعالج Snapdragon وPrism

Windows بإصدار Arm هو Windows الذي يعمل على معالجات Arm64. ومنذ عام 2024، أصبح وجوداً لا يسع المطوّرين تجاهله، بعد أن اعتمد الكثير من فئة «Copilot+ PC» ── الفئة الجديدة من حواسيب Windows 11 المزوَّدة بوحدة معالجة عصبيّة (NPU) قادرة على أكثر من 40 تريليون عمليّة في الثانية (40+ TOPS) ── معالجات Snapdragon X المعتمِدة على Arm.1112

ما يدعم التوافق مع التطبيقات القائمة هو المحاكاة المدمجة في نظام التشغيل. وأهمّ نقاط الآليّة هي كالتالي.1

  • يقوم المحاكي بـترجمة JIT لكتل تعليمات x86/x64 إلى تعليمات Arm64، ويخزّن نتيجة التحويل مؤقّتاً (Cache) لكلّ وحدة (Module)، ما يُسرِّع بدء التشغيل من المرّة الثانية فصاعداً.
  • يستطيع Windows 11 محاكاة x86 وx64 معاً. أمّا Windows 10 on Arm فلا يحاكي إلّا x86 فقط، لذا فالحديث عن تطبيقات الأعمال من نوع x64 يفترض عمليّاً Windows 11.
  • في Windows 11 24H2، أُدخل محاكٍ جديد يُدعى Prism، وارتفع الأداء عمّا كان سابقاً وانخفض استخدام المعالج. وPrism مُحسَّن خصّيصاً لمعالجات Qualcomm Snapdragon.
  • تعمل تطبيقات 32bit (x86) على طبقة WOW64 نفسها المستخدَمة في إصدار Windows من نوع x64، وتخضع لإعادة توجيه (Redirection) نظام الملفّات وسجلّ النظام. في المقابل، لا تمتلك تطبيقات x64 طبقة WOW64، ولأنّ الثنائيّات النظاميّة (System Binaries) مُترجَمة بصيغة Arm64X المشروحة لاحقاً، يمكن لتطبيقات x64 الوصول إلى نظام التشغيل ككلّ (نظام الملفّات وسجلّ النظام أيضاً) دون إعادة توجيه.1

معلومات المعالج التي تراها التطبيقات تحت المحاكاة هي معلومات «معالج افتراضيّ محاكى (Emulated Virtual Processor)». وحتّى GetNativeSystemInfo يُعيد قيماً محاكاة حفاظاً على التوافق، فإن أردتَ معرفة ما إذا كان المضيف Arm64 من عدمه، استخدم IsWow64Process2 أو GetMachineTypeAttributes.13

كما يوفّر Windows آليّة لتغيير إعدادات المحاكاة (بإعدادات مسبقة Default/Safe/Strict/Very Strict وإعدادات تفصيليّة فرديّة) من خلال النقر بزرّ الفأرة الأيمن على ملفّ exe ← خصائص ← علامة تبويب التوافق، وذلك للتطبيقات التي تظهر فيها مشكلات مع المحاكاة. هذا ضبط يخفض الأداء في مقابل التوافق، لكنّه يستحقّ التذكّر كمخرج في حالات من نوع «كان يعمل على إصدار سابق من Windows on Arm ولم يعد يعمل».14

3. ما يعمل عبر المحاكاة وما لا يعمل

تتحدَّد الإجابة عن سؤال «هل يعمل؟» بنوع التبعيّات لا بالتطبيق نفسه. نلخّصها في جدول القرار.

التصنيف التعامل على Windows 11 بإصدار Arm السند/الملاحظات
تطبيق وضع المستخدم من نوع x86/x64 (exe + مجموعة DLL من البنية نفسها) يعمل عبر المحاكاة دون تعديل ودون تثبيت إضافيّ1
تطبيق .NET (مُدار) يعمل (والتنفيذ الأصيل لـ Arm64 ممكن أيضاً) راجع الفصل 58
برنامج تشغيل وضع النواة لا يعمل. Arm64 الأصيل حتميّ لا توجد محاكاة في النواة23
برنامج تشغيل UMDF/برنامج تشغيل الطابعة Arm64 مطابق لنظام التشغيل حتميّ حتّى لو عمل التطبيق نفسه عبر المحاكاة، لا يمكن استخدام الميزات المعتمِدة على برنامج التشغيل3
امتداد القشرة/IME/التقنيات المساعدة (DLL تُحمَّل في عمليّات أخرى) إعادة الترجمة إلى Arm64 لازمة مثل قائمة النقر بالزرّ الأيمن في Explorer، وعرض أيقونات التخزين السحابيّ4
تطبيق x86 يحظر توليد الشيفرة الديناميكيّ لا يعمل عبر المحاكاة لأنّ المحاكي يولِّد تعليمات Arm64 وقت التنفيذ، يلزم تخفيف ProcessDynamicCodePolicy4
ألعاب معتمِدة على OpenGL القديم/برامج تشغيل مكافحة الغشّ قد لا تعمل العائق هو OpenGL أحدث من 3.3 أو برامج مكافحة الغشّ غير الداعمة لـ Arm15
الأجهزة الطرفيّة (الطابعة، الماسح، الأجهزة المخصَّصة) تتحدَّد بوجود برنامج تشغيل Arm64 من عدمه يلزم برنامج تشغيل Arm64 مرفَق بنظام التشغيل أو مزوَّد من الشركة المصنِّعة15
برمجيّات مكافحة الفيروسات/البرمجيّات التي «تُغيِّر تجربة Windows» يلزم التحقّق فرديّاً تقدّم دعم Arm لكن يُنصَح بالتحقّق لكلّ منتج على حدة15

بإعادة الصياغة في سياق تطبيقات الأعمال، فإنّ علامات الخطر هي كالتالي.

  • عملاء VPN، وعملاء إدارة الأصول، ومنتجات الأمان ── هي في جوهرها برامج تشغيل نواة. يلزم التحقّق من المزوِّد عن وجود نسخة داعمة لـ Arm64 من عدمه.
  • مصادقة دونجل USB، والأجهزة المخصَّصة (أجهزة القياس وأجهزة الدفع وغيرها) ── يتوقّف مصيرها على توفّر برنامج تشغيل الجهاز بصيغة Arm64.
  • الأدوات التي «تضيف ميزات إلى Explorer» ── لأنّ امتدادات القشرة تُحمَّل في Explorer من نوع Arm64، فلا تعمل إن بقيت بصيغة x64.
  • حتّى إن لم يكن التطبيق نفسه ينطبق عليه هذا، فإنّ الحالات التي يُضمِّن فيها المثبِّت (Installer) برنامج تشغيل (مثل تصدير PDF بطريقة برنامج تشغيل طابعة افتراضيّة) تصادف المشكلة نفسها.

4. لا يمكن مزج البنى داخل العمليّة ── واقع P/Invoke وCOM

منذ عصر 32bit، كانت هناك قاعدة صارمة: «لا يمكن لعمليّة 64bit تحميل DLL من نوع 32bit»16. ولدى Windows بإصدار Arm قاعدة صارمة من البنية نفسها. قواعد إمكانيّة التحميل مُلخَّصة رسميّاً كالتالي.5

بنية العمليّة DLL من نوع x64 DLL من نوع Arm64EC DLL من نوع Arm64 DLL من نوع Arm64X
عمليّة x64 / Arm64EC يمكن التحميل يمكن التحميل غير ممكن يمكن التحميل
عمليّة Arm64 غير ممكن غير ممكن يمكن التحميل يمكن التحميل

الآليّتان اللتان تظهران هنا هما المفتاح للتفكير في تصميم دعم Arm.

  • Arm64EC (Emulation Compatible) هو واجهة تطبيق ثنائيّة (ABI) لشيفرة Arm64 أصيلة تتّبع اتّفاقيّة الاستدعاء (Calling Convention) واستخدام المكدّس (Stack) وتخطيط البيانات الخاصّ بـ x64، بحيث يمكن مزجها داخل العمليّة نفسها مع شيفرة x64 تُنفَّذ عبر المحاكاة. فعندما يعمل تطبيق x64 على Windows 11 on Arm، تكون معظم شيفرة نظام التشغيل المُحمَّلة في تلك العمليّة مُترجَمة بصيغة Arm64EC، وتُنفَّذ بسرعة أصيلة دون أن يعلم التطبيق بذلك. يمكن استخدام هذا في انتقال تدريجيّ: رفع الأداء بتحويل شيفرتك الخاصّة إلى Arm64EC أوّلاً بأوّل، حتّى إن بقيت مكتبات DLL التابعة بصيغة x64.5
  • Arm64X صيغة ثنائيّة تجمع شيفرة Arm64 التقليديّة وشيفرة Arm64EC في ملفّ PE واحد. وبما أنّها تتصرّف كـDLL من نوع x64 إن كانت العمليّة المُحمِّلة من نوع x64، وكـDLL من نوع Arm64 إن كانت من نوع Arm64، فهي مناسبة لـمكتبات DLL يُحتمَل استدعاؤها من عمليّات كلا البنيتين. تذكر الوثائق الرسميّة كأمثلة على الحالات التي تتطلّب Arm64X: «خادم COM من نوع 64bit يُستدعى من تطبيقات x64 وArm64 معاً»، و«إضافة (Plugin) تُحمَّل في تطبيقات x64/Arm64 على السواء»، و«ثنائيّ واحد يُحقَن في عمليّات x64/Arm64».6

لنُحدِّد الضرر الفعليّ في تطبيقات الأعمال.

الحالة 1: exe من نوع x64 + DLL أصليّة من نوع x64 (عبر P/Invoke). إن كانت العمليّة كلّها موحَّدة على x64، فإنّها تعمل كاملةً داخل المحاكاة. لا يمكن مزج DLL من نوع Arm64 بحجّة «الرغبة في تسريع جزء فقط» (غير ممكن كما في الجدول أعلاه).

الحالة 2: خادم COM داخل العمليّة (In-process Server). بما أنّ خادم COM من نوع in-proc هو مجرّد DLL، تنطبق عليه قواعد الجدول أعلاه كما هي. لا يمكن للعميل من نوع x64 استخدام إلّا DLL من نوع COM بصيغة x64 (أو Arm64EC/Arm64X)، وفي اللحظة التي يُحوَّل فيها التطبيق إلى Arm64 أصيل، يتعذّر تحميل DLL الخاصّ بـCOM بصيغة x64. إن احتجتَ إلى دعم البنيتين معاً، فحوِّل الـDLL إلى صيغة Arm64X، أو طبِّق القاعدة المُجرَّبة في التبديل بين 32bit↔64bit، وهي فصل COM إلى خارج العمليّة/IPC (فصل العمليّات والربط بينها بالاتّصال بين العمليّات). تجاوز حاجز البنية عبر حدود العمليّة هو الشكل الأساسيّ المعتمَد منذ القديم.166

الحالة 3: أن تكون أنت مُستضيفاً للإضافات أو مُستضافاً بها. في حالات مثل إضافات Excel، وإضافات حزم الأعمال، وبرمجيّات وسيطة للطباعة، حيث «تُحمَّل مكتبة DLL الخاصّة بك في عمليّة طرف آخر»، يلزم مطابقة بنية الطرف الآخر. وبالعكس، إن كان تطبيقك يستضيف إضافات، فيلزم قراءة نطاق الأثر: تحويل تطبيقك إلى Arm64 يُقضي كليّاً على إضافات x64 من طرف ثالث.

بالمناسبة، يمكن التحقّق من نوع الثنائيّ الموجود لديك عبر موجّه أوامر المطوّر (Developer Command Prompt).5

link /dump /headers MyLibrary.dll | findstr machine
# 8664 machine (x64)            → x64
# 8664 machine (x64) (ARM64X)   → يتضمّن Arm64EC
# AA64 machine (ARM64)          → Arm64
# AA64 machine (ARM64) (ARM64X) → Arm64X

5. حالة تطبيقات .NET ── فخّ AnyCPU وتحديد البنية

يدعم .NET (سلسلة Core) رسميّاً Windows Arm64، وتنصّ الوثائق صريحاً على أنّ Arm64 من Windows 11/10 من أنظمة التشغيل المدعومة لـ .NET 8/9/10. ويكفي في النشر تحديد win-arm64 في RID.177

<!-- csproj: النشر من أجل Arm64 الأصيل -->
<PropertyGroup>
  <TargetFramework>net8.0-windows</TargetFramework>
  <RuntimeIdentifiers>win-x64;win-arm64</RuntimeIdentifiers>
</PropertyGroup>

dotnet publish -r win-arm64 -c Release

إن كان التطبيق شيفرة مُدارة خالصة فقط، فإنّ التحويل إلى Arm64 أصيل ينتهي تقريباً بهذا القدر. تكفي أن يُخرِج JIT شيفرة Arm64، ولا حاجة أساساً لتعديل الشيفرة المصدريّة. أمّا في حالة تطبيقات .NET Framework، فقد أضاف .NET Framework 4.8.1 دعم Arm64 الأصيل (لأجهزة Arm64 على Windows 11؛ بيئة تشغيل 4.8.1 لا تدعم تطبيقات Arm64 الأصيلة على أجهزة Arm بـ Windows 10). أمّا تطبيقات Framework التي تبقى مبنيّة بصيغة x64، فتُعامَل كتطبيقات تعمل عبر المحاكاة.1819

المشكلة هي التركيب الذي يحدث عند استدعاء مكتبة DLL أصليّة عبر P/Invoke. فعلى أجهزة Arm، يُخذَل الحسّ الراسخ منذ سنوات القائل: «لأنّه تطبيق .NET، فهو AnyCPU ويعمل في كلّ مكان».

  • عند التشغيل ببيئة تشغيل/حزمة تطوير .NET من نوع Arm64، يعمل التطبيق افتراضيّاً كعمليّة Arm64.8
  • لا يمكن لعمليّة Arm64 تحميل DLL من نوع x64 (الجدول في الفصل 4). بمعنى آخر، حتّى لو ظلّت شيفرتك الخاصّة من نوع AnyCPU سليمة، فإنّ تحميل مكتبة DLL أصليّة من نوع x64 مُستدعاة عبر DllImport يفشل.5
  • بالعكس، فإنّ التطبيق المنشور بصيغة win-x64 تكون عمليّته كلّها من نوع x64، ويعمل داخل المحاكاة (مع مكتبة DLL الأصليّة من نوع x64 معاً). في هذه الحالة لا تحصل على أداء Arm64 الأصيل، لكنّها البنية الأعلى في توافق التشغيل.12

حقيقة ما يبدو أنّه «يعمل أحياناً ولا يعمل أحياناً أخرى» هي في معظم الأحيان عدم تطابق بنية العمليّة مع بنية التبعيّات الأصليّة. وكخطوة أولى للتفريق، فإنّ تجهيز طريقة للتحقّق برمجيّاً من البنية التي تعمل بها العمليّة الجارية يُسهِّل التحقيق بشكل كبير.

using System.Runtime.InteropServices;

// بنية العمليّة نفسها (X64 إن كانت تحت محاكاة x64)
Console.WriteLine($"Process: {RuntimeInformation.ProcessArchitecture}");

// بنية نظام التشغيل الأصليّة (Arm64 إن كان جهاز Arm)
Console.WriteLine($"OS: {RuntimeInformation.OSArchitecture}");

من نقاط التنبيه أنّ OSArchitecture لم يبدأ بإعادة «بنية نظام التشغيل الأصليّة بعد نزع المحاكاة» إلّا ابتداءً من .NET 7. وقبل ذلك كان يُعيد X64 تحت المحاكاة، لذا فإنّ الشيفرة التي تُحدِّد «هل الجهاز من نوع Arm؟» عبر هذا الـ API في .NET 6 وما قبله لا تعمل كما هو متوقَّع.2021

نلخّص نقاط التحقّق الخاصّة بـ .NET.

  • الأصول الأصليّة في حزم NuGet: الحزمة التي لا تمتلك إلّا runtimes/win-x64/native لا تجد ما تعتمد عليه عند النشر بصيغة win-arm64. تحقّق من وجود أصول win-arm64 من عدمه في محتوى الحزمة (أو مستودعها). فـRID هو تحديداً الآليّة المخصَّصة لـ«توزيع الأصول الخاصّة بكلّ منصّة».7
  • تركيب حزمة التطوير على جهاز التطوير: على أجهزة Arm، يُثبَّت إصدار Arm64 من .NET في المجلّد العاديّ C:\Program Files\dotnet\، ويُثبَّت إصدار SDK من نوع x64 في C:\Program Files\dotnet\x64\، ويمكنهما التعايش. تتغيّر بنية تنفيذ dotnet run حسب الجهة التي يشير إليها PATH أو DOTNET_ROOT، فانتبه لذلك عند الاختبار.17
  • كيفيّة قراءة الاستثناء: يظهر عدم تطابق بنية التجميعة (Assembly) المُدارة كاستثناء BadImageFormatException (وتنصّ المرجعيّة الرسميّة صريحاً على أنّ «تحميل مكوّن يستهدف منصّة مختلفة» شرط لوقوعه).22

6. قائمة تحقّق لدعم Arm في تطبيق شركتك

في العمل الفعليّ، التحقّق عبر هذه المراحل الثلاث أكثر كفاءة.

المرحلة ما يجب فعله القرار
① جرد التبعيّات حصر مكتبات DLL الأصليّة المُستدعاة عبر P/Invoke، ومكوّنات COM، وبرامج التشغيل المُضمَّنة، وامتدادات القشرة، وحزم NuGet المحتوية على أصول أصليّة إن كانت برامج التشغيل وامتدادات القشرة صفراً، فالوضع واعد. وإن وُجدت، تحقّق من دعم كلّ مزوِّد لـArm6434
② التحقّق على جهاز فعليّ عبر المحاكاة ثبِّت البناء بصيغة x64 كما هو على جهاز Arm (أو جهاز افتراضيّ Arm64)، وجرِّب سيناريوهات الأعمال الرئيسيّة كاملةً إن عمل، فـ«التشغيل بصيغة x64 كما هو» يصبح خياراً. أمّا المواضع التي لا تعمل، فاشتبه في عدم تطابق التبعيّات والبنية1
③ النظر في بناء Arm64 أصيل في .NET، النشر بصيغة win-arm64؛ وفي C++، إضافة تهيئة Arm64 والتحقّق من نجاح البناء السبب النموذجيّ لفشل البناء هو غياب نسخة Arm64 من المكتبة التابعة. انظر في التحديث أو الاستبدال أو الاستفادة من Arm64EC23

لبيئة الاختبار الخاصّة بالمرحلتين ②③، تتوفّر الخيارات التالية.

  • جهاز فعليّ: جهاز مزوَّد بمعالج Snapdragon مثل Copilot+ PC. توفّر جهاز واحد هو الأضمن، بما يشمل التحقيق في المشكلات.12
  • جهاز افتراضيّ على Azure: يمكن تصفية الصورة (Image) بحسب Arm64 في بوّابة Azure، وإنشاء جهاز افتراضيّ Windows 11 Arm64 (بحجم موصى به مثل D2ps_v5، القائم على Ampere Altra). ميزته أنّه يمكن الشروع في الاختبار حتّى دون وجود جهاز Arm واحد بين يديك.9
  • جهاز افتراضيّ محليّ: ملفّ ISO لـ Windows 11 Arm64 مُوزَّع رسميّاً، ويمكن إنشاء جهاز افتراضيّ عليه عبر Hyper-V على جهاز Arm أو على جهاز Mac بمعالج Apple Silicon القائم على Arm. لاحظ أنّه لا يمكن إنشاء جهاز افتراضيّ Arm64 على Hyper-V الخاصّ بجهاز x64.10

يمكن التحقّق من حالة دعم منتجات الطرف الثالث عبر موقع الحالة الذي توفّره Microsoft (Works on Windows on Arm)، وفيما يتعلّق بمشكلات توافق تطبيقات الأعمال (LOB)، يوفّر برنامج App Assure دعماً دون تكلفة إضافيّة للشركات المشتركة في الخطط المؤهَّلة. وجود قناة رسميّة يمكن استخدامها قبل الوصول إلى طريق مسدود بسبب «عدم العمل» أمر فعّال أيضاً كمادّة توضيحيّة لمسؤولي الأنظمة الداخليّة.1215

7. الحلّ الواقعيّ الحاليّ ── التمييز بين ثلاثة خيارات

دعم Arm ليس خياراً واحداً هو «تحويل الجميع إلى أصيل». بل إنّ التمييز التدريجيّ هو الحلّ الواقعيّ في كثير من تطبيقات الأعمال.

الخيار الحالات المناسبة نقاط الحذر
(a) التشغيل عبر المحاكاة مع بقاء x64 كما هو عند عدم وجود اعتماد على برامج تشغيل/امتدادات قشرة، وكفاية الأداء عمليّاً تحسّن الأداء بفضل Prism (24H2 وما بعده). وحِّد العمليّة كلّها على x64 دون مزج ثنائيّات Arm6415
(b) التحقّق من دعم المزوِّد لـArm64 والانتظار عندما تكون مكتبة DLL الأصليّة أو برنامج التشغيل من طرف ثالث تحقّق من «موعد توفير نسخة DLL بصيغة Arm64 (أو Arm64X)». وبرامج التشغيل لا مخرج لها سوى الانتظار323
(c) بناء Arm64 أصيل تطبيق .NET خالص، أو عند توفّر نسخة Arm64 من جميع التبعيّات. أو عندما يكون الأداء وعمر البطاريّة من المتطلّبات الشرط هو النشر بصيغة win-arm64 + تحويل جميع التبعيّات الأصليّة إلى Arm64. احذر نطاق الأثر إن كنتَ تستضيف إضافات75

عندما تكون أصول C++ كبيرة، يوجد Arm64EC كحلّ وسيط بين (a) و(c). فبإمكانه تحويل شيفرتك الخاصّة فقط إلى شيفرة أصيلة تدريجيّاً مع ترك مكتبات DLL التابعة بصيغة x64 كما هي، وهو المسار الرسميّ لحالات «تعذّر نقل تطبيق x64 ضخم دفعة واحدة».523

من جهة بيئة التطوير، توجد نسخة Arm64 أصيلة من Visual Studio، وتتوفّر مجموعة أدوات مُصرِّف (Compiler Toolset) يمكنها استهداف Arm64/x64/x86 جميعها على جهاز Arm. ويمكن أيضاً إنشاء بناء CI عبر الترجمة التقاطعيّة (Cross-compilation) على أجهزة بناء x64 القائمة، ما يسهِّل تكوين بنية «تنفيذ الاختبار فقط على جهاز Arm الفعليّ/الجهاز الافتراضيّ».2423

8. الخلاصة

  • يستطيع Windows 11 بإصدار Arm تشغيل تطبيقات x86/x64 عبر محاكاة مدمجة في نظام التشغيل، وتحسّن الأداء أيضاً بفضل Prism ابتداءً من 24H2. ومحاكاة x64 تبدأ من Windows 11، أمّا Windows 10 on Arm فتحاكي x86 فقط.
  • نطاق تغطية المحاكاة يقتصر على وضع المستخدم فقط. أمّا برامج تشغيل وضع النواة/UMDF/الطابعات، وكذلك «مكتبات DLL تُحمَّل في عمليّات أخرى» مثل امتدادات القشرة ومحرّرات الإدخال والتقنيات المساعدة، فتحتاج حتماً إلى Arm64 أصيل. وإمكانيّة تشغيل تطبيق الأعمال لا تتحدَّد بالتطبيق نفسه، بل بهذه التبعيّات المحيطة.
  • لا يمكن مزج x64 وArm64 داخل عمليّة واحدة. فعمليّة x64/Arm64EC يمكنها تحميل x64+Arm64EC، وعمليّة Arm64 يمكنها تحميل Arm64 فقط. ويخضع خادم COM داخل العمليّة والإضافات لهذه القاعدة نفسها؛ فدعم البنيتين يتطلّب Arm64X، وتجاوز حدود العمليّة يتطلّب COM خارج العمليّة/IPC كقاعدة مُجرَّبة.
  • يمكن نشر .NET أصيلاً بصيغة win-arm64، لكن تطبيق AnyCPU على بيئة تشغيل Arm64 يعمل كعمليّة Arm64، فيفشل إن استدعى عبر P/Invoke مكتبة DLL أصليّة بصيغة x64 فقط. فرِّق بينهما عبر RuntimeInformation.ProcessArchitecture / OSArchitecture (ابتداءً من .NET 7).
  • خطوات التحقّق ثلاث مراحل: «جرد التبعيّات ← التحقّق على جهاز فعليّ عبر المحاكاة مع بقاء x64 كما هو ← التحويل إلى Arm64 أصيل عند الحاجة». ويمكن تجهيز بيئة الاختبار عبر جهاز افتراضيّ Arm64 على Azure أو ملفّ ISO لـArm64، وتحصل الشركات أيضاً على دعم App Assure.
  • الحلّ الواقعيّ الحاليّ هو التمييز بين: «إن عمل عبر المحاكاة فابقَ عليه كما هو»، و«التحقّق من دعم مزوِّدي برامج التشغيل ومكتبات DLL»، و«التحويل إلى Arm64 أصيل حسب المتطلّبات (وفي C++ الانتقال التدريجيّ عبر Arm64EC أيضاً)».

مقالات ذات صلة

مجالات الاستشارة ذات الصلة

تتعامل شركة Komura Soft LLC مع دراسة إمكانيّة دعم تطبيقات الأعمال القائمة لـ Windows بإصدار Arm، وتصميم انتقال بنية التطبيقات التي تتضمّن تكاملاً مع مكتبات DLL أصليّة وCOM، وتحليل أسباب الأعطال من نوع «لا يعمل فقط على جهاز Arm».

المراجع

  1. Microsoft Learn، How emulation works on Arm. حول كون المحاكاة مدمجة في نظام التشغيل وتشغيلها التطبيقات دون تعديل، ودعم Windows 11 لكلّ من x86/x64 في حين لا يحاكي Windows 10 on Arm إلّا x86، وآليّة تحويل JIT وتخزين كتل تعليمات x86 مؤقّتاً، ومحاكي Prism في Windows 11 24H2 وتحسينه لمعالجات Snapdragon، وخضوع تطبيقات x86 لإعادة التوجيه عبر WOW64 في حين تستخدم تطبيقات x64 الثنائيّات النظاميّة بصيغة Arm64X دون WOW64. ↩ ↩2 ↩3 ↩4 ↩5 ↩6

  2. Microsoft Learn، How emulation works on Arm. حول دعم المحاكاة لشيفرة وضع المستخدم فقط دون دعم برامج التشغيل، وضرورة ترجمة مكوّنات وضع النواة بصيغة Arm64. ↩ ↩2

  3. Microsoft Learn، Troubleshooting x86 desktop apps. حول ضرورة مطابقة جميع برامج تشغيل وضع النواة وبرامج تشغيل UMDF وبرامج تشغيل الطابعات لبنية نظام التشغيل، وتعذّر استخدام الميزات المعتمِدة على برنامج التشغيل حتّى لو عمل التطبيق نفسه عبر المحاكاة. ↩ ↩2 ↩3 ↩4 ↩5

  4. Microsoft Learn، Troubleshooting x86 desktop apps. حول ضرورة إعادة ترجمة التطبيقات التي تُحمِّل مكتبة DLL خاصّة بها في عمليّات Windows (امتدادات القشرة/IME/التقنيات المساعدة) بما يطابق بنية النظام (Arm64)، وتعذّر تنفيذ تطبيقات x86 التي تحظر توليد الشيفرة الديناميكيّ عبر المحاكاة. ↩ ↩2 ↩3 ↩4

  5. Microsoft Learn، Arm64EC - Build and port apps for native performance on Arm. حول جدول التوافق التشغيليّ الذي يبيّن أنّ عمليّة x64/Arm64EC يمكنها تحميل ثنائيّات x64 وArm64EC، وعمليّة Arm64 يمكنها تحميل ثنائيّات Arm64 فقط، وكون Arm64EC يتّبع اتّفاقيّة برمجيّات x64 بما يسمح بمزجها مع شيفرة x64 داخل العمليّة نفسها، وكون معظم شيفرة نظام التشغيل المُحمَّلة في عمليّة تطبيق x64 من نوع Arm64EC، وطريقة التحقّق من نوع الثنائيّ عبر link /dump /headers. ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10

  6. Microsoft Learn، Arm64X PE files. حول جمع Arm64X لشيفرة Arm64 وArm64EC في ملفّ PE واحد وإمكانيّة تحميله في عمليّة x64 أو Arm64 على السواء، وذكر خادم COM من نوع 64bit والإضافات ومكتبات DLL المُحقَنة التي تُستدعى من كلا البنيتين كحالات تتطلّب Arm64X. ↩ ↩2 ↩3

  7. Microsoft Learn، .NET RID Catalog. حول تعريف win-arm64 كـRID خاصّ بـWindows، واستخدام RID في توزيع الأصول الخاصّة بمنصّة معيّنة في حزم NuGet. ↩ ↩2 ↩3 ↩4

  8. Microsoft Learn، Windows on Arm. حول التشغيل الافتراضيّ كعمليّة Arm64 عند التنفيذ بحزمة تطوير .NET من نوع Arm64، ودعم .NET 8 فما بعده للتنفيذ الأصيل لـArm64، وعمل تطبيقات .NET القائمة من نوع x64 عبر محاكاة x64 الخاصّة بنظام التشغيل. ↩ ↩2 ↩3

  9. Microsoft Learn، Quickstart: Create a Windows on Arm virtual machine in the Azure portal. حول إمكانيّة إنشاء جهاز افتراضيّ Windows 11 Arm64 (بالحجم الموصى به D2ps_v5، القائم على Ampere Altra) بتصفية صورة Arm64 في بوّابة Azure. ↩ ↩2

  10. Microsoft Learn، Windows 11 Arm ISO files overview. حول توزيع ملفّ ISO لـWindows 11 Arm64، وإمكانيّة إنشاء جهاز افتراضيّ عليه عبر Hyper-V على جهاز Arm أو على جهاز Mac بمعالج Apple Silicon، وعدم دعم Hyper-V على عتاد x64 لأجهزة Arm64 الافتراضيّة. ↩ ↩2

  11. Microsoft Learn، Develop AI applications for Copilot+ PCs. حول كون Copilot+ PC فئة جديدة من عتاد Windows 11 مزوَّدة بوحدة معالجة عصبيّة (NPU) قادرة على أكثر من 40 تريليون عمليّة في الثانية (40+ TOPS). ↩

  12. Microsoft Learn، Windows on Arm. حول دعم Windows 10 لـx86 وإضافة Windows 11 التنفيذ دون تعديل لـx64، واعتماد الكثير من أجهزة Copilot+ PC معالجات سلسلة Snapdragon X، ووجود موقع للتحقّق من حالة دعم Arm (Works on Windows on Arm) وخدمة App Assure Arm Advisory Service. ↩ ↩2 ↩3 ↩4

  13. Microsoft Learn، How emulation works on Arm - Detecting emulation. حول رؤية التطبيقات تحت المحاكاة معلومات معالج افتراضيّ محاكى، وإعادة GetNativeSystemInfo أيضاً قيماً محاكاة حفاظاً على التوافق، واستخدام IsWow64Process2 وGetMachineTypeAttributes للكشف عن مضيف Arm64. ↩

  14. Microsoft Learn، Adjust emulation settings on Arm. حول إمكانيّة تغيير إعدادات محاكاة Prism (بإعدادات مسبقة Default/Safe/Strict/Very Strict وإعدادات فرديّة) من علامة تبويب التوافق في خصائص ملفّ exe. ↩

  15. Microsoft Learn، Arm-based Surface devices FAQ. حول قيود أجهزة Arm (ضرورة تصميم برامج التشغيل خصّيصاً لـArm، وتوقّف الأجهزة الطرفيّة على وجود برنامج تشغيل Arm64، والألعاب المعتمِدة على OpenGL أحدث من 3.3 أو مكافحة الغشّ غير الداعمة، وتطبيقات التخصيص كـIME، والتحقّق الفرديّ من برمجيّات مكافحة الفيروسات) ودعم التوافق عبر App Assure بما يشمل تطبيقات LOB. ↩ ↩2 ↩3 ↩4

  16. Microsoft Learn، Process Interoperability. حول تعذّر تحميل عمليّة 64bit مكتبة DLL من نوع 32bit (والعكس)، والقاعدة المُجرَّبة القاضية بإمكانيّة التواصل عبر حدود البنية باستخدام خادم COM خارج العمليّة وRPC. ↩ ↩2

  17. Microsoft Learn، Install .NET on Windows. حول كون Arm64 من Windows 11/10 مدعوماً لـ .NET 8/9/10، وتثبيت إصدار Arm64 من .NET في C:\Program Files\dotnet\ وإصدار SDK من نوع x64 في C:\Program Files\dotnet\x64\ على أجهزة Arm، وإمكانيّة الحاجة إلى تعديل PATH أو DOTNET_ROOT. ↩ ↩2

  18. Microsoft Learn، What’s new in .NET Framework. حول إضافة .NET Framework 4.8.1 دعم Arm64 الأصيل، وتفوّقه من ناحية الأداء على شيفرة x64 التي تُنفَّذ عبر المحاكاة على Arm64. ↩

  19. Microsoft Learn، Develop Apps for Windows IoT Enterprise. حول كون دعم .NET Framework 4.8.1 لـArm64 الأصيل موجَّهاً لـWindows 11، وعدم دعم بيئة تشغيل 4.8.1 لتطبيقات Arm64 الأصيلة على أجهزة Windows 10. ↩

  20. Microsoft Learn، RuntimeInformation.OSArchitecture under emulation. حول بدء OSArchitecture من .NET 7 بإعادة Arm64 حتّى في عمليّات المحاكاة على Windows Arm64 (وكان يُعيد X64 قبل ذلك)، وضرورة استخدام ProcessArchitecture لبنية العمليّة. ↩

  21. Microsoft Learn، RuntimeInformation.ProcessArchitecture Property / RuntimeInformation.OSArchitecture Property. حول واجهتَي API للحصول على بنية العمليّة الجارية وبنية نظام التشغيل الأصليّة. ↩

  22. Microsoft Learn، BadImageFormatException Class. حول وقوع BadImageFormatException عندما يستهدف مكوّن التطبيق منصّة مختلفة (تحميل تجميعة من بنية مختلفة). ↩

  23. Microsoft Learn، Add Arm support to your Windows app. حول العوامل النموذجيّة التي تعيق بناء Arm64 (مكتبات تابعة غير داعمة، شيفرة خاصّة ببنية معيّنة، برامج تشغيل نواة) وطرق التعامل معها، وخيار إعادة البناء بصيغة Arm64EC مع بقاء تبعيّات x64، وطرق الحصول على جهاز Arm فعليّ/جهاز افتراضيّ للاختبار، والجمع بين البناء عبر الترجمة التقاطعيّة والاختبار في بيئة Arm. ↩ ↩2 ↩3 ↩4

  24. Microsoft Learn، Visual Studio on Arm-powered devices. حول إمكانيّة تطوير .NET/C++ بنسخة Arm64 أصيلة من Visual Studio، وتوفير مجموعة أدوات MSVC التي تستهدف Arm64/x64/x86 من مضيف Arm64. ↩

مقالات ذات صلة

أحدث المقالات التي تشترك في نفس الوسوم. عمّق فهمك بمواضيع مرتبطة.

أين يتصل هذا الموضوع

ترتبط هذه المقالة بشكل طبيعي بصفحات الخدمات التالية.

الأسئلة الشائعة

أسئلة شائعة حول موضوع هذه المقالة.

هل تعمل تطبيقات الأعمال العاديّة من نوع x64 على Windows بإصدار Arm؟
في معظم الحالات، نعم تعمل. يحتوي Windows 11 on Arm على ميزة محاكاة مدمجة تشغِّل تطبيقات x86/x64 دون تعديل، وابتداءً من Windows 11 24H2 تحسّن الأداء أيضاً بفضل محاكٍ جديد يُدعى Prism. لكنّ المحاكاة تتولّى فقط شيفرة وضع المستخدم (User Mode)، أمّا برامج التشغيل في وضع النواة (Kernel Mode)، وكذلك امتدادات القشرة (Shell Extensions) ومحرّرات الإدخال (IME) التي تُحمَّل في عمليّات أخرى مثل Explorer، فتتطلّب Arm64 أصيلاً حتماً. اعتبر أنّ الأمر يتحدَّد بالتبعيّات المحيطة أكثر من التطبيق نفسه.
هل يمكن استدعاء DLL من نوع Arm64 من ملفّ exe من نوع x64؟
لا يمكن. لا يمكن مزج ثنائيّات (Binaries) x64 وArm64 داخل عمليّة واحدة؛ فعمليّة x64 (أو Arm64EC) يمكنها تحميل ثنائيّات x64 وArm64EC فقط، وعمليّة Arm64 يمكنها تحميل ثنائيّات Arm64 فقط. والاتّجاه المعكوس (من exe بصيغة Arm64 إلى DLL بصيغة x64) غير ممكن أيضاً بالمثل. إذا احتجتَ حتماً إلى ملفّ DLL واحد يدعم الصيغتين، فاستخدم صيغة تُدعى Arm64X تجمع شيفرة Arm64 وArm64EC في ملفّ واحد، أو فصل العمليّات والربط بينها عبر الاتّصال بين العمليّات (IPC).
ما المطلوب لجعل تطبيق .NET يدعم Arm64؟
يدعم .NET 6 فما بعده رسميّاً Windows Arm64، ويكفي تحديد معرّف بيئة التشغيل (RID) win-arm64 عند النشر (publish) لإنشاء ملفّ تنفيذيّ أصيل لـ Arm64. إن كانت الشيفرة كلّها مُدارة (Managed) خالصة، فهذا يُنهي الأمر تقريباً، لكن إن وُجدت مكتبات DLL أصليّة تُستدعى عبر P/Invoke أو حزم NuGet تحتوي أصولاً أصليّة، فيلزم التحقّق من وجود نسخة Arm64 لكلّ منها. أمّا تطبيقات .NET Framework، فالإصدار 4.8.1 يدعم التنفيذ الأصيل لـ Arm64 على Windows 11.
ما هي البرمجيّات التي لا تعمل على Windows بإصدار Arm؟
في المقدّمة، البرمجيّات التي تتضمّن برامج تشغيل في وضع النواة. فبرامج التشغيل لا تُحاكى، لذا لا تعمل عملاء VPN، ومنتجات الأمان، والأجهزة الافتراضيّة، ومصادقة دونجل USB، وما شابه، من دون برنامج تشغيل من نوع Arm64. تالياً، تدخل ضمن ذلك البرمجيّات التي تُحمِّل DLL في عمليّات نظام التشغيل مثل امتدادات القشرة ومحرّرات الإدخال (IME) والتقنيات المساعدة، والتطبيقات التي تحظر توليد الشيفرة الديناميكيّ (Dynamic Code Generation)، والألعاب المعتمِدة على OpenGL القديم أو برامج تشغيل مكافحة الغشّ (Anti-cheat). كما تتحدَّد إمكانيّة استخدام الأجهزة الطرفيّة بوجود برنامج تشغيل من نوع Arm64 من عدمه.

الملف الشخصي للمؤلف

صفحة الملف الشخصي لمؤلف المقالة.

غو كومورا

مؤسّس شركة كومورا سوفت ذ.م.م.

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

تواصل معنا

روابط عامة

GitHub LinkedIn X COM_BLAS COM_BigDecimal
العودة إلى المدونة