أعماق الافتراضيّة في Windows（الجزء 3）── آلات افتراضيّة تقلع في ثوانٍ: لماذا WSL2 وWindows Sandbox والحاويات خفيفة هكذا

عندما تُنشئ آلة افتراضيّة Windows في Hyper-V Manager، يستغرق بدؤها عشرات الثواني وتحتكر عدّة غيغابايت من الذاكرة. لكن على الحاسوب نفسه، كتابة wsl تُرجع صدفة Linux خلال بضع ثوانٍ، ويفتح Windows Sandbox سطح مكتب قابلاً للرمي في بضع ثوانٍ أيضاً.¹

كلاهما يستند إلى hypervisor Windows نفسه (الجزء 1، «أين يعمل Windows فعليّاً؟»). في الجزء 2 رأينا أنّ هذا الأساس يستطيع إنشاء عزل أقوى من النواة. فلماذا أحدهما ثقيل والآخر خفيف؟

السؤال الذي يجيب عنه الجزء الأخير من السلسلة واحد فقط.

الآلات الافتراضيّة الكاملة ثقيلة ── فلماذا WSL2 وWindows Sandbox خفيفان هكذا؟

القرّاء المستهدَفون مطوِّرون ومشغِّلون يستخدمون WSL2 وWindows Sandbox وحاويات Windows للتطوير والتحقّق، ويريدون فهم خفّتها وقيودها من الآليّات صعوداً. المتطلّبات هي Windows 10/11؛ المرور بقسم Windows Sandbox يتطلّب إصدار Pro أو Enterprise أو Education (Home وWindows Server لا يملكان هذه الميزة). معرفة الخلفيّة هي مفهوم الأقسام من الجزء 1. الصعوبة متوسّطة.

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

تُبقي آلة افتراضيّة خفيفة خطّ العزل（نواة مخصَّصة وحدّ hypervisor）وتخفِّف «نسخة نظام تشغيل ضيف كاملة». يشارك Sandbox Windows المضيف نفسه؛ ويستبدل WSL2 الضيف بـ Linux صغير مبنيّ لغرضه؛ وفي الحالتين ليست الذاكرة حجزاً ثابتاً بل إعارة واستعارة ديناميّة مع المضيف.

مصدر ثقل آلة افتراضيّة كاملة ليس العزل نفسه بل التكرار. صورة نظام تشغيل أخرى على القرص، صفحات بقدر نظام تشغيل آخر في RAM، وإقلاع كامل آخر في كلّ مرّة تبدأ. تقطع الآلات الافتراضيّة الخفيفة ذلك التكرار بسياستين: «شارك ما هو آمن للمشاركة» (Sandbox) و«إن لم تستطع مشاركته، أعد بناءه صغيراً» (WSL2).

flowchart TB
    accTitle: ثلاثة أنواع من المشاركة تدعم الآلات الافتراضيّة الخفيفة
    accDescr: صورة نظام التشغيل التي كانت آلة افتراضيّة كاملة تكرِّرها تُقطَع بالمشاركة في Sandbox وبالتقليص في WSL2؛ الذاكرة التي هي تخصيص ثابت افتراضيّاً（الذاكرة الديناميّة هي الاستثناء）تصبح إعارة واستعارة ديناميّة مع المضيف؛ يُستبدَل البدء بنواة خفيفة وإعداد أدنى؛ حدّ العزل وحده يبقى
    heavy["آلة افتراضيّة كاملة: تكرار"] --> d1["القرص: نسخة صورة نظام تشغيل"]
    heavy --> more{"ذاكرة أم بدء؟"}
    more --> d2["الذاكرة: ثابت افتراضيّاً"]
    more --> d3["البدء: إقلاع كامل"]
    d1 -->|يُستبدَل بـ| s1["مشاركة（Sandbox）"]
    s1 -.-> s1b["أو تقليص（WSL2）"]
    d2 -->|يُستبدَل بـ| s2["إعارة ديناميّة من المضيف"]
    d3 -->|يُستبدَل بـ| s3["نواة خفيفة + أدنى"]

الشكل 1: هيكل الجواب على «الـ hypervisor نفسه، ومع ذلك خفيف» هو أنّهم توقّفوا عن التكرار، لا عن العزل.

أدناه ننظر إلى WSL2 وWindows Sandbox والحاويات بهذا الترتيب، وإلى أيّ نوع من التكرار يقطعه كلّ منها.

2. ما الذي تحمله آلة افتراضيّة كاملة

كخطّ أساس للمقارنة، إليك ما تحمله آلة افتراضيّة تقليديّة.

• صورة نظام تشغيل مستقلّة. تحتفظ بكلّ ملفّات نظام تشغيل الضيف داخل قرص افتراضيّ. حتّى إن كان للمضيف Windows نفسه، لا يشاركه.
• تخصيص ذاكرة خشن. افتراضيّ آلة افتراضيّة تقليديّة هو تخصيص ذاكرة المضيف بحجم ثابت. آليّات مثل Hyper-V Dynamic Memory تستطيع تنمية التخصيص وانكماشه ضمن نطاق مضبوط، لكن وسائل التكيّف مع تغيّرات الطلب محدودة.²
• إقلاع كامل عامّ الغرض. يبدأ البرنامج الثابت ومحمِّل الإقلاع ومجموعة الخدمات بالتسلسل نفسه كما على جهاز فيزيائيّ.

flowchart TB
    accTitle: الأحمال الثلاثة التي تحملها آلة افتراضيّة كاملة
    accDescr: تحمل آلة افتراضيّة كاملة صورة نظام تشغيل مستقلّة، وتخصيص ذاكرة ثابت افتراضيّاً، وإقلاعاً كاملاً عامّ الغرض، وتظهر تلك تكاليف في القرص وRAM وزمن البدء
    fullvm["آلة افتراضيّة كاملة"] --> b1["صورة نظام تشغيل مستقلّة"]
    fullvm --> more{"ذاكرة أم إقلاع؟"}
    more --> b2["ذاكرة ثابتة افتراضيّاً"]
    more --> b3["إقلاع عامّ الغرض"]
    b1 -.-> c1["قرص إضافيّ لنسخة"]
    b2 -.-> c2["تحتجز RAM غير مستخدَمة أيضاً"]
    b3 -.-> c3["يستغرق عشرات الثواني"]

