إلى أيّ مدى يمكن لتطبيق Windows أن يكون فعلاً single binary - ما الذي يندرج في EXE واحد وما الذي يبقى معتمداً على Windows

نشأت هذه المقالة من المنشور التالي.

«إن أمكن، نريد توزيعه ملفّاً واحداً» طلبٌ معتاد جدّاً في عمل Windows. أدوات الفِرَق الداخليّة، أدوات تكامل الأجهزة، البيئات غير المتّصلة (offline)، أدوات الدعم الميدانيّ، والفِرَق التي تريد تجنّب الـ installers الكاملة كلّها تدفع في هذا الاتّجاه.

المشكلة أنّ عبارة «single binary» تبدأ بخلط عدّة أهداف مختلفة:

• جعل المُنتَج المسلَّم ملفّاً واحداً
• تجنّب اشتراط .NET أو Visual C++ runtime مثبَّتَين مسبقاً
• جعل التطبيق يعمل بدون installer أو صلاحيّات admin
• تقليل الفروق عبر بيئات Windows المستهدفة

هذه الأمور ليست الشيء نفسه.

أكثر صياغة عمليّة هي هذه:

يمكنك غالباً دفع تطبيق Windows بعيداً جدّاً نحو EXE واحد بصورة مفاجئة.
لكنّك لا تستطيع أن تحذف Windows نفسه من قصّة التبعيّات.

تنظّم هذه المقالة تلك الحدود بشكل عملي.

1. الإجابة المختصرة

إن ضغطنا الواقع بشدّة، يبدو الأمر هكذا:

• يمكن غالباً دفع الملفّات التنفيذيّة العاديّة لسطح المكتب بعيداً جدّاً نحو تسليم single-binary
• لكن كون الملفّ EXE واحداً وعدم الاعتماد على بيئة Windows المستهدفة أمران مختلفان تماماً
• بمجرّد أن تُدخل تكامل shell، أو خدمات Windows، أو drivers، أو WebView2، أو بعض أشكال نشر WinUI 3، تصبح المشكلة الفعليّة أقلّ تعلّقاً بعدد الملفّات وأكثر تعلّقاً بـ ما يجب تسجيله، أو تثبيته، أو وجوده مسبقاً على Windows
• أهمّ خطوة عمليّة هي فصل هذه الأهداف بصراحة:
  • مُنتَج مسلَّم واحد
  • بدون تثبيت runtime منفصل
  • بدون installer
  • تبعيّة أقلّ على جانب الـ OS

بكلمات أخرى:

• مُنتَج مسلَّم واحد: ممكن جدّاً في الغالب
• runtime مُجمَّع: ممكن في الغالب
• نشر بنمط xcopy: يعتمد على نوع التطبيق
• صفر تبعيّة على Windows: مستحيل

2. «Single binary» تعني فعلاً عدّة مستويات مختلفة

2.1 المستوى A: المُنتَج المسلَّم ملفّ واحد

هذا هو المعنى السطحي:

• ملفّ واحد للإرسال
• ملفّ واحد لوضعه على ذاكرة USB
• ملفّ واحد يُوضع على الجهاز المستهدف

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

2.2 المستوى B: لا يوجد تثبيت منفصل لـ language runtime

هنا تظهر أسئلة مثل:

• static linking في C/C++ الأصليّة
• self-contained deployment في .NET
• single-file publishing في .NET
• Native AOT في .NET

عند هذا المستوى يبدأ التطبيق في الإحساس بأنّه أكثر اكتفاءً ذاتيّاً بكثير.

2.3 المستوى C: لا installer ولا تسجيل على جانب الـ OS

هنا تصبح كثير من المحادثات أصعب.

قد يعمل EXE قائم بذاته بشكل جيّد بمفرده، لكنّ القصّة تتغيّر إذا احتاج التطبيق إلى:

• shell extensions
• تسجيل خدمة Windows service
• تسجيل URL protocol
• ربط أنواع الملفّات (file associations)
• drivers
• مكوّنات تستضيفها Explorer أو Office

هنا لم تعد المشكلة الرئيسيّة «كم ملفّاً نُسلّم؟» بل «ماذا يحتاج Windows أن يعرفه عن هذا المكوّن؟»

2.4 المستوى D: لا اعتماد على بيئة Windows المستهدفة

هذا غير واقعي على Windows.

ما زال تطبيق Windows يعتمد على:

• سطح Windows API
• system loader
• system DLLs
• قواعد الأمان والصلاحيّات في الـ OS
• بنية الأجهزة والخدمات

يمكن لتعبئة single-binary أن تقلّل تعقيد النشر على جانب التطبيق. لكنّها لا تحوّل Windows إلى جزء قائم بذاته من التطبيق.

3. أين يكون تسليم single-binary واقعيّاً نسبيّاً

هذه هي أنواع التطبيقات التي يكون عادةً دفعها نحو EXE واحد أسهل:

