WSL2 on kenji.blog

Hyper-V مقابل WSL2: مقارنة تقنيات المحاكاة الافتراضية على Windows

Sun, 13 Sep 2026 07:00:00 +0900

1. مقدمة: تطور المحاكاة الافتراضية في Windows

لقد تطورت تقنيات المحاكاة الافتراضية على منصة Windows بشكل كبير خلال العقود القليلة الماضية. في الماضي، كانت برامج الهايبرفايزر (Hypervisor) من النوع الثاني (Type 2) التابعة لجهات خارجية (مثل VMware Workstation و VirtualBox) هي السائدة، ولكن منذ أن قدمت Microsoft “Hyper-V” في Windows Server 2008، تم دمج برامج الهايبرفايزر من النوع الأول (Type 1) في أنظمة تشغيل سطح المكتب Windows 10/11.

وفي السنوات الأخيرة، أصبح “WSL2 (Windows Subsystem for Linux 2)” يحظى بأكبر قدر من الاهتمام بين المطورين. بينما كان WSL1 يعتمد على ترجمة استدعاءات النظام (System Calls)، يستخدم WSL2 “جهازاً افتراضياً خفيفاً للأدوات (Lightweight Utility VM)” يعتمد على تقنية Hyper-V، مما يوفر توافقاً كاملاً مع نظام Linux وتحسناً هائلاً في الأداء.

في هذه المقالة، سنقوم بمقارنة وشرح هاتين التقنيتين القويتين للمحاكاة الافتراضية ―― “Hyper-V” كامل الميزات، و “WSL2” المتخصص في تجربة المطورين ―― من حيث البنية، الأداء (وحدة المعالجة المركزية، الذاكرة، وإدخال/إخراج القرص (Disk I/O))، تكوين الشبكة، وأفضل حالات الاستخدام، إلى جانب تفاصيل فنية عميقة.

2. النظرية الأساسية للهايبرفايزر ومقارنة البنية (Architecture)

لفهم تقنيات المحاكاة الافتراضية، من الضروري فهم تصنيف أنواع الهايبرفايزر (مراقب الأجهزة الافتراضية: VMM).

2.1. الفرق بين الهايبرفايزر من النوع الأول (Type 1) والنوع الثاني (Type 2)

الهايبرفايزر عبارة عن طبقة برمجية تجرد الوصول إلى الأجهزة وتسمح لأنظمة تشغيل متعددة (أنظمة التشغيل الضيف) بالعمل في وقت واحد على جهاز مادي واحد.

النوع الأول (المعدن المجرد - Bare-metal): يعمل مباشرة على الأجهزة. لا يوجد مفهوم لنظام التشغيل المضيف (على الرغم من أنه بالمعنى الدقيق للكلمة قد يكون هناك نظام تشغيل إدارة له امتيازات)، وله حمل زائد (Overhead) منخفض للغاية ويوفر أداءً وأماناً عاليين. أمثلة: Hyper-V و VMware ESXi و Xen.
النوع الثاني (المستضاف - Hosted): يعمل كتطبيق على نظام التشغيل المضيف (مثل Windows أو macOS). نظراً لأن جميع عمليات الوصول إلى الأجهزة تتم عبر نظام التشغيل المضيف، فإن الحمل الزائد يكون كبيراً. أمثلة: VMware Workstation و Oracle VirtualBox.

يعد Hyper-V الخاص بـ Windows هايبرفايزر نقياً من النوع الأول (Type 1). عندما تقوم بتمكين Hyper-V، فإن نظام تشغيل Windows الفعلي الذي يتفاعل معه المستخدم عادة سيعمل أيضاً داخل جهاز افتراضي خاص يسمى “قسم الجذر (Root Partition)”.

2.2. تفاصيل بنية Hyper-V

تتبنى بنية Hyper-V تصميم الميكروكيرنل (Microkernel)، وتستند إلى وحدات عزل منطقية تسمى الأقسام (Partitions).

graph TD
A["الأجهزة (وحدة المعالجة المركزية، ذاكرة الوصول العشوائي، القرص، بطاقة الشبكة)"] --> B["هايبرفايزر ويندوز (Ring -1)"]
B --> C["قسم الجذر (نظام تشغيل ويندوز)"]
B --> D["القسم الفرعي 1 (جهاز افتراضي ويندوز)"]
B --> E["القسم الفرعي 2 (جهاز افتراضي لينكس)"]
C --> F["ناقل الجهاز الافتراضي (VMBus)"]
D --> F
E --> F
C --> G["برنامج تشغيل البنية التحتية للمحاكاة الافتراضية (VID)"]
C --> H["عملية العامل (VMWP.exe)"]

هايبرفايزر ويندوز (Windows Hypervisor): يعمل بأعلى مستوى امتياز لوحدة المعالجة المركزية (Ring -1 أو VMX Root Mode)، ويكون مسؤولاً فقط عن تخصيص الذاكرة وجدولة وحدة المعالجة المركزية. لا يتضمن برامج تشغيل الأجهزة.
قسم الجذر (Root Partition): القسم الذي يعمل فيه نظام تشغيل Windows المضيف. يمتلك جميع برامج تشغيل الأجهزة ويتحكم في الأجهزة مباشرةً. يوفر أيضاً وظائف الإدارة للأقسام الفرعية (مثل مزود WMI و VMWP.exe).
القسم الفرعي (Child Partition): القسم الذي يعمل فيه نظام التشغيل الضيف. لا يُسمح له بالوصول المباشر إلى الأجهزة، ويرسل طلبات الإدخال/الإخراج إلى قسم الجذر (Synthetic I/O) عبر ناقل مشاركة ذاكرة منطقي يسمى “VMBus”.

2.3. آلية عمل WSL2 وجهاز Utility VM الخفيف

يستخدم WSL2 نفس تقنية الأساس للهايبرفايزر من النوع الأول (Type 1) مثل Hyper-V، ولكنه يستخدم مجموعة فرعية تسمى “منصة الأجهزة الافتراضية (Virtual Machine Platform: VMP)” والتي تختلف عن الأجهزة الافتراضية كاملة الميزات لـ Hyper-V.