الشكل 2: تفصيل تكلفة آلة افتراضيّة كاملة يُدفَع لا للعزل بل للعموميّة والتكرار.

هذه ليست عيوباً؛ إنّها ثمن العموميّة أنّ «يمكنك وضع أيّ شيء في الضيف». لاستخدام مثل تشغيل Linux قديم بجانب Windows Server، تلك العموميّة هي القيمة. لكن لاستخدام مثل «أريد تشغيل نظام التشغيل نفسه (أو مقرَّر) كالمضيف، الآن، للتطوير أو التحقّق»، معظمها أمتعة مهدورة. تضع الآلات الافتراضيّة الخفيفة تلك الأمتعة جانباً بتضييق الغرض.

3. WSL2 ── آلة افتراضيّة خدميّة بنواة مبنيّة لغرضها

3.1. البنية: آلة افتراضيّة مُدارة والتوزيعات داخلها

WSL2 آليّة تشغِّل نواة Linux أصيلة داخل آلة افتراضيّة خدميّة خفيفة.³ ثمّة ثلاث نقاط.

• النواة أصيلة، لكنّها منتج متخصِّص. هي نواة Linux تبنيها Microsoft من فرع Stable، مضبوطة أصلاً حجماً وأداءً لـ WSL2. على المعيار الحاليّ، WSL الموزَّع عبر Microsoft Store، تُحدَّث النواة مع حزمة WSL نفسها وتُطبَّق بـwsl --update (على التوزيع الأقدم داخل الصندوق كانت تأتي عبر Windows Update).⁴ لأنّها نواة أصيلة، توافق استدعاءات النظام كامل، وتعمل أدوات مثل Docker كما هي.
• الآلة الافتراضيّة خلف الكواليس. إنشاء الآلة الافتراضيّة وبدءها وإيقافها تديره WSL؛ المستخدم يفتح صدفة فحسب. لا شاشة إعدادات آلة افتراضيّة ولا انتظار إقلاع ملموس.⁴
• التوزيعة حاوية داخل الآلة الافتراضيّة. تعمل توزيعات مثل Ubuntu وDebian حاويات معزولة داخل آلة افتراضيّة مُدارة واحدة. تشارك مساحة أسماء الشبكة والنواة، بينما تُفصَل مساحات أسماء مثل PID وmount وuser.³

flowchart TB
    accTitle: معماريّة WSL2
    accDescr: يجلس Windows مضيف وآلة افتراضيّة خدميّة خفيفة جنباً إلى جنب على الـ hypervisor؛ تعمل نواة Linux تبنيها Microsoft داخل الآلة الافتراضيّة؛ وتعمل كلّ توزيعة حاويةً معزولة داخل ذلك
    hv["الـ hypervisor"] --> host["Windows المضيف"]
    hv --> uvm["آلة افتراضيّة خدميّة خفيفة"]
    uvm --> lk["نواة Linux（بناء Microsoft؛ تُحدَّث بـ wsl --update）"]
    lk --> u1["Ubuntu（حاوية）"]
    lk --> u2["Debian（حاوية）"]
    host <-->|"Interop（أوامر، ملفّات، شبكة）"| uvm

الشكل 3: جواب «هل WSL2 آلة افتراضيّة؟» هو «نعم، لكن آلة افتراضيّة مُدارة خلف الكواليس»، وحتّى إن ثبَّتَّ عدّة توزيعات ما زالت ثمّة آلة افتراضيّة واحدة.

لحظة كتابة wsl، يبدو الجانب الخلفيّ هكذا.

flowchart TB
    accTitle: من تشغيل أمر wsl إلى عودة صدفة في بضع ثوانٍ
    accDescr: إن لم تكن الآلة الافتراضيّة الخدميّة تعمل عند تنفيذ wsl، تبدأ الآلة الافتراضيّة الخفيفة ونواة Linux؛ إن كانت تعمل أصلاً يُعاد استخدامها؛ وتعود صدفة داخل حاوية التوزيعة
    cmd["شغِّل wsl"] --> vmq{"هل الآلة الافتراضيّة الخدميّة تعمل أصلاً؟"}
    vmq -->|لا| bootvm["ابدأ الآلة الافتراضيّة الخفيفة ونواة Linux（بضع ثوانٍ）"]
    vmq -->|نعم| reuse["أعد استخدام الآلة الافتراضيّة العاملة"]
    bootvm --> shell["تعود صدفة داخل الحاوية"]
    reuse --> shell

الشكل 4: الانتظار هو بدء آلة افتراضيّة أدنى فقط، وهنا يظهر وضع أمتعة الإقلاع الكامل جانباً.

3.2. إدخال/إخراج الملفّات: الجانب الذي تضعه فيه يجعله شيئاً مختلفاً

الموضوع الذي يظهر دائماً في حديث أداء WSL2 هو أين تضع الملفّات.

• عمليّات الملفّات في جانب Linux (القرص الافتراضيّ ext4) سريعة. ذلك لأنّ نواة Linux تتحدّث إلى نظام ملفّاتها مباشرةً، وقد أُبلِغ عن تسريعات تصل إلى 20 ضعفاً مقابل WSL1 لاستخراج tarball، و2–5 أضعاف لـgit clone وnpm install.⁴
• عمليّات الملفّات في جانب Windows (/mnt/c وما شابه) تصبح بطيئة لأنّها تمرّ بمشاركة ملفّات تعبر حدّ نظام تشغيل. أداء نظام الملفّات عبر أنظمة التشغيل هو البند الكبير الوحيد الذي يكون فيه WSL2 أسوأ من WSL1.⁴