• أدوات سطح المكتب القائمة بذاتها
• التطبيقات الداخليّة للأعمال التي تملك UI والمعالجة معاً
• أدوات الاتّصال والمراقبة والتسجيل والتحكّم بالأجهزة
• التطبيقات التي لا تحتاج استضافة من Explorer أو Office
• التطبيقات التي لا تتطلّب تكامل browser runtime

في هذه الحالات، يمكنك غالباً الإبقاء معاً على:

• شيفرتك الخاصّة
• الموارد
• بيانات الـ manifest
• التهيئة الافتراضيّة
• القوالب
• بعض مكتبات الطرف الثالث
• language runtime نفسه

وحتّى حين لا تُجبر حرفيّاً كلّ شيء داخل ملفّ واحد، يبقى app-local deployment نمطاً عمليّاً جدّاً في Windows:

• app.exe
• أو app.exe مع بضعة DLLs مجاورة
• بدون installer ثقيل
• بدون اشتراط صلاحيّات administrator

يمكن أن يكون هذا حلاً تشغيليّاً أفضل من الإفراط في تحسين النتيجة الصارمة لملفّ واحد.

4. تبعيّات Windows التي لا تختفي

4.1 إصدار الـ OS والـ architecture

ما زال لكلّ EXE واحد بيئة مستهدفة:

• أيّ إصدار Windows مدعوم
• هل يندرج Windows Server
• هل يهمّ x64 أو Arm64
• ما الـ API baseline التي تتوقّعها

ما زالت تلك القرارات بحاجة إلى وضوح صريح.

4.2 System DLLs وسلوك الـ loader

حتّى لو شُحن تطبيقك ملفّاً تنفيذيّاً واحداً، فإنّه ما زال يستخدم loader نظام التشغيل ومكوّناته:

• kernel32.dll
• user32.dll
• advapi32.dll
• بنية COM
• بنية الخدمات

يبقى نظام التشغيل جزءاً من الـ runtime الفعلي.

4.3 نموذج الأمان والتسجيل

هذه الأمور لا تختفي لمجرّد أنّ التطبيق مُعبَّأ بإحكام:

• UAC
• ACLs
• service control manager
• استخدام الـ registry
• قواعد توقيع الـ drivers

إن احتاج التطبيق هذه الأنظمة الفرعيّة، فإنّ شكل التعبئة لا يلغي تلك الحاجة.

4.4 تبعيّات الـ host أو الـ runtime

يصبح التصميم أكثر اعتماداً على عناصر خارجيّة بكثير حين يكون مستضافاً أو مُحرَّكاً بـ runtime:

• WebView2 يعني التعامل مع WebView2 Runtime
• بعض أشكال نشر Windows App SDK / WinUI تُدخل اعتبارات تعبئة إضافيّة
• shell extensions تتطلّب تسجيلاً موجَّهاً نحو Explorer

ولهذا فإنّ اختيارات تقنيّة الـ UI والتكامل تؤثّر مباشرةً على تعقيد النشر.

5. الواقع تقنيّةً تقنيّة

5.1 Native C/C++

Native C/C++ من الأماكن الأكثر ودّيّة لأهداف single-binary لأنّ خيارات static-linking موجودة. للأدوات العاديّة القائمة بذاتها، يمكن أن يعمل ذلك جيّداً جدّاً.

لكن حتّى هناك، تكون القرارات الفعليّة المهمّة عادةً:

• استراتيجيّة static مقابل dynamic CRT
• ما إذا كانت DLLs الطرف الثالث يمكن أن تبقى app-local
• إلى أيّ مدى يمكنك تحديد دعم الـ CPU والـ OS المستهدفَين بإحكام

5.2 .NET

تعطيك .NET عدّة مفاتيح مفيدة:

• framework-dependent
• self-contained
• single-file
• Native AOT

تساعد هذه كثيراً في تشكيل المُنتَج المسلَّم. لكنّها لا تلغي تبعيّات جانب Windows مثل الـ OS APIs، وسلوك الـ loader، واستهداف الـ architecture، أو متطلّبات الأنظمة الفرعيّة.

5.3 WebView2

بمجرّد دخول WebView2 إلى الصورة، يتوقّف السؤال الفعلي عن كونه «هل يمكنني جعل الـ EXE ملفّاً واحداً؟» ويصبح:

• هل أعتمد على WebView2 Runtime موجود سابقاً؟
• هل أستخدم Evergreen؟
• هل أشحن إصداراً ثابتاً؟
• كيف أتعامل مع البيئات غير المتّصلة (offline)؟

هذا سؤال عقد نشر (deployment-contract) أكثر من كونه سؤال عدد ملفّات.

5.4 WinUI 3 / Windows App SDK

يمكن أن يكون WinUI 3 بكلّ تأكيد الخيار التقني الصحيح، لكنّه يغيّر افتراضات النشر. إن كان تسليم ملفّ واحد متطلّباً صارماً، فينبغي مراجعة اختيار تقنيّة الـ UI نفسها مبكّراً لا متأخّراً.

6. مجالات يكون فيها التسجيل على جانب الـ OS هو القضيّة الرئيسيّة

6.1 Shell extensions