يلغي “الجهاز الافتراضي الخفيف للأدوات (Lightweight Utility VM)” المستخدم في WSL2 تماماً المحاكاة (Emulation) للأجهزة القديمة التي تمتلكها الأجهزة الافتراضية التقليدية (مثل BIOS الافتراضي واللوحة الأم الافتراضية).

graph TD
A["نظام تشغيل ويندوز المضيف (مساحة المستخدم)"]
B["نظام ملفات NTFS"]
C["خادم بروتوكول 9P (Plan 9)"]
D["الجهاز الافتراضي الخفيف للأدوات (نواة لينكس)"]
E["ext4.vhdx (القرص الافتراضي)"]
F["مساحة مستخدم لينكس (توزيعات WSL2)"]
A --> C
C -->| مشاركة الملفات عبر أنظمة التشغيل | D
D --> E
D --> F

أكبر ميزات WSL2 هي سرعة بدء التشغيل و التكامل السلس مع نظام التشغيل المضيف. تعمل نواة Linux في أقل من ثانية، ويتم الوصول إلى نظام الملفات (NTFS) على جانب Windows عبر بروتوكول نظام ملفات الشبكة 9P الخاص بـ Plan 9.

3. التحليل الشامل للأداء: موارد الحوسبة والإدخال/الإخراج

يتم التعبير عن أداء الجهاز الافتراضي كمجموع الأحمال الزائدة (Overheads) في كل مكون: وحدة المعالجة المركزية، الذاكرة، وإدخال/إخراج القرص (Disk I/O).

3.1. وحدة المعالجة المركزية وتبديل السياق (Context Switch)

يستخدم كل من Hyper-V و WSL2 المحاكاة الافتراضية المدعومة بالأجهزة (Intel VT-x / AMD-V). يتم تنفيذ تعليمات وحدة المعالجة المركزية بشكل أساسي بالسرعة الأصلية، ولكن عند تنفيذ التعليمات ذات الامتيازات أو معالجة الإدخال/الإخراج، تحدث مقاطعة تسمى “VM Exit”، ويتم تبديل السياق (Context Switch) إلى الهايبرفايزر.

يمكن التعبير عن الحمل الزائد لوحدة المعالجة المركزية $T_{overhead}$ في هذا الوقت بالنموذج الرياضي التالي:

$$ T_{overhead} = \sum_{i=1}^{N} (t_{vm\_exit} + t_{hypercall\_process} + t_{vm\_entry}) $$

حيث:

$N$: عدد مرات حدوث VM Exit لكل وحدة زمنية
$t_{vm\_exit}$: وقت الانتقال من الضيف إلى الهايبرفايزر
$t_{hypercall\_process}$: وقت معالجة الإدخال/الإخراج أو المقاطعات عبر VMBus
$t_{vm\_entry}$: وقت العودة من الهايبرفايزر إلى الضيف

نظراً لعدم وجود محاكاة (Emulation) للأجهزة القديمة في WSL2، تم تحسين $t_{hypercall\_process}$ ليكون صغيراً للغاية. لذلك، في العمليات الحسابية البحتة لوحدة المعالجة المركزية (على سبيل المثال، تجميع النواة أو استنتاج نماذج التعلم الآلي)، يقتصر تدهور الأداء على بضع نسب مئوية مقارنة ببيئة المعدن المجرد (Bare-metal).

3.2. آلية تخصيص الذاكرة

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

Hyper-V (الذاكرة الديناميكية): بناءً على طلب الذاكرة من الجهاز الافتراضي الضيف، يقوم قسم الجذر بتخصيص واستعادة الذاكرة ديناميكياً. ومع ذلك، لا يتم تحرير الذاكرة المحجوزة كذاكرة تخزين مؤقت للصفحات (Page Cache) داخل نظام التشغيل الضيف بسهولة ما لم يكن النظام تحت ضغط.
WSL2 (الاستعادة الديناميكية للذاكرة): يمتلك WSL2 آلية خاصة به حيث يقوم بانتظام بإرجاع (Reclaim) الذاكرة التي لم يعد هناك حاجة إليها داخل جهاز Linux الافتراضي (بما في ذلك ذاكرة التخزين المؤقت) إلى مضيف Windows. في الإصدارات الأولى من WSL2، كانت هناك مشكلة حيث تستهلك ذاكرة التخزين المؤقت للصفحات في Linux ذاكرة Windows (تضخم عملية Vmmem)، ولكن تم تحسين ذلك الآن من خلال تصحيحات النواة (Kernel Patches).

3.3. خصائص إدخال/إخراج القرص (VHDX مقابل ext4.vhdx)

غالبًا ما يكون إدخال/إخراج القرص هو العائق (Bottleneck) الأكبر في أداء الجهاز الافتراضي.

يتم حساب زمن انتقال (Latency) الإدخال/الإخراج $L_{total}$ على النحو التالي:

$$ L_{total} = L_{guest\_fs} + L_{vmbus} + L_{host\_fs} + L_{physical\_disk} $$

في حالة Hyper-V: تستخدم الأجهزة الضيفة النموذجية في Hyper-V أقراصاً افتراضية بتنسيق VHDX. يتم معالجة طلبات الإدخال/الإخراج الصادرة من نظام الملفات (ext4 أو NTFS) داخل نظام التشغيل الضيف عبر برنامج تشغيل تخزين الجهاز الكتلي لـ VMBus (storvsc)، ويتم التعامل معها كوصول إلى ملف VHDX على نظام NTFS في جانب Windows.

في حالة WSL2: تعمل توزيعات Linux الخاصة بـ WSL2 على نظام ملفات ext4 الأصلي المبني داخل ملف ext4.vhdx مخصص. توفر عمليات الملفات داخل Linux (مثل داخل دليل ~) أداءً أصلياً مشابهاً لأداء Hyper-V المذكور أعلاه. ومع ذلك، عند الوصول إلى ملفات على جانب Windows (مثل /mnt/c/) من Linux في WSL2، أو العكس، تختلف المعالجة بشكل كبير. يتم استخدام 9P (بروتوكول نظام ملفات Plan 9) للوصول عبر أنظمة التشغيل هذه.

$$ L_{cross\_os} = L_{9p\_client} + L_{socket\_transfer} + L_{9p\_server} + L_{ntfs} $$