لذا القاعدة هي: «ضع ملفّات المشروع في جانب نظام التشغيل نفسه الذي تستخدمه الأدوات التي تعمل عليها».⁴ مستودع تتعامل معه بأدوات بناء Linux يذهب إلى جانب Linux؛ حلّ تبنيه في Visual Studio يذهب إلى جانب Windows.

flowchart TB
    accTitle: تفرع مسارات إدخال/إخراج ملفّات WSL2
    accDescr: الوصول إلى القرص الافتراضيّ ext4 في جانب Linux مباشر من نواة Linux ولذلك سريع؛ الوصول إلى ملفّات جانب Windows يمرّ بمشاركة تعبر حدّ نظام تشغيل ولذلك بطيء
    io["عمليّات ملفّات داخل WSL2"] --> place{"في أيّ جانب الملفّ؟"}
    place -->|"جانب Linux（home وغيرها）"| ext4["إدخال/إخراج مباشر إلى قرص ext4 الافتراضيّ"]
    place -->|"جانب Windows（/mnt/c وغيرها）"| p9["عبر مشاركة تعبر حدّ نظام تشغيل"]
    ext4 --> fast["سريع（أمثلة تصل إلى 20 ضعفاً مقابل WSL1）"]
    p9 --> slow["يميل إلى البطء"]
    slow -.-> fix["الإصلاح: ضع الملفّ على نظام التشغيل الذي يستخدمه"]

الشكل 5: ما هو بطيء هو المسار، لا WSL2، لذا تغيير أين تضع الملفّات غالباً يجعل مشكلة الأداء تختفي.

3.3. الذاكرة: تنمو، وتنكمش، لكنّها لا تعيد كلّ شيء دائماً

استخدام ذاكرة WSL2 (تراه عمليّة vmmem في مدير المهام) ليس حجزاً ثابتاً؛ إنّه ينمو وينكمش مع الاستخدام. الذاكرة التي أطلقتها العمليّات تُعاد تلقائيّاً إلى Windows تحت إعداد pageReporting، المفعَّل افتراضيّاً.⁵ الصفحات المحتفَظ بها ذاكرة تخزين مؤقّت للملفّات كانت لا تعود إلى Windows حتّى تخرج الآلة الافتراضيّة.⁴ في WSL الحاليّ، إعداد .wslconfig التجريبيّ autoMemoryReclaim (الافتراضيّ هو dropCache) يستعيد التخزين المؤقّت تلقائيّاً أيضاً.⁵ في بيئات يكون فيها هذا الإعداد disabled، أو على WSL أقدم، يمكن أن يبقى تخزين مؤقّت جلسة طويلة حتّى تخرج الآلة الافتراضيّة ويضغط ذاكرة المضيف.

flowchart TB
    accTitle: كيف تنمو ذاكرة WSL2 وتنكمش وتُعاد
    accDescr: نموّ الطلب داخل WSL2 يرفع استخدام ذاكرة الآلة الافتراضيّة؛ الصفحات التي أطلقتها العمليّات تُعاد إلى Windows تحت pageReporting المفعَّل افتراضيّاً؛ يستعيد autoMemoryReclaim التخزين المؤقّت للملفّات تلقائيّاً افتراضيّاً؛ لكن على إعداد معطَّل أو WSL أقدم يبقى حتّى تخرج الآلة الافتراضيّة، وwsl --shutdown يعيد كلّ شيء
    grow["ينمو طلب الذاكرة داخل WSL2"] --> vm["ينمو استخدام vmmem"]
    vm --> freed{"هل أُطلِقت تلك الصفحة؟"}
    freed -->|"أطلقتها عمليّة（عندما pageReporting مفعَّل）"| ret["تُعاد تلقائيّاً إلى Windows"]
    freed -->|محتفَظ بها تخزيناً مؤقّتاً للملفّات| amr["يستعيدها autoMemoryReclaim تلقائيّاً（افتراضيّ）"]
    amr -.-> old2["على إعداد معطَّل أو WSL أقدم، تبقى حتّى تخرج الآلة الافتراضيّة"]
    old2 --> sd["wsl --shutdown يعيد كلّ شيء"]

الشكل 6: ما يبدو «لم تتوقّف عن النموّ» هو أساساً التخزين المؤقّت (وعندما يكون pageReporting معطَّلاً، الصفحات التي أطلقتها العمليّات أيضاً)، فاعرف مسار الإعادة قبل أن تقرِّر أنّه تسرّب.

إذا أردت حدّاً أعلى صريحاً، يمكن لـ%UserProfile%\.wslconfig التحكّم بذاكرة الآلة الافتراضيّة الكلّيّة وعدد المعالجات وswap.⁵

# %UserProfile%\.wslconfig
[wsl2]
memory=8GB
processors=4
swap=2GB

بعد تغيير الإعدادات، أعد تشغيل الآلة الافتراضيّة بـwsl --shutdown حتّى تسري. هذا التخصيص الديناميّ ── «الحدّ الأعلى إعداد، والاستخدام الفعليّ يتبع الطلب» ── يُؤخَذ أبعد في الموضوع التالي، Windows Sandbox.

4. Windows Sandbox ── إعادة استخدام Windows المضيف

4.1. صورة أساسيّة ديناميّة: Windows كامل في 500 ميغابايت

Windows Sandbox سطح مكتب Windows قابل للرمي معزول بالـ hypervisor. أغلقه فيختفي كلّ شيء؛ في المرّة التالية، يبدأ في بضع ثوانٍ من حالة نظيفة.¹

اللغز الأوّل هو القرص. يستطيع إقلاع Windows كامل، ومع ذلك صورة Sandbox الأساسيّة نحو 500 ميغابايت فقط بعد التثبيت، و30 ميغابايت مضغوطة وقت التوزيع.² السرّ هو الصورة الأساسيّة الديناميّة.