shell extensions التي يحمِّلها Explorer ليست فعلاً جزءاً من الفضاء نفسه لمشكلة EXE قائم بذاته عاديّ. هي تتعلّق بـ كيف يحمِّل Windows المكوّن ويتعرّف عليه.

6.2 خدمات Windows

قد يكون الملفّ التنفيذي للخدمة نفسه مجرّد ملفّ واحد، لكنّ النشر ما زال يتضمّن:

• تسجيل الخدمة
• قرارات الحساب والصلاحيّات
• سياسة الاسترداد
• إجراء التحديث

لذا بالنسبة للخدمات، تصميم التثبيت أهمّ من مجرّد عدد الملفّات الثنائيّة.

6.3 Drivers

الـ drivers أكثر صراحةً:

• INF
• التوقيع
• بنية الحزمة
• مسار التثبيت

هذه ليست مشكلة «ادفعها داخل EXE واحد». هي مشكلة «ملاءمة نموذج Windows driver بشكل صحيح».

7. جدول قرار عملي

أهمّ درس في ذلك الجدول هو هذا:

عدد الملفّات الثنائيّة ومسؤوليّة النشر شيئان مختلفان.

8. ما يجب تقريره قبل التنفيذ

إن كان تسليم single-binary مهمّاً، فينبغي الإجابة على هذه الأسئلة مبكّراً.

8.1 ما الذي تريد بالضبط جعله «واحداً»؟

• مُنتَج مسلَّم واحد؟
• لا تثبيت runtime منفصل؟
• لا installer؟
• تحديث offline أسهل؟

تتغيّر الإجابة مع اختيار التقنيّة.

8.2 ما الحدّ الأدنى المدعوم لـ Windows المستهدف؟

ما زالت مخرجات single-file وNative AOT خاصّةً بالمنصّة. إن بقي الـ OS والـ architecture المدعومان غامضَين لفترة طويلة، يميل المشروع إلى اكتشاف افتراضات غير متوافقة متأخّراً.

8.3 ما المُجمَّع وما المفترَض؟

كتابة هذا تساعد كثيراً:

• مُجمَّع مع التطبيق
  • الـ EXE الرئيسي
  • DLLs الخاصّة بك
  • قوالب التهيئة
  • self-contained runtime
• متروك لـ Windows
  • system DLLs
  • الـ OS APIs الأساسيّة
  • SCM / registry / Explorer
  • بنية الـ drivers
• متطلّبات خارجيّة
  • WebView2 Runtime
  • VC++ Redistributable
  • Office / Excel
  • drivers خاصّة بالأجهزة

8.4 إن أردت سلوك single-binary أقوى، قلّل تكامل الـ host

هذه واحدة من أكثر الرافعات فعّاليّةً:

• فضّل EXE عاديّاً على shell extension
• تجنّب تثبيت الخدمات إلّا حين يكون ضروريّاً فعلاً
• تجنّب الاعتماد على browser-runtime إن أمكن
• أبقِ استخدام COM داخل عمليّتك الخاصّة قدر الإمكان

تقليل التكامل المستضاف في الـ OS يقرّبك عادةً كثيراً من تسليم single-binary عملي.

9. الخلاصة

يسمح Windows بكثير من التقدّم نحو تسليم single-binary، لكنّ النموذج الذهنيّ الصحيح ما زال هذا:

يمكنك جعل التطبيق EXE واحداً.
لا يمكنك جعل نظام التشغيل يختفي من الرسم البياني لتبعيّات التطبيق.

النقاط الخمس التي تستحقّ التذكّر هي:

• الملفّات التنفيذيّة العاديّة القائمة بذاتها يمكن غالباً تسليمها بشكل مدمج جدّاً
• static-linking في C/C++، و.NET single-file، وNative AOT كلّها أدوات مفيدة
• ما زال إصدار الـ OS، والـ architecture، وsystem DLLs، ونموذج أمان Windows باقيةً
• shell extensions، والخدمات، والـ drivers، وWebView2، وبعض حالات WinUI تتعلّق فعلاً بالتسجيل أو افتراضات الـ runtime الخارجيّة
• يعتمد النجاح على تعريف ما تعنيه «واحد» قبل بدء التنفيذ

إن كان تسليم ملفّ واحد أولويّةً صارمة، فاختيار تقنيّات ذات ضغط تكامل أقلّ مع نظام التشغيل يهمّ عادةً أكثر من ضغط DLL إضافي داخل الحزمة.

10. مراجع

• Microsoft Learn, Create a single file for application deployment
• Microsoft Learn, Native AOT deployment overview
• Microsoft Learn, C runtime (CRT) and C++ standard library (STL) lib files
• Microsoft Learn, Dynamic-link library search order
• Microsoft Learn, Targeting your application for Windows
• Microsoft Learn, Creating Registration-Free COM Objects
• Microsoft Learn, Registering Shell Extension Handlers
• Microsoft Learn, CreateServiceW function
• Microsoft Learn, Overview of INF Files
• Microsoft Learn, Windows driver signing tutorial
• Microsoft Learn, Distribute your app and the WebView2 Runtime
• Microsoft Learn, Windows App SDK deployment guide for self-contained apps