نظراً لأن الوصول عبر بروتوكول 9P يترتب عليه حمل زائد كبير بسبب عملية التسلسل (Serialization)، فإن الأداء ينخفض بشكل ملحوظ (أحياناً بتأخير يزيد عن 10 أضعاف) للاستخدامات التي تقرأ وتكتب عدداً كبيراً من الملفات الصغيرة (مثال: npm install في مشروع Node.js أو عمليات Git الموجودة في دليل على جانب Windows). لذلك، القاعدة الذهبية عند استخدام WSL2 هي وضع ملفات المشروع دائماً في نظام الملفات الأصلي لنظام Linux (تحت ~/).

4. هيكل الشبكة: NAT، والمفتاح الافتراضي (Default Switch)، والشبكة المدمجة (Bridged)

تعد مرونة ميزات الشبكات أحد الاختلافات الرئيسية بين Hyper-V و WSL2.

4.1. شبكة WSL2 (القائمة على NAT)

تم تكوين شبكة WSL2 افتراضياً لتكون شبكة “NAT (ترجمة عنوان الشبكة)” باستخدام تقنية التبديل الافتراضي (Virtual Switch) الخاصة بـ Hyper-V. يتم تلقائياً تخصيص عنوان IP خاص (مثال: 172.20.x.x) لجهاز Linux الافتراضي يختلف عن مضيف Windows. توجد آلية مدمجة تقوم بتوجيه الطلبات من مضيف Windows عبر localhost إلى الخدمات (المنافذ) التي تم تشغيلها داخل WSL2، مما يسمح للمطورين باختبار خوادم الويب وغيرها دون القلق بشأن الشبكة.

في الآونة الأخيرة، تم تقديم وضع شبكة جديد يسمى “وضع النسخ المتطابق (Mirrored Mode)” في إصدار المعاينة لـ WSL2. يهدف هذا إلى دعم IPv6 وتحسين التوافق مع اتصالات VPN (يمكن تكوينه في .wslconfig).

4.2. المفتاح الافتراضي لـ Hyper-V (Virtual Switch)

يسمح Hyper-V ببناء شبكات متقدمة على مستوى المؤسسات. من خلال “مدير المفتاح الافتراضي (Virtual Switch Manager)"، فإنه يوفر ثلاثة أوضاع رئيسية:

خارجي (External): يربط بطاقة الشبكة الفعلية للجهاز المضيف بالمفتاح الافتراضي، ويسمح للجهاز الافتراضي الضيف بالانضمام مباشرة إلى الشبكة المادية (اتصال جسر - Bridged). يحصل الجهاز الافتراضي على عنوان IP من خادم DHCP من نفس الشبكة الفرعية للشبكة المادية.
داخلي (Internal): يسمح فقط بالاتصال بين نظام التشغيل المضيف والجهاز الافتراضي، وبين الأجهزة الافتراضية وبعضها البعض. لا يمكن الوصول المباشر إلى الشبكات الخارجية.
خاص (Private): يسمح فقط بالاتصال بين الأجهزة الافتراضية، ويحظر حتى الاتصال بنظام التشغيل المضيف. يستخدم لبناء بيئات اختبار معزولة.

4.3. بناء شبكة Hyper-V المتقدمة باستخدام PowerShell

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

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


# 1. إنشاء مفتاح افتراضي داخلي
$SwitchName = "HyperV-NatSwitch"
New-VMSwitch -SwitchName $SwitchName -SwitchType Internal

# 2. تعيين عنوان IP لبطاقة الشبكة الافتراضية على جانب المضيف (عنوان IP الذي سيكون البوابة)
$GatewayIP = "192.168.100.1"
$NetPrefix = 24
$InterfaceAlias = "vEthernet ($SwitchName)"
New-NetIPAddress -IPAddress $GatewayIP -PrefixLength $NetPrefix -InterfaceAlias $InterfaceAlias

# 3. تكوين شبكة NAT
$NatName = "HyperV-NatNetwork"
$NatSubnet = "192.168.100.0/24"
New-NetNat -Name $NatName -InternalIPInterfaceAddressPrefix $NatSubnet

# أمر للتحقق
Get-NetNat

من خلال هذا التكوين، ومن خلال تعيين عنوان IP يدوياً مثل 192.168.100.x والبوابة 192.168.100.1 لضيف Hyper-V المحدد، يمكنك بناء مقطع NAT خاص يمكنه الاتصال بالعالم الخارجي عبر المضيف.

5. حالات الاستخدام ودليل الاختيار العملي

بناءً على الاختلافات في البنية والأداء التي تمت مناقشتها حتى الآن، سنحدد في أي المواقف يجب اعتماد أي تقنية.

5.1. السيناريوهات التي يجب فيها اختيار WSL2

تم تصميم WSL2 خصيصاً لـ “تحسين إنتاجية المطورين”. إنه مثالي للاستخدامات التالية:

تطوير الويب وتطوير السحابة الأصلية (Cloud-Native): تطوير الحاويات باستخدام Docker Desktop (نهاية WSL2 الخلفية - Backend) أو Podman.
استخدام الأدوات المخصصة لنظام Linux: إذا كنت تستخدم بشكل يومي bash و grep و awk و sed، أو مجمعات GCC أو Clang لنظام Linux.
تطبيقات واجهة المستخدم الرسومية (WSLg): عندما تريد تشغيل تطبيقات X11/Wayland الخاصة بـ Linux بسلاسة على سطح مكتب Windows.
التعلم الآلي وتطوير الذكاء الاصطناعي: التدريب السريع للنماذج باستخدام TensorFlow أو PyTorch مع الاستفادة من ميزة التمرير المباشر لوحدة معالجة الرسومات (GPU Passthrough) (مثل NVIDIA CUDA على WSL).

ملاحظة: قد تواجه قيوداً إذا كنت ترغب في تخصيص النواة بدقة، أو إذا كنت تبني خدمات معقدة تعتمد بشكل كبير على systemd (على الرغم من أن systemd مدعوم حالياً، إلا أنه قد يكون معطلاً أو مقيداً بشكل افتراضي).

5.2. السيناريوهات التي يجب فيها اختيار Hyper-V

يهدف Hyper-V إلى “المحاكاة الافتراضية للبنية التحتية والعزل الكامل”. وهو ضروري للاستخدامات التالية:

تشغيل أجهزة Windows الافتراضية: عند تشغيل إصدارات مختلفة من Windows (مثل Windows Server أو إصدار أقدم من Windows 10) كبيئة اختبار.
المحاكاة الافتراضية المتداخلة (Nested Virtualization): عندما تريد تشغيل أجهزة افتراضية (Hyper-V أو KVM) داخل جهاز افتراضي آخر. لا غنى عنه لبيئات التحقق الخاصة بمهندسي البنية التحتية.
متطلبات الشبكة المتقدمة: عندما تحتاج إلى التحكم الصارم في تكوين الشبكة، مثل اتصالات الجسر الخارجية (الانضمام إلى نفس الشبكة المحلية LAN)، ووضع علامات VLAN (VLAN Tagging)، وتعيين بطاقات شبكة (NICs) متعددة.
اللقطات (نقاط الفحص - Checkpoints): القدرة على حفظ حالة الجهاز الافتراضي في نقطة زمنية معينة والتراجع (Rollback) إليها على الفور في أي وقت. مفيد للغاية للاختبارات المدمرة للبرامج أو تحليل البرامج الضارة.
تخصيص الموارد الثابتة: عندما تريد تحديد عدد أنوية وحدة المعالجة المركزية وسعة الذاكرة بدقة، وتقليل التأثير على نظام التشغيل المضيف.

6. دراسة إنتاجية الإدخال/الإخراج باستخدام النموذج الرياضي (الملحق)

كمهندس أنظمة، عند تقييم حدود أداء الإدخال/الإخراج لكليهما، من المهم أن تفهم نظرياً العلاقة بين الإنتاجية (Throughput) $S$ وحجم الكتلة (Block Size) $B$.

إنتاجية نقل البيانات $S$ هي كمية البيانات المنقولة لكل وحدة زمنية، ويمكن تمثيلها بالنموذج التالي:

$$ S(B) = \frac{B}{L_{setup} + \frac{B}{R_{max}}} $$

$B$: حجم الكتلة (بايت - Bytes)
$L_{setup}$: الكمون الثابت (Fixed Latency) المرتبط بإعداد طلب الإدخال/الإخراج وتبديل السياق
$R_{max}$: أقصى عرض نطاق ترددي للأجهزة في النسخ ونقل الأجهزة

في الوصول إلى الملفات عبر بروتوكول 9P في WSL2، يكون $L_{setup}$ كبيراً جداً (بسبب اتصال المآخذ (Socket) والتسلسل/إلغاء التسلسل للبروتوكول). لذلك، عندما يكون حجم الكتلة $B$ صغيراً (قراءة وكتابة كميات كبيرة من الملفات الصغيرة بحجم عدة كيلوبايتات)، يصبح تأثير $L_{setup}$ في المقام هو السائد، وتنخفض الإنتاجية $S$ بشكل كبير. على العكس من ذلك، في الوصول إلى VHDX عبر VMBus في Hyper-V، يتم تحسين $L_{setup}$ إلى مستوى قريب من مقاطعات الأجهزة، مما يتيح الحفاظ على IOPS عالي حتى مع الكتل الصغيرة.

هذا الواقع الرياضي هو الأساس المنطقي لأفضل الممارسات القائلة: “في WSL2، يجب ألا تضع ملفات مشروعك على جانب Windows”.

7. الخلاصة: تقنيتا محاكاة افتراضية تتعايشان معاً

لا يعني Hyper-V و WSL2 أن أحدهما أفضل من الآخر، بل هما “حلان ذوا أهداف مختلفة”.

WSL2 هو “أداة التكامل الأفضل” لكسر قوقعة نظام التشغيل Windows وتقديم نظام Linux البيئي بسلاسة وسرعة إلى مستخدمي Windows. ليس من المبالغة القول إنها بيئة واجهة سطر الأوامر (CLI) المثلى للمطورين.
Hyper-V هو “هايبرفايزر متكامل” يجلب قدرات العزل والإدارة القوية المزروعة في مراكز بيانات المؤسسات إلى سطح المكتب. لا يوجد مثيل له في بناء الشبكات واختبار نظام تشغيل Windows ومحاكاة بيئات البنية التحتية.

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

الدليل الشامل لإعداد بيئة التطوير لنظام WSL2 (نظام ويندوز الفرعي لنظام لينكس)

Sat, 12 Sep 2026 23:00:00 +0900

يوفر “WSL2” (نظام ويندوز الفرعي لنظام لينكس 2)، والذي يقدم بيئة تطوير أصلية للينكس على ويندوز، أداة لا غنى عنها في تطوير البرمجيات الحديثة. ومع ذلك، هناك فرق شاسع في الأداء وتجربة التطوير بين الاستمرار في استخدامه في حالته الافتراضية، وبين فهم بنيته المعمارية وإجراء الضبط المناسب.

في هذه المقالة، سنشرح بالتفصيل الشامل (بأكثر من 10,000 حرف) جميع الخطوات اللازمة لبناء “بيئة التطوير المطلوبة (المثالية)” التي يبحث عنها المهندسون المحترفون. بدءًا من شرح البنية المعمارية التي تشكل أساس WSL2، وصولاً إلى الإعدادات اللازمة لاستخراج أقصى أداء، وبناء بيئة طرفية (Terminal) مريحة، والتكامل السلس مع Docker و VS Code، وإعدادات الشبكة المتقدمة.

1. بنية WSL2 وتطورها عن WSL1

لاستخراج كامل إمكانات WSL2، من المهم أولاً فهم بنيته الداخلية. تختلف المقاربة المستخدمة لتشغيل ثنائيات لينكس على ويندوز بشكل جذري بين الإصدار الأول (WSL1) و WSL2.

WSL1: طبقة ترجمة استدعاءات النظام (System Calls)

اعتمد WSL1 على آلية تترجم استدعاءات نظام لينكس إلى واجهة برمجة تطبيقات ويندوز (NT API) في الوقت الفعلي (Real-time). وبما أن هذا لم يستخدم جهازًا افتراضيًا (VM)، كان يتمتع بميزة أن العبء على الموارد كان ضئيلًا جدًا. ومع ذلك، كان من الصعب محاكاة استدعاءات النظام المعقدة بشكل كامل، مثل عمليات الإدخال والإخراج (I/O) لنظام الملفات، مما أدى إلى انخفاض مروع في الأداء، خاصة في العمليات التي تتعامل مع عدد كبير من الملفات الصغيرة، مثل npm install في Node.js أو عمليات مستودع Git.