• معظم ملفّات نظام التشغيل غير قابلة للتغيير، لذا يمكن مشاركة نُسَخ المضيف كما هي.
• العدد الصغير من الملفّات القابلة للتغيير لا يمكن مشاركته، لذا تُحفَظ نسخة نظيفة منها داخل الصورة الأساسيّة.
• عند البدء، تُجمَع ملفّات المضيف غير القابلة للتغيير زائد النُسَخ المحلّيّة للملفّات القابلة للتغيير لتجميع صورة Windows كاملة.²

بعبارة أخرى، لا ينزِّل Sandbox نسخة من Windows ولا يخزِّنها؛ إنّه يعيد استخدام Windows المثبَّت أصلاً على المضيف للبدء.

flowchart TB
    accTitle: كيف تُجمَّع صورة أساسيّة ديناميّة
    accDescr: تُشارَك ملفّات نظام التشغيل غير القابلة للتغيير من Windows المضيف؛ الملفّات القابلة للتغيير وحدها تُحفَظ نسخة نظيفة في الصورة الأساسيّة؛ ويُجمَع الاثنان لتجميع صورة Windows الكاملة لـ Sandbox
    hostw["Windows الكامل للمضيف"] --> imm["ملفّات نظام تشغيل غير قابلة للتغيير（الأغلبيّة）"]
    hostw --> mut["ملفّات نظام تشغيل قابلة للتغيير（أقلّيّة）"]
    imm -->|تُشارَك كما هي| img["صورة إقلاع Sandbox"]
    mut -->|احتفظ بنسخة نظيفة| img
    img --> boot["تقلع Windows كاملاً"]
    img -.-> size["نحو 500 ميغابايت فقط تحتاج إلى التخزين"]

الشكل 7: شكل التخلّي عن تكرار القرص ليس «امتلك Windows آخر» بل «جمِّعه من Windows المضيف».

ذلك التركيب هو ما يجعل دورة الحياة التالية ممكنة. ما يُرمى هو الحالة المحلّيّة داخل Sandbox. إذا كنت قد ربطت مجلّداً قابلاً للكتابة من المضيف في ملفّ إعداد .wsb، تبقى التغييرات هناك على المضيف.⁶

flowchart TB
    accTitle: دورة حياة Windows Sandbox
    accDescr: يجهِّز البدء Windows نظيفاً في بضع ثوانٍ؛ بعد التحقّق من تطبيق أو تجارب تغلقه وتُرمى كلّ الحالة داخل Sandbox لذا تبدأ المرّة التالية نظيفة أيضاً؛ لكن تغييرات مجلّد مضيف مربوط قابلاً للكتابة تبقى
    launch["ابدأ（بضع ثوانٍ）"] --> clean["Windows نظيف"]
    clean --> work["تحقّق من تطبيق أو تجارب"]
    work --> close2["أغلق"]
    close2 --> discard["ارمِ كلّ الحالة داخل Sandbox"]
    discard -.-> mapped["تغييرات مجلّد مربوط قابل للكتابة تبقى على المضيف"]
    discard -->|البدء التالي| launch

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

4.2. Direct map: الـ ntdll.dll نفسه هو الصفحة الفيزيائيّة نفسها

ليس القرص فقط بل RAM أيضاً يُشارَك. لأنّ Sandbox يشغِّل صورة نظام التشغيل نفسها كالمضيف، تُستخدَم تقنيّة تُسمَّى «direct map» بحيث، للملفّات الثنائيّة لنظام التشغيل، يستخدم صفحات الذاكرة الفيزيائيّة نفسها كالمضيف. عندما يُحمَّل ntdll.dll في الذاكرة داخل Sandbox، يشير إلى الصفحة الفيزيائيّة نفسها كالملفّ الثنائيّ نفسه المحمَّل أصلاً على المضيف. دون تعريض أسرار المضيف للخطر، يحقِّق بصمة ذاكرة أصغر بكثير من آلة افتراضيّة تقليديّة.²

«شارك الصفحة الفيزيائيّة نفسها بين عدّة مستخدمين» ── تلك هي الفكرة نفسها لمشاركة DLL عبر كائنات القسم، التي تتبّعناها في الجزء 3 من سلسلة الذاكرة («كائنات القسم والنسخ عند الكتابة»). تلك الآليّة كانت مشاركة بين العمليّات؛ يفعل Sandbox ذلك عبر حدّ آلة افتراضيّة.

flowchart TB
    accTitle: مشاركة الصفحات الفيزيائيّة عبر direct map
    accDescr: يشارك تطبيق على المضيف وتطبيقاً داخل Sandbox صفحة الذاكرة الفيزيائيّة نفسها لملفّات نظام التشغيل الثنائيّة مثل ntdll، فيقلّ استخدام الذاكرة
    happ["تطبيق على المضيف"] --> hva["عنوان افتراضيّ جانب المضيف"]
    sapp["تطبيق داخل Sandbox"] --> sva["عنوان افتراضيّ جانب Sandbox"]
    hva --> phys["الصفحة الفيزيائيّة نفسها（ملفّات ثنائيّة مثل ntdll.dll）"]
    sva --> phys
    phys -.-> save["لا حاجة لتكرار بقدر نظام تشغيل من RAM"]

الشكل 9: Direct map هي فكرة مشاركة الصفحات المستخدَمة بين العمليّات، مطبَّقة عبر حدّ آلة افتراضيّة.

4.3. إعارة الذاكرة واستعارتها: أقرب إلى عمليّة منها إلى آلة افتراضيّة

مقابل تخصيص الذاكرة الثابت لآلة افتراضيّة تقليديّة، تقرِّر تقنيّة الحاويات التي يجلس عليها Sandbox تخصيص الموارد ديناميّاً بالتعاون مع المضيف. إذا نقصت ذاكرة المضيف، يمكنه استعادة ذاكرة من الحاوية بالطريقة نفسها التي يستعيدها من عمليّة عاديّة.² تنمّي Hyper-V Dynamic Memory أيضاً تخصيص آلة افتراضيّة وتنكمشه ضمن نطاق مضبوط، لكن Sandbox يذهب أبعد: الفرق هو أنّه يعير ويستعير على الميدان نفسه كإدارة ذاكرة المضيف.