WSL2: جهاز افتراضي (VM) للمرافق خفيف الوزن ونواة لينكس كاملة

في WSL2، تم تجديد البنية المعمارية، وأصبحت نواة لينكس حقيقية، تم بناؤها بواسطة Microsoft، تعمل مباشرة على “جهاز افتراضي للمرافق خفيف الوزن” يستخدم مجموعة فرعية من بنية Hyper-V. هذا يضمن توافقًا بنسبة 100% مع استدعاءات النظام، ومن خلال استخدام قرص افتراضي (VHDX) يستخدم نظام ملفات ext4 الأصلي للينكس، تم تحسين أداء إدخال/إخراج الملفات بشكل كبير مقارنة بـ WSL1.

يوضح مخطط Mermaid التالي الاختلافات الهيكلية بين WSL1 و WSL2.

flowchart TD
subgraph "بيئة نظام تشغيل ويندوز"
A["نواة Windows NT"]
A --> F["نظام ملفات NTFS (محرك C:)"]
end
subgraph "بنية WSL2"
B["مراقب الأجهزة الافتراضية Hyper-V"]
B --> C["جهاز افتراضي (VM) للمرافق خفيف الوزن"]
C --> D["نواة لينكس (Microsoft)"]
D --> E["مساحة مستخدم Ubuntu (glibc, bash, إلخ)"]
D --> G["قرص افتراضي ext4 (.vhdx)"]
end
A -.->|"مشاركة ملفات شبكة بروتوكول Plan 9 (9P)"| D
style B fill:#f9f,stroke:#333,stroke-width:2px
style D fill:#bbf,stroke:#333,stroke-width:2px

الدرس المهم المستفاد من هذا الهيكل هو أن “الوصول إلى الملفات الموجودة على جانب لينكس (داخل VHDX) سريع للغاية، ولكن الوصول إلى الملفات الموجودة على جانب ويندوز (/mnt/c/) بطيء جدًا لأنه يمر عبر بروتوكول 9P”. يجب وضع الشيفرة المصدرية (Source code) للمشروع دائمًا ضمن الدليل الرئيسي (~) على جانب WSL.

2. التحليل الرياضي للأداء: لماذا يعتبر WSL2 سريعًا؟

دعونا نقيم تحسين أداء WSL2 بشكل كمي باستخدام نموذج رياضي. في تطوير البرمجيات، واحدة من أكثر العمليات استهلاكًا للوقت هي تلك التي تتضمن عمليات إدخال/إخراج (I/O) لعدد كبير من الملفات (مثل: تثبيت المكتبات أو البناء).

يتم التعبير عن وقت التنفيذ الإجمالي للعملية $T_{total}$ بمجموع وقت الحوسبة بواسطة وحدة المعالجة المركزية $T_{compute}$ ووقت إدخال/إخراج القرص $T_{io}$.

$$ T_{total} = T_{compute} + T_{io} $$

في حالة WSL1، يتم تكبد عبء لتحويل عمليات جانب لينكس إلى عمليات NTFS، لذلك يتم نمذجة وقت الإدخال/الإخراج على النحو التالي. هنا، $n$ هو عدد عمليات الملفات، و $t_{ntfs\_syscall}$ هو وقت تنفيذ استدعاء النظام على جانب ويندوز، و $t_{trans}$ هو عبء طبقة الترجمة.

$$ T_{wsl1\_io} = \sum_{i=1}^{n} (t_{ntfs\_syscall_i} + t_{trans_i}) $$

من ناحية أخرى، في حالة WSL2، تُصدر النواة (Kernel) عمليات الإدخال/الإخراج مباشرة إلى نظام ملفات ext4، لذلك يكون العبء عبارة عن تأخير طفيف جداً بسبب المحاكاة الافتراضية $t_{virt}$ فقط.

$$ T_{wsl2\_io} = \sum_{i=1}^{n} (t_{ext4_i} + t_{virt_i}) $$

في أنظمة الملفات العامة، بما أن $t_{ext4} \ll t_{ntfs\_syscall} + t_{trans}$، فإنه عندما يكون $n$ كبيرًا جدًا (إجراء عشرات الآلاف إلى مئات الآلاف من عمليات الملفات)، يتسع الفارق في وقت الإدخال/الإخراج بين WSL1 و WSL2 بشكل أُسّي.

بالإضافة إلى ذلك، إذا كانت نسبة عبء حساب وحدة المعالجة المركزية (CPU) في البيئة الافتراضية هي $\rho$، فإن المحاكاة الافتراضية الحديثة المدعومة بالأجهزة (Intel VT-x / AMD-V) ستبقيها عند حوالي $\rho \approx 0.01 \sim 0.03$ (1 إلى 3٪). وبالتالي، حتى في مهام الحساب البحتة، يتم تحقيق أداء بنسبة $97\% \sim 99\%$، وهو ما يمكن مقارنته ببيئة لينكس الأصلية (Native).

3. التثبيت وبناء الأساس

على أنظمة التشغيل Windows 10/11، أصبح تثبيت WSL2 بسيطًا للغاية. افتح PowerShell بصلاحيات المسؤول وقم بتنفيذ الأمر التالي.

1
2
3
4
5
6


# سيتم تثبيت WSL2 و Ubuntu بشكل افتراضي
wsl --install

# لتحديد توزيعة معينة
# يمكن التحقق منها باستخدام wsl --list --online
wsl --install -d Ubuntu-24.04

بعد التثبيت وإعادة التشغيل، سيُطلب منك إعداد اسم مستخدم UNIX وكلمة مرور عند بدء التشغيل لأول مرة. هذا المستخدم مستقل عن مستخدم ويندوز ويكون صالحًا فقط داخل WSL.

إذا كنت تستخدم WSL1 بالفعل، فقم بالتحويل إلى WSL2 باستخدام الأوامر التالية.

1
2
3
4
5


# تحويل توزيعة موجودة إلى WSL2
wsl --set-version Ubuntu 2

# تعيين WSL2 كإصدار افتراضي للتوزيعات التي ستضاف مستقبلاً
wsl --set-default-version 2

4. أسرار التحكم في الموارد: .wslconfig و wsl.conf

أحد أكبر فخاخ WSL2 هو “الاستهلاك غير المحدود للذاكرة (تضخم عملية Vmmem)”. نظرًا لأن WSL2 يستخدم ذاكرة التخزين المؤقت للصفحات (Page cache) الخاصة بنواة لينكس، فإنه سيستهلك ذاكرة المضيف (ويندوز) بلا حدود في كل مرة يتم فيها إجراء إدخال/إخراج (I/O). لمنع ذلك، من الضروري تقييد الموارد باستخدام ملفات الإعدادات.

تنقسم ملفات إعدادات WSL2 إلى قسمين: .wslconfig الذي يؤثر على نظام ويندوز بأكمله، و wsl.conf الذي يؤثر على التوزيعة الفردية من الداخل.

4.1. .wslconfig (جانب ويندوز)

قم بإنشاء ملف في مجلد ملف تعريف مستخدم ويندوز الخاص بك (C:\Users\<اسم المستخدم>\.wslconfig) للتحكم في تخصيص الموارد للجهاز الافتراضي (VM).

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28


# C:\Users\<اسم المستخدم>\.wslconfig
[wsl2]
# أقصى قدر من الذاكرة المخصصة للجهاز الافتراضي. يوصى بنسبة 50% إلى 75% من إجمالي ذاكرة المضيف
memory=16GB

# عدد نوى وحدة المعالجة المركزية (CPU) المراد استخدامها (إذا تم حذفها، يتم استخدام جميع النوى)
processors=8

# حجم ملف التبادل (Swap file)
swap=8GB

# وجهة حفظ ملف التبادل (إذا كنت ترغب في توفير مساحة على محرك الأقراص C)
# swapfile=D:\\wsl\\swap.vhdx

# تمكين إعادة توجيه localhost (للوصول إلى WSL من جانب ويندوز باستخدام localhost)
localhostForwarding=true

# تحرير الذاكرة تلقائيًا (نظام التشغيل Windows 11 فقط)
# يحرر ذاكرة التخزين المؤقت للصفحات ديناميكيًا ويمنع تضخم Vmmem
autoMemoryReclaim=dropcache

[experimental]
# ميزات الشبكات المتقدمة المتاحة في Windows 11 إصدار 22H2 وما بعده
# يتيح هذا دعم IPv6 ومشاركة نفس عنوان IP بين WSL وويندوز
networkingMode=mirrored
dnsTunneling=true
firewall=true
autoProxy=true

4.2. wsl.conf (جانب لينكس)

قم بتحرير /etc/wsl.conf داخل WSL للتحكم في السلوك الخاص بالتوزيعة.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24


# /etc/wsl.conf (تم التحرير داخل WSL)
[network]
# تعطيل إنشاء ملف /etc/resolv.conf التلقائي عند بدء تشغيل WSL
# مفيد عندما تريد إعداد DNS خاص بك (مثال: 8.8.8.8)
generateResolvConf=false

# تعيين اسم مضيف (hostname) مخصص
hostname=WSL-DevNode

[automount]
# الإعدادات عند تركيب محركات أقراص ويندوز (Mounting)
enabled=true
options="metadata,uid=1000,gid=1000,umask=022"
# تغيير نقطة تركيب محرك الأقراص C من /mnt/c إلى /c (لتقصير المسار)
root=/

[boot]
# تمكين systemd (في WSL إصدار 0.67.6 وما بعده)
# يتيح هذا لـ snap والبرامج الخفية (daemons) المتنوعة (مثل Docker) العمل محليًا
systemd=true

[user]
# المستخدم الذي سيتم تسجيل الدخول به افتراضيًا
default=kenji

لتطبيق هذه الإعدادات، تحتاج إلى تشغيل wsl --shutdown في PowerShell لإيقاف تشغيل جهاز WSL الافتراضي بالكامل قبل إعادة تشغيله.

5. بيئة الطرفية المطلوبة: Zsh + Powerlevel10k

لن تتحسن إنتاجيتك مع بقاء bash الافتراضي. سنقوم ببناء أقوى موجه أوامر (Prompt) من خلال الجمع بين Zsh، الذي يتميز بوظائف إكمال قوية وإمكانيات رؤية واضحة، مع السمة (Theme) فائقة السرعة “Powerlevel10k”.

5.1. تثبيت وإعداد Windows Terminal

قم بتثبيت “Windows Terminal” من متجر Microsoft. افتح إعدادات JSON (settings.json)، واضبط ملف التعريف (Profile) الافتراضي على WSL (Ubuntu)، وقم بتغيير الخط إلى خط Nerd مخصص للتطوير (مثال: HackGen Console NF أو MesloLGS NF).

5.2. تثبيت Zsh و Oh My Zsh

قم بتنفيذ الأوامر التالية في محطة طرفية لـ WSL.

1
2
3
4
5
6


# تحديث الحزم وتثبيت Zsh
sudo apt update && sudo apt upgrade -y
sudo apt install -y zsh git curl

# تنفيذ برنامج نصي (Script) لتثبيت Oh My Zsh
sh -c "$(curl -fsSL https://raw.githubusercontent.com/ohmyzsh/ohmyzsh/master/tools/install.sh)"

5.3. تقديم Powerlevel10k والإضافات (Plugins)

قم بتثبيت الإضافات لتعزيز Zsh (تسليط الضوء على بناء الجملة والإكمال التلقائي للإدخال) وسمة Powerlevel10k.

1
2
3
4
5
6
7
8


# Powerlevel10k
git clone --depth=1 https://github.com/romkatv/powerlevel10k.git ${ZSH_CUSTOM:-$HOME/.oh-my-zsh/custom}/themes/powerlevel10k

# zsh-autosuggestions
git clone https://github.com/zsh-users/zsh-autosuggestions ${ZSH_CUSTOM:-~/.oh-my-zsh/custom}/plugins/zsh-autosuggestions

# zsh-syntax-highlighting
git clone https://github.com/zsh-users/zsh-syntax-highlighting.git ${ZSH_CUSTOM:-~/.oh-my-zsh/custom}/plugins/zsh-syntax-highlighting