flowchart TB
    accTitle: تعاون الذاكرة بين المضيف وSandbox
    accDescr: افتراضيّ آلة افتراضيّة تقليديّة تخصيص حصريّ بحجم ثابت بوسائل تكيّف محدودة؛ يصبح Sandbox هدفاً للاستعادة استجابةً لضغط ذاكرة المضيف ويعير ويستعير ذاكرة على الميدان نفسه كالعمليّات العاديّة
    pressure["يرتفع ضغط ذاكرة المضيف"] --> from{"من أين نستعيد؟"}
    from --> proc["مجموعات عمل العمليّات العاديّة"]
    from --> sbx["استخدام Sandbox（الحاوية）"]
    proc --> relief["تُؤمَّن ذاكرة حرّة"]
    sbx --> relief
    relief -.-> contrast["لآلة افتراضيّة تقليديّة وسائل تكيّف محدودة"]

الشكل 10: في إعارة الذاكرة واستعارتها، يقف Sandbox في جانب العمليّة لا جانب الآلة الافتراضيّة، ويقدِّم ذاكرة عندما يكون المضيف في ضيق.

في الجزء 1 قلنا «أداء آلة افتراضيّة يعتمد أيضاً على جانب المضيف»، لكن مع الآلات الافتراضيّة الخفيفة نأخذ خطوة إضافيّة: تخصيص الذاكرة نفسه عمل مشترك مع المضيف. سبب إمكان استخدام Sandbox بإحساس «تطبيق آخر» لا «منتج افتراضيّة ثقيل» هو هذا التعاون.

الإجراء الملموس لاستخدام Sandbox للتحقّق من تطبيق أعمال مشروح في «كيف نستعمل Windows Sandbox لتسريع التحقّق من تطبيقات Windows» السابق. هذا المقال هو الآليّة تحت ذلك.

5. الحاويات ── أين ترسم خطّ العزل

5.1. عزل العمليّة وعزل Hyper-V

لحاويات Windows وضعا عزل وقت التشغيل. الصورة مشتركة؛ تختار بعلم عند البدء.⁷

• عزل العمليّة: تشارك عدّة حاويات النواة مع المضيف وتعزل عبر افتراضيّة لكلّ مساحة أسماء لنظام الملفّات والسجلّ ومنافذ الشبكة وفضاء معرِّف العمليّة ومساحة أسماء مدير الكائنات وغيرها. هو أساساً النهج نفسه لحاويات Linux.
• عزل Hyper-V: تعمل كلّ حاوية داخل آلة افتراضيّة عالية التحسين ولها ما هو في الواقع نواة مخصَّصة. وجود الآلة الافتراضيّة يضع عزلاً على مستوى العتاد بين الحاويات والمضيف.⁷

يمكن وصف العزل عبر مساحات الأسماء بوصفه نسخة مستفيضة من التقنيّة التي رأيناها في مقال افتراضيّة السجلّ («إعادة توجيه السجلّ والافتراضيّة على Windows») ── «أظهر واقعاً مختلفاً تحت الواجهة البرمجيّة نفسها».

flowchart TB
    accTitle: عزل العمليّة مقابل عزل Hyper-V
    accDescr: تحت عزل العمليّة، تشارك الحاويات النواة مع المضيف وتعزل عبر مساحات الأسماء؛ تحت عزل Hyper-V، لكلّ حاوية نواة مخصَّصة داخل آلة افتراضيّة محسَّنة
    subgraph pi ["عزل العمليّة"]
        c1["الحاوية أ"] --> sk1["نواة مشتركة مع المضيف"]
        c2["الحاوية ب"] --> sk1
    end
    subgraph hi ["عزل Hyper-V"]
        c3["الحاوية ج"] --> k3["نواة مخصَّصة（داخل آلة افتراضيّة محسَّنة）"]
        c4["الحاوية د"] --> k4["نواة مخصَّصة（داخل آلة افتراضيّة محسَّنة）"]
    end
    sk1 ~~~ c3

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

5.2. أيّهما يمكنك تسميته «حدّ أمان»

الفرق بين هذين الوضعين ليس قصّة أداء فقط. لا تعتبر Microsoft حاوية معزولة بالعمليّة حدّ أمان متيناً. الحاويات التي تُصان (مع استجابة للثغرات) بوصفها حدّ أمان هي الحاويات المعزولة بالـ hypervisor، وعزل Hyper-V هو ما ينبغي اختياره في سيناريو متعدّد المستأجرين معادٍ.⁸

كان VBS الذي رأيناه في الجزء 2 أيضاً تصميماً يفترض «يمكن اختراق النواة» ويتراجع إلى حدّ hypervisor. المعيار نفسه ينطبق في عالم الحاويات. الخطّ الذي يحصر شيفرة غير موثوقة يُرسَم عند حدّ الـ hypervisor، لا داخل نواة مشتركة.

flowchart TB
    accTitle: كيفيّة اختيار العزل من مقدار ثقتك بالشيفرة
    accDescr: إن كان حمل العمل موثوقاً، خذ الكثافة والأداء بعزل العمليّة؛ إن كانت الشيفرة غير موثوقة أو لشخص آخر، اختر حدّ hypervisor مثل حاوية معزولة بـ Hyper-V، أو Windows Sandbox محصَّن بتعطيل الشبكة، أو آلة افتراضيّة معزولة
    trust{"هل تستطيع الوثوق بتلك الشيفرة؟"} -->|نعم| dens["عزل العمليّة（أعطِ الأولويّة للكثافة والسرعة）"]
    trust -->|لا / شيفرة شخص آخر| bound["اختر حدّ hypervisor"]
    bound --> opt1["حاويات معزولة بـ Hyper-V"]
    bound --> opt2["Sandbox محصَّن أو آلة افتراضيّة معزولة"]