قم بتحرير ~/.zshrc وتمكين السمة والإضافات.

1
2
3
4
5


# التغييرات في ~/.zshrc
ZSH_THEME="powerlevel10k/powerlevel10k"

# أضفه إلى مصفوفة الإضافات (plugins)
plugins=(git zsh-autosuggestions zsh-syntax-highlighting)

عندما تقوم بالحفظ وتشغيل source ~/.zshrc، سيبدأ معالج إعداد Powerlevel10k (p10k configure). اتبع التعليمات التي تظهر على الشاشة لتخصيص موجه الأوامر (Prompt) حسب رغبتك (نمط الموجه، وجود الرموز من عدمها، المعلومات التي سيتم عرضها، إلخ). سيتم عرض أسماء فروع Git وحالتها، وإصدار Node.js، ووقت تنفيذ الأوامر، وما إلى ذلك في الوقت الفعلي، مما يؤدي إلى زيادة كفاءة التطوير بشكل كبير.

6. VS Code Remote - تكامل سلس مع WSL

عند التطوير في WSL2، توفر إضافة “Remote - WSL” آلية للوصول السلس إلى الملفات داخل WSL من بيئة التطوير المتكاملة (Visual Studio Code) المثبتة على جانب ويندوز.

شرح البنية المعمارية

يوضح مخطط التسلسل (Sequence diagram) التالي كيف يتصل VS Code مع WSL2.

sequenceDiagram
autonumber
participant U as "المطور"
participant V as "واجهة مستخدم VS Code (ويندوز)"
participant S as "خادم VS Code (WSL2)"
participant F as "نظام ملفات ext4 (WSL2)"
U->>V: "كتابة `code .` في محطة WSL"
V->>S: "إنشاء اتصال RPC عبر Vsock"
Note over V,S: الاتصال باستخدام مآخذ Hyper-V بدلاً من TCP/IP
S->>F: "قراءة الملفات المصدرية / تشغيل أداة التحقق (Linter)"
F-->>S: "إرجاع البيانات والتحليل"
S-->>V: "بث نتائج خادم اللغة (Language Server) إلى واجهة المستخدم"
V-->>U: "عرض تمييز بناء الجملة (syntax highlighting) والأخطاء"

يعمل VS Code على جانب ويندوز كمجرد “عميل خفيف (واجهة مستخدم)"، وتتم معالجة جميع المهام الثقيلة مثل خادم اللغة (Language Server)، والمصحح (Debugger)، وتنفيذ المحطة الطرفية بواسطة “خادم VS Code” على جانب WSL. يتيح لك ذلك الحفاظ على نظافة البيئة الخاصة بك من خلال استخدام جانب WSL فقط، دون تثبيت Node.js أو Python على جانب ويندوز.

إعدادات VS Code الأساسية

من “الإضافات” (Extensions) في VS Code، قم بتثبيت “WSL” (ms-vscode-remote.remote-wsl). بعد ذلك، ببساطة انتقل إلى دليل المشروع في محطة WSL وقم بتنفيذ code .، وسيتم تشغيل VS Code على جانب ويندوز مع فتح ذلك الدليل.

ملاحظة هامة (مشكلة رمز نهاية السطر (Line Ending)): رموز نهاية السطر تختلف بين ويندوز ولينكس (ويندوز يستخدم CRLF، ولينكس يستخدم LF). عند التطوير على WSL، تأكد من توحيد إعداد core.autocrlf في Git وإعداد الملف الافتراضي في VS Code إلى LF. سيؤدي الفشل في القيام بذلك إلى التسبب في أخطاء غامضة عند تشغيل نصوص الصدفة (Shell scripts) أو حاويات Docker.

1
2


# إعداد رمز نهاية السطر (Line Ending) لـ Git في WSL
git config --global core.autocrlf input

أضف الإعدادات التالية إلى settings.json الخاص بـ VS Code (الإعدادات عن بُعد).

1
2
3
4


{
 "files.eol": "\n",
 "terminal.integrated.defaultProfile.linux": "zsh"
}

7. تحسين Docker Desktop وتكامله مع WSL2

هناك طريقتان رئيسيتان لاستخدام Docker في بيئة WSL2.

تثبيت Docker Desktop لنظام ويندوز وتمكين ميزة تكامل WSL2.
تثبيت محرك Docker الأصلي (Docker Engine) مباشرة داخل WSL2 (مثل Ubuntu).

النهج 1: Docker Desktop (موصى به)

يُوصى بهذا النهج غالبًا لأنه يسهل الإدارة عبر واجهة المستخدم الرسومية (GUI) والوصول الشفاف إلى الحاويات (Containers) بين ويندوز و WSL. تحقق من التالي في إعدادات Docker Desktop (Settings).

في General -> ضع علامة اختيار على Use the WSL 2 based engine.
في Resources -> WSL Integration -> ضع علامة اختيار على Enable integration with my default WSL distro، وقم بتشغيل مفتاح التبديل للتوزيعة التي تستخدمها (Ubuntu).

يسمح لك ذلك بتنفيذ أوامر docker مباشرة من محطة WSL2، ويتم الاتصال ببرنامج Docker الخفي (Daemon) من خلال أجهزة افتراضية خفيفة الوزن مخصصة يديرها Docker Desktop (docker-desktop و docker-desktop-data).

النهج 2: التثبيت المباشر لمحرك Docker الأصلي (Native Docker Engine)

إذا كان هناك قيود على شبكة الشركة (مثل تجنب الإصدار المدفوع من Docker Desktop) أو كنت ترغب في تقليل عبء الأداء إلى أدنى حد ممكن، فقم بتمكين systemd في /etc/wsl.conf وقم بتثبيت Docker كخادم Ubuntu نقي.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


# مقتطف من خطوات التثبيت الرسمية لـ Docker في WSL2 Ubuntu مع تفعيل systemd
sudo apt-get update
sudo apt-get install ca-certificates curl gnupg
sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
sudo chmod a+r /etc/apt/keyrings/docker.gpg

# إضافة المستودع (Repository)
echo \
 "deb [arch="$(dpkg --print-architecture)" signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \
 "$(. /etc/os-release && echo "$VERSION_CODENAME")" stable" | \
 sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