الشكل 12: وضع العزل قصّة أمان قبل أن يكون قصّة أداء، والثقة تقرِّر أين ترسم الخطّ.

بالمناسبة، تشغيل حاوية معزولة بـ Hyper-V داخل آلة افتراضيّة Hyper-V يجعل الـ hypervisor طبقتين عمقاً ── افتراضيّة متداخلة. مستوى واحد من التداخل مدعوم في الإنتاج على بيئات تستوفي الشروط (معالج Intel مع مضيف Windows 10 / Windows Server 2016 أو أحدث، أو معالج AMD مع مضيف Windows 11 / Windows Server 2022 أو أحدث، وإصدار تكوين الآلة الافتراضيّة المقابل في كلّ حالة)، ومتطلَّب إضافيّ هو إعداد يعرِّض امتدادات الافتراضيّة للآلة الافتراضيّة الخارجيّة (ExposeVirtualizationExtensions على Set-VMProcessor في Hyper-V). تشغيل WSL2 داخل آلة افتراضيّة مدعوم بالطريقة نفسها.⁹ ما إذا كان يمكنك استخدام WSL2 أو Docker في آلة افتراضيّة تطوير في السحابة يقرِّره أيضاً ما إذا كان حجم تلك الآلة الافتراضيّة وتكوينها يعرِّضان الافتراضيّة المتداخلة.

flowchart TB
    accTitle: بنية الافتراضيّة المتداخلة
    accDescr: تجلس آلة افتراضيّة سحابيّة على hypervisor المضيف الفيزيائيّ، وداخلها يعمل hypervisor آخر（التداخل المدعوم مستوى واحد）لدعم WSL2 والحاويات المعزولة بـ Hyper-V
    phys3["hypervisor المضيف الفيزيائيّ"] --> cvm["آلة افتراضيّة سحابيّة（جهاز تطوير）"]
    cvm --> nhv["hypervisor داخل الآلة الافتراضيّة（مستوى التداخل 1）"]
    nhv --> w2["WSL2"]
    nhv --> hvc["حاوية معزولة بـ Hyper-V"]
    nhv -.-> limit["التداخل المدعوم مستوى واحد"]

الشكل 13: سبب عمل wsl داخل آلة افتراضيّة سحابيّة هو أنّ الافتراضيّة المتداخلة مدعومة رسميّاً لمستوى واحد فقط.

5.3. طيف العزل والخفّة

اصطفاف الطاقم حتّى الآن على محور واحد يبدو هكذا.

flowchart TB
    accTitle: طيف قوّة العزل والخفّة
    accDescr: الحاويات المعزولة بالعمليّة الأخفّ لكنّها تشارك النواة؛ WSL2 وSandbox والحاويات المعزولة بـ Hyper-V آلات افتراضيّة خفيفة بنواة مخصَّصة（يخفِّف Sandbox بالمشاركة، وWSL2 بنواة مبنيّة لغرضها）；آلة افتراضيّة كاملة الأثقل لكنّها عامّة الغرض
    ax["خفيف ← → ثقيل"] ~~~ p1
    p1["حاويات معزولة بالعمليّة（نواة مشتركة）"] --> p2["WSL2 وSandbox وعزل Hyper-V（آلات افتراضيّة خفيفة بنواة مخصَّصة）"]
    p2 --> p3["آلة افتراضيّة كاملة（تشغِّل أيّ شيء؛ تحتفظ بنسخة كاملة）"]
    p1 -.-> n1["الحدّ: مساحات الأسماء"]
    p2 -.-> n2["الحدّ: hypervisor"]
    p3 -.-> n3["الحدّ: hypervisor + استقلال كامل"]

الشكل 14: مجموعة الآلات الافتراضيّة الخفيفة هي الحلّ الوسط الذي أبقى حدّ الـ hypervisor وقطع التكرار؛ طريقة قطعه تنقسم إلى مشاركة لـ Sandbox ونواة مبنيّة لغرضها لـ WSL2.

6. انظر بنفسك

الخفّة والمشاركة أمور يمكنك ملاحظتها على جهاز أمامك.

زمن البدء وصعود الذاكرة وهبوطها (WSL2). مع فتح مدير المهام، جرِّب التالي.

# Felt startup time (the first run starts the VM; the second and later are faster still)
Measure-Command { wsl -e true }

# Memory usage of the WSL2 VM (vmmem / Virtual Machine Memory)
Get-Process -Name vmmem* | Select-Object Name, WorkingSet64

# End the whole VM and watch the memory come back
wsl --shutdown

إذا فعلت بناء كبيراً أو عمليّة ملفّات داخل WSL2، ينمو vmmem، ويمكنك ملاحظة إعادته دفعة واحدة بـwsl --shutdown.

فرق السرعة من أين تضع الملفّات (WSL2). ضع المستودع نفسه في جانب Linux (~/repo) وفي جانب Windows (/mnt/c/repo) وقارن زمن git status أو استخراج، فيظهر فرق القسم 3.2 بالأرقام.

خلفيّة لـ direct map (Sandbox). ابدأ Sandbox وانظر إلى الزيادة في الذاكرة في مدير المهام على المضيف. أنّ الزيادة تبقى أصغر بكثير ممّا يوحي به «Windows آخر» هو أثر المشاركة يروي قصّته. للحفر أبعد في تفصيل ذاكرة جانب المضيف، مقال أدوات Sysinternals الذي يغطّي كيفيّة استخدام RAMMap وVMMap («Process Explorer / Handle / VMMap عمليّاً») مفيد. هذه مع ذلك أدوات للنظر في تصنيف عمليّات جانب المضيف والذاكرة الفيزيائيّة؛ ولا تلاحظ المشاركة مع الضيف نفسه مباشرةً.

أوضاع عزل الحاويات (Docker / حاويات Windows). إن كان لديك بيئة حاويات Windows، ابدأ الصورة نفسها بـdocker run --isolation=process و--isolation=hyperv وقارن زمن البدء وكيف تبدو في مدير المهام (تحت عزل العمليّة، تظهر العمليّات داخل الحاوية في قائمة عمليّات المضيف)، ويمكنك الشعور أين يجلس خطّ العزل.⁷ عزل العمليّة مع ذلك يفترض تطابق إصدارات المضيف والصورة، وعلى نظام تشغيل عميل يقتصر على استخدام التطوير والاختبار. يتيح عزل Hyper-V مجموعة أوسع من التركيبات، لذا افعل المقارنة على زوج متوافق.¹⁰

7. ثلاثة قراءات خاطئة تجنَّبها في العمل

7.1. «WSL2 بطيء»

ما هو بطيء ليس WSL2 بل مسار إدخال/إخراج الملفّات الذي يعبر حدّ نظام تشغيل. ثمّة حالات كثيرة حيث مجرّد نقل المشروع إلى جانب Linux يجعل الإحساس شيئاً مختلفاً.⁴ بالمقابل، وضع ملفّات ستلمسها أدوات Windows في جانب Linux غير مواتٍ بالقدر نفسه وللسبب نفسه. احكم بـ«ضعه على نظام التشغيل نفسه كالجانب الذي يستخدمه».

7.2. «نموّ vmmem كبيراً تسرّب ذاكرة»

تنمو ذاكرة WSL2 وتنكمش مع الطلب، وتُعاد الأجزاء المطلَقة. على WSL الحاليّ، يستعيد autoMemoryReclaim أيضاً التخزين المؤقّت للملفّات تلقائيّاً (الافتراضيّ هو dropCache)، لذا «بقي كبيراً» غالباً يُحَلّ مع الوقت.⁵ إن بقي مع ذلك، أكِّد أنّ autoMemoryReclaim لم يُضبَط على disabled وأنّ pageReporting، المسؤول عن إعادة الأجزاء المطلَقة، لم يُعطَّل (أو أنّك لست على WSL أقدم)، ثمّ إمّا اجعل الحدّ الأعلى صريحاً بـmemory في .wslconfig أو أعد كلّ شيء بـwsl --shutdown عند حدّ جلسة. طريقة التفكير في التمييز بين تسرّب ولا-تسرّب هي نفسها كما في الحلقة التمهيديّة لسلسلة الذاكرة، «ماذا يعني «استخدام الذاكرة» في Windows فعليّاً؟».

7.3. «إنّه في حاوية، إذن هو آمن»

حاوية معزولة بالعمليّة تشارك النواة، وبمعيار Microsoft ليست حدّ أمان.⁸ لتشغيل شيفرة غير موثوقة أو عيّنة، اختر عزلاً يملك حدّ hypervisor، مثل حاوية معزولة بـ Hyper-V، أو Windows Sandbox، أو آلة افتراضيّة مخصَّصة. حدّ hypervisor مع ذلك ليس إعفاءً شاملاً. إعدادات Windows Sandbox الافتراضيّة تملك اتّصال شبكة ممكَّناً، ويمكن أن تعرِّض تطبيقاً غير موثوق للشبكة الداخليّة.¹ إن استخدمته لتشغيل عيّنة، حصِّن العزل بتعطيل الشبكة وإعادة توجيه الحافظة في ملفّ إعداد .wsb، أو استخدم آلة افتراضيّة مخصَّصة على شبكة معزولة.

8. الخلاصة ── إغلاق السلسلة

نقاط الجزء 3.

• خفّة آلة افتراضيّة خفيفة نتيجة «إيقاف التكرار»، لا «إضعاف العزل».
• يشغِّل WSL2 نواة Linux أصيلة في آلة افتراضيّة خدميّة خفيفة مُدارة، والتوزيعات معزولة حاويات داخل تلك الآلة الافتراضيّة.³ قاعدة الأداء هي وضع الملفّات على نظام التشغيل الذي يستخدمها، وتنمو الذاكرة وتنكمش ديناميّاً، مع إمكان التحكّم بالحدّ الأعلى في .wslconfig.⁴⁵
• يشارك Windows Sandbox ملفّات نظام التشغيل غير القابلة للتغيير للمضيف عبر صورة أساسيّة ديناميّة ويشارك أيضاً الصفحات الفيزيائيّة لملفّات نظام التشغيل الثنائيّة المستهدَفة عبر direct map، لذا لا يحتفظ بنسخة Windows كاملة.² ما زلت تحتاج نحو 500 ميغابايت للملفّات القابلة للتغيير، زائد ذاكرة التطبيقات التي تشغِّلها داخله.
• يُختار وضع عزل الحاوية عند البدء، والجانب الذي يمكنك تسميته حدّ أمان هو عزل Hyper-V.⁷⁸

وإذا وضعنا السلسلة كلّها في صفحة واحدة، تبدو هكذا.

• الجزء 1: ثمّة طبقة hypervisor تحت Windows، ونظام التشغيل المضيف نفسه يعمل بوصفه القسم الجذر. تحكيم المعالج والذاكرة (SLAT) تفعله هذه الطبقة مباشرةً، ويتوسّط القسم الجذر (VSP) إدخال/إخراج الأجهزة الاصطناعيّة وراء VMBus.
• الجزء 2: تُستخدَم تلك الطبقة لا لعزل الآلات الافتراضيّة بعضها عن بعض فقط بل أيضاً لرسم حدّ أقوى من النواة (VTL) داخل نظام التشغيل نفسه. أمان Windows 11 الافتراضيّ مبنيّ فوق هذا.
• الجزء 3: على الطبقة نفسها، قطع التكرار هو ما يجعل «آلة افتراضيّة تبدأ في ثوانٍ» ممكناً. خطّ العزل مُبقًى، وأصبحت أداة يوميّة.