sudo apt-get update
sudo apt-get install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

# إضافة المستخدم الحالي إلى مجموعة docker (للتشغيل بدون sudo)
sudo usermod -aG docker $USER

بعد إعادة التشغيل، سيعمل systemctl start docker تمامًا كما هو الحال في بيئة لينكس الأصلية، مما يوفر أداءً عاليًا.

8. تكامل مفاتيح SSH: المصادقة السلسة بين ويندوز و WSL

تعد إدارة مفاتيح SSH المنفصلة على ويندوز و WSL لاستنساخ Git (Git clone) عبر SSH أو الاتصال بخوادم عن بُعد عبر SSH مهمة شاقة جدًا. لتحقيق التوازن بين الأمان والراحة، سنقوم بإعداد جسر (Bridge) لوكيل SSH (SSH Agent) الذي يعمل على جانب ويندوز (أو مدير كلمات مرور مثل 1Password) إلى جانب WSL.

هنا، سنشرح الطريقة الأكثر أمانًا وحداثة باستخدام ميزة وكيل SSH في 1Password أو وكيل مصادقة OpenSSH في ويندوز (OpenSSH Authentication Agent)، وإعادة توجيهها إلى مقبس نطاق UNIX (UNIX domain socket) الخاص بـ WSL2 باستخدام npiperelay أو socat.

إعادة توجيه المقبس (Socket Forwarding) لوكيل ssh-agent

عادة، يجب تحويل وكيل SSH المقدم كأنبوب مسمى (Named Pipe) في ويندوز إلى ملف مقبس (Socket file) على جانب WSL. من السهل استخدام wsl-ssh-agent أو الميزات المقدمة من 1Password.

من شاشة إعدادات 1Password، قم بتمكين “Developer” (المطور) -> “Use SSH agent” (استخدام وكيل SSH). بعد ذلك، أضف الإعدادات التالية إلى ~/.zshrc أو ~/.bashrc على جانب WSL لربط المقبس (Socket bind) تلقائيًا عند تسجيل الدخول.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


# إضافة إلى ~/.zshrc (مثال عند استخدام وكيل SSH الخاص بـ 1Password)
export SSH_AUTH_SOCK=$HOME/.ssh/agent.sock
# إذا لم يكن المقبس موجودًا عند بدء تشغيل WSL، أو إذا لم تكن العملية مرتبطة (bind)، فاستخدم socat و npiperelay لإعادة التوجيه (forward)
ALREADY_RUNNING=$(ps -aux | grep "[n]piperelay.exe -ei -s //./pipe/openssh-ssh-agent" | wc -l)
if [ $ALREADY_RUNNING -eq 0 ]; then
 if [ -S $SSH_AUTH_SOCK ]; then
 rm $SSH_AUTH_SOCK
 fi
 # تشغيل socat في الخلفية وتوصيل الأنبوب المسمى (Named Pipe) لجانب ويندوز بمقبس UNIX لجانب WSL
 (setsid socat UNIX-LISTEN:$SSH_AUTH_SOCK,fork EXEC:"npiperelay.exe -ei -s //./pipe/openssh-ssh-agent",nofork &) >/dev/null 2>&1
fi

※يتطلب هذا تثبيت npiperelay.exe وإضافته إلى المسار (Path) على جانب ويندوز مسبقًا.

بمجرد اكتمال هذا الإعداد، عند تشغيل ssh-add -l من محطة WSL، سيتم عرض قائمة بالمفاتيح العامة (Public keys) المسجلة في 1Password أو على جانب ويندوز. يتيح لك هذا اجتياز المصادقة بأمان دون الحاجة إلى نسخ ملفات المفاتيح الخاصة (Private keys) إلى WSL.

9. الصيانة: تحسين (ضغط) ملفات VHDX المتضخمة

أحد أكبر عيوب WSL2 هو أن “حجم ملف القرص الافتراضي على جانب ويندوز (.vhdx) لا يتقلص تلقائيًا حتى لو قمت بحذف صور Docker أو الملفات”. إذا واصلت التطوير لفترة طويلة، سيتضخم ملف ext4.vhdx إلى عشرات أو مئات الجيجابايت.

لتحرير مساحة على القرص، يجب عليك تحسين (Compact) ملف VHDX من جانب ويندوز بانتظام.

أولاً، قم بإيقاف تشغيل WSL بالكامل.
1

wsl --shutdown
افتح PowerShell بصلاحيات المسؤول، وقم بتنفيذ أمر diskpart أدناه، أو أمر Optimize-VHD من وحدة Hyper-V (يمكن استخدام الأخير فقط إذا تم تمكين Hyper-V).

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


# إذا كانت وحدة Hyper-V متاحة
Optimize-VHD -Path "$env:LOCALAPPDATA\Packages\CanonicalGroupLimited.Ubuntu_79rhkp1fndgsc\LocalState\ext4.vhdx" -Mode Full

# في حالة استخدام diskpart
diskpart
# أدخل بشكل تفاعلي داخل الموجه التالي
DISKPART> select vdisk file="C:\Users\<اسم المستخدم>\AppData\Local\Packages\CanonicalGroupLimited.Ubuntu_79rhkp1fndgsc\LocalState\ext4.vhdx"
DISKPART> attach vdisk readonly
DISKPART> compact vdisk
DISKPART> detach vdisk
DISKPART> exit

من خلال إجراء هذه العملية بانتظام، يمكنك استعادة المساحة المستهلكة بلا داعٍ على محرك الأقراص C.

10. خاتمة

لقد تجاوز WSL2 تمامًا إطار كونه مجرد “لينكس إضافي يعمل على ويندوز”، وتطور ليصبح منصة تطوير قوية لا تقل أهمية عن نظام MacOS أو أجهزة لينكس الأصلية (Native)، بل وربما تتفوق عليها.

من خلال تطبيق جميع الإعدادات الموضحة في هذا الدليل (تحسين الموارد باستخدام .wslconfig، وتحسين المحطة الطرفية (Terminal) باستخدام Zsh + Powerlevel10k، والوصول الشفاف باستخدام VS Code Remote، بالإضافة إلى دمج SSH وصيانة VHDX)، ستحصل على “بيئة تطوير مطلوبة” خالية من التوتر، سريعة، وآمنة.

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