flowchart TB
    accTitle: صورة واحدة للسلسلة كلّها
    accDescr: الـ hypervisor مباشرةً على العتاد هو الجزء 1؛ انقسام VTL0 وVTL1 داخل Windows المضيف هو الجزء 2؛ خفّة WSL2 وSandbox وعزل Hyper-V على الطبقة نفسها هي الجزء 3؛ الحاويات المعزولة بالعمليّة تشارك نواة المضيف؛ يخفِّف Sandbox بالمشاركة، وWSL2 بنواة مبنيّة لغرضها
    hw3["العتاد"] --> hv3["الـ hypervisor（الجزء 1）"]
    hv3 --> rp3["Windows المضيف（عزل VTL هو الجزء 2）"]
    hv3 --> lw3["WSL2 وSandbox وعزل Hyper-V（الجزء 3）"]
    rp3 --> pc3["حاويات معزولة بالعمليّة（نواة مشتركة）"]
    lw3 -.-> mech3["يشارك Sandbox؛ يخفِّف WSL2 بنواة مبنيّة لغرضها"]

الشكل 15: كدِّس الحلقات الثلاث فتحصل على الصورة الكلّيّة للأرض تحت Windows الحاليّ.

الافتراضيّة لم تعد تقنيّة غرفة خوادم، ولا تقنيّة لمن يُقيم آلات افتراضيّة فقط. عند الأرض تحت Windows لديك، تدعم بهدوء كلاً من الأمان وتجربة التطوير ── هناك نحن الآن.

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

• أعماق الافتراضيّة في Windows（الجزء 1）── أين يعمل Windows فعليّاً؟ الـ hypervisor والأقسام
• أعماق الافتراضيّة في Windows（الجزء 2）── ذاكرة لا تراها النواة: كيف يعمل VBS وHVCI وCredential Guard
• أعماق ذاكرة Windows（الجزء 3）── كائنات القسم والنسخ عند الكتابة: ما هي DLL وتعيينات الملفّات حقّاً
• كيف نستعمل Windows Sandbox لتسريع التحقّق من تطبيقات Windows - صلاحيّات المسؤول والبيئات النظيفة وإعادة إنتاج حالات نقص الصلاحيّات أو الموارد
• مطبّات إعادة توجيه السجلّ 32-بت/64-بت والافتراضيّة ── Wow6432Node ومشكلة «القيمة التي كتبتها ليست هناك»

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

تتعامل شركة كومورا سوفت ذ.م.م. مع إعداد بيئات تطوير تستخدم WSL2 والحاويات، وتصميم بيئات التحقّق لتطبيقات Windows، والتحقيق في الأداء والتوافق في البيئات الافتراضيّة.

• تطوير تطبيقات Windows
• التحقيق في الأخطاء وتحليل الأسباب الجذريّة
• ترحيل الأصول القائمة والاستفادة منها
• التواصل معنا

روابط مرجعيّة

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

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

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

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

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

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

هل WSL2 آلة افتراضيّة؟

نعم. يشغِّل WSL2 نواة Linux أصيلة تبنيها Microsoft داخل آلة افتراضيّة خدميّة خفيفة. تدير WSL الآلة الافتراضيّة خلف الكواليس، لذا لا يجعل التصميم المستخدم يفكِّر في إعدادات آلة افتراضيّة أو انتظار إقلاع. يعمل كلّ توزيعة Linux حاويةً معزولة داخل هذه الآلة الافتراضيّة المُدارة.

لماذا عمليّات الملفّات تحت /mnt/c بطيئة في WSL2؟

لأنّ الوصول من نواة Linux في WSL2 إلى نظام ملفّات جانب Windows يمرّ بمشاركة ملفّات تعبر حدّ نظام تشغيل. عمليّات نظام ملفّات Linux（قرص افتراضيّ ext4）سريعة، لذا القاعدة هي إبقاء ملفّات المشروع في جانب نظام التشغيل نفسه الذي تستخدمه الأدوات التي تعمل عليها.

هل استخدام ذاكرة كبير لعمليّة vmmem تسرّب؟

في معظم الحالات ليس تسرّباً. تنمو ذاكرة WSL2 وتنكمش مع الاستخدام، والذاكرة التي أطلقتها العمليّات تُعاد إلى Windows تحت إعداد pageReporting، المفعَّل افتراضيّاً. صفحات ذاكرة التخزين المؤقّت للملفّات أيضاً تُستعاد تلقائيّاً في WSL الحاليّ عبر autoMemoryReclaim في .wslconfig（الافتراضيّ هو dropCache）. في بيئات عُطِّلت فيها هذه الإعدادات، أو على WSL أقدم، يمكن أن تبقى الذاكرة حتّى تخرج الآلة الافتراضيّة؛ في تلك الحالة اضبط حدّاً أعلى بإعداد memory، أو أعدها بـ wsl --shutdown.

كيف يستطيع Windows Sandbox إقلاع Windows كامل من بضع مئات ميغابايت من القرص؟

عبر آليّة تُسمَّى صورة أساسيّة ديناميّة. تشارك ملفّات نظام التشغيل غير القابلة للتغيير من Windows المثبَّت أصلاً على المضيف، وتحتفظ بنسخة نظيفة من العدد الصغير فقط من الملفّات القابلة للتغيير. ذلك يتيح تجميع صورة كاملة قابلة للإقلاع دون تخزين نسخة كاملة من Windows.

هل الحاويات أكثر أماناً من الآلات الافتراضيّة؟

يعتمد على وضع العزل. الحاويات المعزولة بالعمليّة تشارك النواة مع المضيف، ولا تعتبر Microsoft هذا حدّ أمان متيناً. عندما تتعامل مع شيفرة معادية، تحتاج عزل Hyper-V، الذي يعطي كلّ حاوية نواتها المخصَّصة.

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

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

غو كومورا

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

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