أعماق الافتراضيّة في Windows (الجزء 1) ── أين يعمل Windows فعليّاً؟ الـ hypervisor والأقسام

لم تُنشئ آلة افتراضيّة واحدة قطّ، ومع ذلك تُظهر معلومات النظام (msinfo32) على Windows 11 «Virtualization-based security: Running». ماذا يعني ذلك العرض؟

على ذلك الحاسوب، يعمل Windows المضيف نفسه فوق hypervisor أصلاً. على Windows 11، يُفعَّل VBS افتراضيّاً على التكوينات التي تستوفي الشروط، كتثبيت نظيف على عتاد متوافق، وذلك الأساس مستخدَم حتّى إن لم تُنشئ آلة افتراضيّة قطّ.¹ يستخدم WSL2 وWindows Sandbox hypervisor Windows نفسه أيضاً.

يشرح الجزء 1 أين ينتهي Windows المضيف إلى العمل عندما تفعِّل Hyper-V، عبر تقسيم الأدوار عبر المعالج والذاكرة وإدخال/إخراج الأجهزة. إنّه الجزء الذي يستقيم فيه أوّلاً منظور «برمجيّة آلات افتراضيّة تجلس فوق Windows».

«أعماق الافتراضيّة في Windows» ── الأجزاء الثلاثة كلّها

ننظر إلى hypervisor Windows نفسه بترتيب الأساس → عزل الأمان → التطبيق على آلات افتراضيّة خفيفة.

مقدّمات هذا المقال

كيف تقرأ هذا المقال

خريطة المعرفة أدناه قائمة علاقات. إن كانت هذه قراءتك الأولى، اتّبع النصّ من القسم 1، الصورة الكبيرة.

في المخطّط، يشير الخطّ المتّصل إلى علاقة قائمة دائماً، ويشير الخطّ المتقطّع إلى علاقة مشروطة (شروط قيامها مذكورة في شرح كلّ علاقة في الصفحة التفصيليّة). القائمة الكاملة للعلاقات (المجموع 22، مع الأدلّة ودرجة اليقين) وتعريفات المفاهيم الرئيسة مجمّعة في صفحة تفاصيل خريطة المعرفة (باليابانية). البيانات: JSON-LD / Turtle

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

عندما يسمع الناس Hyper-V، قد يتصوّرون «برمجيّة تشغيل آلات افتراضيّة تجلس فوق Windows». البنية الفعليّة معكوسة.

من لحظة تفعيل Hyper-V وإعادة التشغيل، يكون الـ hypervisor هو من يتحكّم بالمعالجات الفيزيائيّة والذاكرة، ويعمل Windows المضيف فوقه بوصفه القسم الأوّل المميَّز، «القسم الجذر».

الـ hypervisor طبقة برمجيّة رقيقة تجلس بين العتاد ونظام التشغيل، وتنشئ بيئات تنفيذ معزولة تُسمَّى «أقساماً»، وتتوسّط الوصول إلى العتاد.² يدخل Windows المضيف القسم الجذر؛ وتدخل الآلات الافتراضيّة الأقسام الأبناء.

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

flowchart TB
    accTitle: البنية الكلّيّة بعد تفعيل Hyper-V
    accDescr: يجلس الـ hypervisor مباشرة على العتاد الفيزيائيّ، وفوقه يجلس القسم الجذر الذي يمسك Windows المضيف والأقسام الأبناء التي تمسك الآلات الافتراضيّة
    hw["العتاد الفيزيائيّ"] --> hv["الـ hypervisor"]
    hv --> root["القسم الجذر (Windows المضيف)"]
    hv --> child1["الأقسام الأبناء (الآلات الافتراضيّة)"]
    root -.-> stack["يمسك مكدّس إدارة الافتراضيّة وبرامج تشغيل الأجهزة"]

الشكل 1: Hyper-V ليس «برمجيّة آلات افتراضيّة فوق Windows» بل طبقة تذهب تحت Windows، ونظام التشغيل المضيف نفسه يعمل داخل القسم الجذر.

قد تفكّر: «لا شيء يبدو مختلفاً قبل التفعيل وبعده، فهل حدث حقّاً انقلاب بهذا الحجم؟» لقد حدث. ولهذا بالضبط تمرّ هذه البنية عادة دون أن تُلاحَظ. في هذا المقال نفكّك هذا المخطّط الواحد من ثلاثة اتّجاهات: المعالج، والذاكرة، وإدخال/إخراج الأجهزة.

2. من المعالج ── امتياز إضافي تحت الحلقات

في نقاش المعالج، نميِّز الحلقات التي تفصل النواة عن التطبيقات عن أوضاع التنفيذ التي تفصل الـ hypervisor عن الضيوف. سؤال هذا القسم: نواة الضيف تعمل أيضاً عند الحلقة 0، فلماذا لا يحدث تصادم؟

2.1. مراجعة حماية الحلقات

لمعالجات x64 مستويات امتياز (حلقات)، ويعمل Windows وضع النواة عند الحلقة 0 ووضع المستخدم عند الحلقة 3. لا تستطيع التطبيقات لمس العتاد مباشرة لأنّ التعليمات المميَّزة لا يمكن تنفيذها من الحلقة 3.

فكيف تؤوي بأمان عدّة نوى أنظمة تشغيل، كلّ منها تعمل عند الحلقة 0، على المعالج الفيزيائيّ نفسه؟ كلّ نواة مكتوبة على افتراض أنّ «أنا أتحكّم بالمعالج». أعطِ الحلقة 0 لكلّها فتتصادم؛ احجبها فلا تعمل.

flowchart TB
    accTitle: مشكلة نوى أنظمة تشغيل متعدّدة تطالب بالحلقة 0
    accDescr: نواتا المضيف والضيف مكتوبتان بافتراض سلطة كاملة عند الحلقة 0، لذا سلّم الحلقات التقليديّ وحده لا يستطيع إيواءهما بأمان على المعالج الفيزيائيّ نفسه
    k1["نواة المضيف (تفترض الحلقة 0)"] --> want["تطالب بالتحكّم بالمعالج الفيزيائيّ"]
    k2["نواة الضيف (تفترض الحلقة 0)"] --> want
    want --> conflict["الحلقات التقليديّة وحدها لا تستطيع التوفيق"]
    conflict --> need["يلزم وسيط فوق الحلقة 0"]

الشكل 2: بُني سلّم الحلقات بافتراض نظام تشغيل واحد، لذا إيواء نوى متعدّدة يحتاج امتيازاً إضافيّاً فوقه.

2.2. امتدادات الافتراضيّة ── وضع محجوز للـ hypervisor

ما يحلّ هذه المشكلة امتدادات الافتراضيّة في المعالج (Intel VT-x/AMD-V). يشترط Hyper-V معالجاً يملك هذه الميزة.² تضيف امتدادات الافتراضيّة، على محور منفصل عن الحلقات التقليديّة، «وضع تنفيذ للـ hypervisor» و«وضع تنفيذ للضيوف». إنّه امتياز أقوى حتّى من الحلقة 0، يُلقَّب أحياناً «الحلقة -1».

• تواصل نواة الضيف العمل عند الحلقة 0، كما كان. لا يلزم إعادة كتابة.
• غير أنّ تلك الحلقة 0 هي «الحلقة 0 داخل وضع الضيف»، وهي لا تتحكّم بالمعالج الفيزيائيّ ككلّ.
• عندما يصطدم الضيف بعمليّة معيّنة تحتاج تدخّل الـ hypervisor (تعليمة مضبوطة اعتراضاً، أو استثناء أو انتهاك)، ينقل المعالج التحكّم تلقائيّاً إلى الـ hypervisor (VM Exit). عندما يُنهي الـ hypervisor معالجتها، يعود إلى الضيف (VM Entry). تمرّ وصولات الذاكرة العاديّة مباشرة بلا VM Exit، ما دام ترجمة SLAT تنجح.

تعمل المقاطعات بالطريقة نفسها. لا تلمس الأقسام المعالجات الفيزيائيّة مباشرة؛ يتلقّى الـ hypervisor المقاطعات ويوجّهها إلى كلّ قسم.²

flowchart TB
    accTitle: تدفّق تنفيذ الضيف وVM Exit
    accDescr: تعمل نواة الضيف والتطبيقات عند الحلقة 0 والحلقة 3 في وضع الضيف؛ وتمرّ وصولات الذاكرة العاديّة عبر ترجمة SLAT، بينما تسبّب العمليّات المضبوطة اعتراضاً والاستثناءات VM Exit ينقل التحكّم إلى الـ hypervisor، الذي يعود إلى الضيف عبر VM Entry بعد معالجتها
    guest["يعمل في وضع الضيف (بما فيها نواة الحلقة 0)"] --> op{"عمليّة تحتاج تدخّلاً؟ (اعتراضات/استثناءات مضبوطة)"}
    op -->|لا| cont["واصل التنفيذ كما هو"]
    op -->|نعم| exitEv["VM Exit (المعالج ينقل التحكّم)"]
    exitEv --> hvp["الـ hypervisor يعالجها"]
    hvp --> entry["العودة إلى الضيف عبر VM Entry"]
    entry --> guest

الشكل 3: يظلّ نظام تشغيل الضيف يعمل عند الحلقة 0 بلا إعادة كتابة، ويستدعي المعالج الـ hypervisor فقط عند الحاجة.

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

2.3. النوع 1 والنوع 2 ── الفرق أين يجلس

تُقسَم الـ hypervisors إجمالاً إلى النوع 1 (على العتاد مباشرة)، الذي يعمل مباشرة على العتاد، والنوع 2 (مستضاف)، الذي يعمل فوق نظام تشغيل مضيف. Hyper-V من النوع 1.³ يُصنَّف VirtualBox وVMware Workstation (عند التشغيل مستقلَّين) نوعاً 2.

بسماع النوع 1، يميل الناس إلى تخيّل «تكوين خادم فقط بلا نظام تشغيل مضيف»، لكن Hyper-V مختلف. لا يختفي Windows المضيف؛ إنّه «ينتقل» إلى القسم الجذر. عندما تفعِّل Hyper-V وتعيد التشغيل، يبدأ الـ hypervisor أوّلاً أثناء الإقلاع، ثمّ يصعد Windows المضيف بوصفه القسم الجذر فوقه.

flowchart TB
    accTitle: الفرق بين hypervisor من النوع 1 والنوع 2
    accDescr: في النوع 2 يجلس نظام التشغيل المضيف على العتاد ويجلس الـ hypervisor والآلات الافتراضيّة على نظام التشغيل المضيف، بينما في Hyper-V من النوع 1 يجلس الـ hypervisor مباشرة على العتاد ويدخل نظام التشغيل المضيف نفسه القسم الجذر فوقه
    subgraph t2 ["النوع 2 (مستضاف)"]
        hw2["العتاد"] --> hostos["نظام التشغيل المضيف"]
        hostos --> hv2["الـ hypervisor"]
        hv2 --> vm2["آلة افتراضيّة"]
    end
    subgraph t1 ["النوع 1 (Hyper-V)"]
        hw1["العتاد"] --> hv1["الـ hypervisor"]
        hv1 --> root1["القسم الجذر (نظام التشغيل المضيف)"]
        hv1 --> vm1["آلة افتراضيّة"]
    end
    vm2 ~~~ hw1

الشكل 4: في النوع 2 يجلس الـ hypervisor على نظام التشغيل المضيف، بينما في Hyper-V من النوع 1 ينعكس الترتيب ويجلس نظام التشغيل المضيف نفسه على الطبقة درجة أسفل.

منظوراً على خطّ زمني للإقلاع، يبدو التغيير الذي يحدث عندما تفعِّله هكذا.

flowchart TB
    accTitle: ترتيب الإقلاع بعد تفعيل Hyper-V
    accDescr: بعد التشغيل، يبدأ الـ hypervisor أوّلاً أثناء الإقلاع، ثمّ يصعد Windows المضيف بوصفه القسم الجذر فوقه، وتبدأ الآلات الافتراضيّة وVBS وما شابه بعد ذلك
    poweron["التشغيل وبدء الإقلاع"] --> bhv["يبدأ الـ hypervisor أوّلاً"]
    bhv --> broot["يبدأ Windows المضيف بوصفه القسم الجذر"]
    broot --> blater["تبدأ الآلات الافتراضيّة وVBS وWSL2 وما شابه فوق ذلك"]
    broot -.-> feel["تجربة المستخدم بلا تغيير"]

الشكل 5: انقلاب الترتيب يكون قد انتهى قبل ظهور شاشة تسجيل الدخول، ويصعد نظام التشغيل المضيف على الـ hypervisor من البداية.

3. الأقسام ── وحدة العزل

لننظر عن كثب إلى الأقسام، «الصناديق» في الصورة الكبيرة. ما نريد فصله هنا هو توسّط المعالج والذاكرة، الذي يتولّاه الـ hypervisor مباشرة، عن إدخال/إخراج الأجهزة، الذي يتوسّطه القسم الجذر عادة.

3.1. أدوار يملكها القسم الجذر وحده

القسم وحدة عزل منطقيّة يوفّرها الـ hypervisor.² غير أنّ الأقسام ليست متساوية كلّها. ثمّة أشياء يملكها القسم الجذر وحده.

الوصول المباشر إلى الأجهزة الفيزيائيّة

تعيش برامج تشغيل الأجهزة للأقراص ومحوِّلات الشبكة ووحدات GPU وما شابه في Windows داخل القسم الجذر، لا في الـ hypervisor. يملك Hyper-V على Windows Server تكويناً يخصِّص جهازاً PCIe معيّناً مباشرة لقسم ابن (Discrete Device Assignment)؛ في تلك الحالة يترك الجذر ذلك الجهاز (هذا غير متاح على Windows العميل).⁴

مكدّس إدارة الافتراضيّة

تعمل VMMS (خدمة إدارة الآلات الافتراضيّة)، التي تحكم إنشاء الآلات الافتراضيّة وبدءها وإيقافها، والعمليّة العاملة التي تبدأ لكلّ آلة افتراضيّة (vmwp.exe) في وضع المستخدم في القسم الجذر.⁵ هذه جزء من ميزات إدارة الآلات الافتراضيّة في Hyper-V، لذا قد تغيب على مضيف يعمل فيه الـ hypervisor فقط من أجل VBS أو WSL2.

حقّ إنشاء الأقسام الأبناء

ينشئ القسم الجذر أقساماً أبناء عبر واجهة hypercall (واجهة الاستدعاء إلى الـ hypervisor).²

لهذا التصميم سبب. إن وضعت كلّ برنامج تشغيل جهاز في الـ hypervisor نفسه، يصير الـ hypervisor ضخماً وينمو عدد الأخطاء ومداخل الهجوم. يحصر الـ hypervisor نفسه في العمل الأدنى لتوسّط المعالجات والذاكرة، ويترك رعاية الأجهزة لـ Windows في القسم الجذر. تقسيم الأدوار هذا هو ما يُبقي Hyper-V رقيقاً.

flowchart TB
    accTitle: تقسيم الأدوار بين القسم الجذر والأقسام الأبناء
    accDescr: يمسك القسم الجذر مكدّس إدارة الافتراضيّة وبرامج تشغيل الأجهزة الفيزيائيّة وينشئ أقساماً أبناء عبر hypercall؛ ويرى قسم ابن أجهزة افتراضيّة فقط في التكوين المعتاد، وتحت Discrete Device Assignment على Windows Server يصل إلى الجهاز المعيَّن مباشرة
    subgraph rootp ["القسم الجذر"]
        vmms["VMMS والعمليّات العاملة"]
        drv["برامج تشغيل الأجهزة الفيزيائيّة"]
    end
    subgraph childp ["القسم الابن"]
        gos["نظام تشغيل الضيف"]
        vdev["في التكوين المعتاد، لا تُرى إلّا أجهزة افتراضيّة"]
    end
    vmms -->|إنشاء وإدارة عبر hypercall| childp
    hv2["الـ hypervisor (يحصر نفسه في توسّط المعالج والذاكرة)"] --- rootp
    hv2 --- childp

الشكل 6: وضع برامج تشغيل الأجهزة ومكدّس الإدارة في جانب القسم الجذر هو ما يُبقي الـ hypervisor نفسه رقيقاً.

3.2. العالم كما يُرى من قسم ابن

لا يستطيع نظام تشغيل الضيف في قسم ابن رؤية العتاد الفيزيائيّ مباشرة في تكوين الجهاز الافتراضيّ المعتاد (الاستثناء الوحيد جهاز مُسنَد عبر Discrete Device Assignment على Windows Server، كما وُصف في القسم السابق). ما يستطيع رؤيته معالجات افتراضيّة، وفضاء ذاكرة يبدو خاصّاً به، وأجهزة افتراضيّة. تُحوَّل الطلبات إلى الأجهزة الافتراضيّة إلى القسم الجذر عبر VMBus أو الـ hypervisor.²

تخصيص زمن المعالج وترجمة الذاكرة عبر SLAT، بالمقابل، يتولّاهما الـ hypervisor مباشرة دون المرور بالجذر. ما يتوسّطه الجذر هو إدخال/إخراج الأجهزة، لا كلّ مورد فيزيائيّ.

flowchart TB
    accTitle: العالم كما يُرى من قسم ابن
    accDescr: ما يراه نظام تشغيل الضيف معالجات افتراضيّة وفضاء ذاكرة خاصّ بالقسم وأجهزة افتراضيّة؛ وتُحوَّل الطلبات إلى الأجهزة الافتراضيّة إلى القسم الجذر عبر VMBus وما شابه، ويتولّى الـ hypervisor زمن المعالج وترجمة الذاكرة مباشرة، وفي تكوين Discrete Device Assignment على Windows Server تُوصَل الأجهزة المعيَّنة فقط مباشرة
    gos2["نظام تشغيل الضيف في القسم الابن"] --> vcpu["معالجات افتراضيّة"]
    gos2 --> gpa2["فضاء ذاكرة خاصّ"]
    gos2 --> vdev2["أجهزة افتراضيّة"]
    vdev2 -->|"عبر VMBus وما شابه"| rootx["تُحوَّل إلى القسم الجذر"]
    gos2 -.->|غير مرئي مباشرة| phys2["معالجات فيزيائيّة وRAM وأجهزة حقيقيّة"]
    phys2 -.-> dda2["في تكوين DDA (Windows Server)، تُوصَل الأجهزة المعيَّنة فقط مباشرة"]
    vcpu ~~~ phys2

الشكل 7: في تكوين الجهاز الافتراضيّ المعتاد كلّ ما يراه الضيف نافذة افتراضيّة والمسار إلى الفيزيائيّ يمرّ بوسيط؛ والجهاز المُسنَد عبر DDA على Windows Server وحده الاستثناء.

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

4. من الذاكرة ── ترجمة العناوين تكسب مستوى إضافيّاً

مع الذاكرة، نفصل العنوان الذي يعتبره الضيف «فيزيائيّاً» عن الموقع الفعلي في RAM. أبقِ في الذهن الترتيب GVA ← GPA ← SPA ومن يدير كلّ ترجمة.

4.1. ثلاثة أنواع من العنوان

في الجزء 1 من سلسلة الذاكرة تبعنا التدفّق الذي يُترجَم به عنوان افتراضي عبر جدول الصفحات إلى عنوان فيزيائي («اللحظة التي يصبح فيها العنوان الافتراضي ذاكرة RAM مادّيّة»). في بيئة مُفتَرَضة يُضاف مستوى إضافي تحت تلك الترجمة، وثمّة ثلاثة أنواع من العنوان.

يترجم نظام تشغيل الضيف GVA إلى GPA بجدول صفحاته. غير أنّ GPA الذي يراه الضيف ليس عنواناً فيزيائيّاً حقيقيّاً؛ إنّه فضاء ذاكرة خاصّ مكرَّس لكلّ قسم.² إسقاط GPA على الموقع الفعلي في RAM (SPA) عمل الـ hypervisor.

4.2. SLAT ── ترجمة مستويين في العتاد

لو أُنجزت هذه الترجمة من المستوى الثاني برمجيّاً وحدها، لاضطرّ الـ hypervisor إلى تتبّع كلّ تحديث لجدول صفحات الضيف واحداً واحداً، وهو غير واقعي من منظور الأداء. لذا يوفّر المعالج آليّة تمشي جداول الترجمة من المستوى الثاني في العتاد. ذلك هو SLAT (Second Level Address Translation)؛ Intel EPT (Extended Page Tables) وAMD RVI هما التنفيذان.

يشترط Hyper-V الحالي معالجاً 64-بت يدعم SLAT.⁴

flowchart TB
    accTitle: ترجمة عناوين بمستويين عبر SLAT
    accDescr: يُترجَم عنوان افتراضي للضيف إلى عنوان فيزيائي للضيف بجدول صفحات نظام تشغيل الضيف، ثمّ يُترجَم أبعد إلى عنوان فيزيائي للنظام بـ SLAT الذي يديره الـ hypervisor، ويصل إلى RAM الفعلي
    gva["عنوان افتراضي للضيف (GVA)"] -->|جدول صفحات نظام تشغيل الضيف| gpa["عنوان فيزيائي للضيف (GPA)"]
    gpa -->|"SLAT (جداول ترجمة EPT/RVI)"| spa["عنوان فيزيائي للنظام (SPA)"]
    spa --> ram["RAM فيزيائيّة"]
    gpa -.-> note["طبقة يعتقد الضيف فحسب أنّها فيزيائيّة"]

الشكل 8: يجلس جدول ترجمة آخر، يديره الـ hypervisor، تحت جدول صفحات الضيف، ويمشي المعالج الاثنين في العتاد.

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

5. من إدخال/إخراج الأجهزة ── VMBus ونوعان من الجهاز

يسلك إدخال/إخراج الأجهزة مساراً يختلف عن زمن المعالج وترجمة الذاكرة. نقارن الطريقة التي تحاكي عتاداً حقيقيّاً بالطريقة التي تستخدم مساراً مخصَّصاً للافتراضيّة.

5.1. حدود الأجهزة المُحاكاة

الطريقة الكلاسيكيّة لإظهار جهاز لقسم ابن محاكاة عتاد حقيقي بالكامل (متحكّم IDE قديم مثلاً) برمجيّاً. التوافق عالٍ لأنّ برامج التشغيل المضمَّنة في نظام تشغيل الضيف تعمل كما هي، لكن يحدث VM Exit في كلّ مرّة يصطدم فيها الضيف بمنفذ إدخال/إخراج، ولا يتوسّع الأداء.

flowchart TB
    accTitle: لماذا إدخال/إخراج جهاز مُحاكى بطيء
    accDescr: في كلّ مرّة يشغِّل فيها الضيف منفذ إدخال/إخراج، ينتقل التحكّم إلى جانب الـ hypervisor عبر VM Exit، ويُحاكى الجهاز برمجيّاً، ويعود التحكّم إلى الضيف، لذا يتكرّر الذهاب والإياب ويبطئ
    gio["الضيف يشغِّل منفذ إدخال/إخراج"] --> vex["يحدث VM Exit"]
    vex --> emu2["يُحاكى الجهاز برمجيّاً"]
    emu2 --> back["العودة إلى الضيف عبر VM Entry"]
    back -->|يتكرّر عند تشغيل المنفذ التالي| gio

الشكل 9: يعمل هذا الذهاب والإياب مرّات كثيرة وراء وصول قرص واحد، وثمن التوافق يُدفَع بالأداء.

5.2. VMBus وVSP/VSC ── مسار سريع مصمَّم للافتراضيّة

لذا يملك Hyper-V آليّة «جهاز اصطناعيّ» مصمَّمة بافتراض الافتراضيّة. ثمّة ثلاثة لاعبين.²

• VMBus: قناة اتّصال منطقيّة بين الأقسام. توفِّر اتّصالاً عالي السرعة بين الأقسام يستخدم ذاكرة مشتركة.³
• VSP (موفّر خدمة الافتراضيّة): خدمة تقيم في جانب القسم الجذر، تتلقّى طلبات الأجهزة من الابن، وتجسرها إلى مكدّس الجهاز/الخلف في جانب الجذر. قد يصل طلب إلى جهاز فيزيائيّ، أو قد يعالجه خلف جانب المضيف كقرص افتراضي أو مبدِّل افتراضي.
• VSC (مستهلك خدمة الافتراضيّة): برنامج تشغيل جهاز اصطناعيّ يدخل نظام تشغيل الضيف في جانب القسم الابن. يرسل الطلبات إلى VSP عبر VMBus.

مثال: كيف يصل WriteFile للضيف إلى المضيف

يتدفّق طلب تخزين من نظام تشغيل الضيف بالترتيب التالي.

1. ينزل WriteFile لتطبيق الضيف مكدّس إدخال/إخراج نواة الضيف.
2. في القاع، يصل إلى VSC بدل العتاد الحقيقي.
3. يضع VSC الطلب على VMBus ويسلِّمه إلى VSP في القسم الجذر.
4. يُدخل VSP الطلب في مكدّس إدخال/إخراج جانب الجذر. في تكوين قرص افتراضي (VHDX)، يُعالَج كتابة إلى ملفّ VHDX على المضيف ويصل في النهاية إلى القرص الفيزيائيّ.

تُسمَّى هذه المقاربة Enlightened I/O (إدخال/إخراج واعٍ بالافتراضيّة)، وترفع الكفاءة بتجاوز طبقة محاكاة الجهاز.²

flowchart TB
    accTitle: مسار إدخال/إخراج لجهاز اصطناعيّ
    accDescr: يصل طلب إدخال/إخراج من تطبيق في القسم الابن إلى VSC عبر نواة الضيف، ويعبر VMBus إلى VSP في القسم الجذر، وعلى مكدّس إدخال/إخراج جانب الجذر الذي يجسره VSP قد يصل إلى جهاز حقيقي عبر برنامج تشغيل جهاز فيزيائيّ، أو قد يعالجه خلف جانب المضيف كقرص افتراضي أو مبدِّل افتراضي
    app["تطبيق في القسم الابن"] --> gk["مكدّس إدخال/إخراج نواة الضيف"]
    gk --> vsc["VSC (برنامج تشغيل جهاز اصطناعيّ)"]
    vsc -->|VMBus| vsp["VSP (جانب القسم الجذر)"]
    vsp --> rio["مكدّس إدخال/إخراج جانب الجذر"]
    rio --> pdrv["برنامج تشغيل جهاز فيزيائيّ"]
    rio --> hb["خلف جانب المضيف (قرص افتراضي، مبدِّل افتراضي، وما شابه)"]
    pdrv --> dev["جهاز فيزيائيّ"]

الشكل 10: مع جهاز اصطناعيّ، يعبر إدخال/إخراج الضيف إلى القسم الجذر عبر VMBus، وعبر مكدّس جانب الجذر، يصل إلى جهاز حقيقي أو خلف جانب المضيف.

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

flowchart TB
    accTitle: الأجهزة المُحاكاة مقابل الأجهزة الاصطناعيّة
    accDescr: يحاكي جهاز مُحاكى عتاداً حقيقيّاً فتعمل برامج التشغيل المضمَّنة في الضيف لكنّه بطيء؛ والجهاز الاصطناعيّ برنامج تشغيل مبنيّ للغرض يفترض VMBus وهو سريع
    dev2{"الجهاز المعروض للقسم الابن"} --> emu["جهاز مُحاكى"]
    dev2 --> syn["جهاز اصطناعيّ"]
    emu -.-> emuP["يحاكي عتاداً حقيقيّاً؛ التوافق أوّلاً"]
    emuP -.-> emuC["يحتاج تدخّلاً عند كلّ إدخال/إخراج؛ بطيء"]
    syn -.-> synP["مصمَّم حول VMBus؛ سريع"]
    synP -.-> synC["يتطلّب برنامج تشغيل مطابقاً في الضيف"]

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

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

6.1. VBS وWSL2 وSandbox تستخدم الأساس نفسه

قد تبدو البنية حتّى الآن «قصّة لمن يُقيم آلات افتراضيّة». كما قال الافتتاح، غير أنّه على Windows الحالي الـ hypervisor جزء من الحياة اليوميّة.

• الأمان المستند إلى الافتراضيّة (VBS). يستخدم hypervisor Windows لإنشاء بيئة معزولة ويؤوي فيها ميزات أمنيّة. على Windows 11 يُفعَّل افتراضيّاً عندما تُستوفى شروط كتثبيت نظيف على عتاد متوافق.¹ التفاصيل في الجزء 2.
• WSL2. يشغِّل نواة Linux حقيقيّة داخل آلة افتراضيّة خدميّة خفيفة.⁶
• Windows Sandbox. بيئة Windows قابلة للرمي معزولة بالـ hypervisor.⁷ الاثنان مشمولان في الجزء 3.

flowchart TB
    accTitle: ميزات يوميّة تجلس على الـ hypervisor نفسه
    accDescr: لا آلات Hyper-V الافتراضيّة فحسب، بل أيضاً VBS الذي يُفعَّل افتراضيّاً على أجهزة تستوفي شروطاً كتثبيت نظيف، زائد WSL2 وWindows Sandbox، مبنيّة كلّها على hypervisor Windows نفسه
    base["hypervisor Windows"] --> f1["آلات Hyper-V الافتراضيّة"]
    base --> f2["VBS (مفعَّل افتراضيّاً على تثبيتات نظيفة وما شابه)"]
    base --> f3["WSL2"]
    base --> f4["Windows Sandbox"]
    f2 -.-> daily["لماذا يعمل حتّى على حواسيب لا تستخدم آلة افتراضيّة قطّ"]

الشكل 12: الأساس واحد، وهذا الشكل هو حيث ينهار افتراض «الافتراضيّة قصّة لمن يستخدم آلات افتراضيّة».

6.2. التعايش مع برمجيّات افتراضيّة من أطراف ثالثة

أمر آخر يصطدم به الناس كثيراً في الممارسة هو التعايش مع برمجيّات افتراضيّة من أطراف ثالثة. لأنّ الـ hypervisor يستخدم امتدادات الافتراضيّة في المعالج حصريّاً، في بيئة يعمل فيها hypervisor Windows، لا يستطيع VirtualBox وما شابه العمل بالطريقة التقليديّة (الطريقة التي تستخدم امتدادات الافتراضيّة في المعالج نفسها).

لهذا تُوفَّر واجهة عامّة تُسمَّى Windows Hypervisor Platform، ويمكن لمكدّس افتراضيّة من طرف ثالث أن يعمل بالجلوس فوق hypervisor Windows.⁸ يستطيع VirtualBox/VMware الحاليّان التعايش مع WSL2 بفضل هذه الآليّة، لكن فروق الأداء والميزات التي تأتي مع تبديل الأوضاع تُلاحَظ أحياناً بوصفها «بعد أن فعَّلت Hyper-V (أو VBS)، بدأت برمجيّة الافتراضيّة تسلك سلوكاً مختلفاً».

flowchart TB
    accTitle: من يملك امتدادات افتراضيّة المعالج، ومسار برمجيّة افتراضيّة من طرف ثالث
    accDescr: بينما يعمل hypervisor Windows يملك حصريّاً امتدادات افتراضيّة المعالج؛ وبرمجيّة افتراضيّة من طرف ثالث تدعم WHP تعمل فوقه عبر Windows Hypervisor Platform، بينما تنفيذات لا تدعم WHP لا تستطيع العمل أو تكون محدودة الميزات
    vt["امتدادات افتراضيّة المعالج (VT-x/AMD-V)"] --> hvon{"هل يعمل hypervisor Windows؟"}
    hvon -->|لا| direct["تستطيع برمجيّة طرف ثالث استخدامها مباشرة"]
    hvon -->|نعم| own["الـ hypervisor يستخدمها حصريّاً"]
    own --> whp["Windows Hypervisor Platform"]
    whp --> third["برمجيّة طرف ثالث قادرة على WHP تعمل فوقه"]
    third -.-> nowhp["تنفيذات غير قادرة لا تعمل، أو تكون محدودة"]

الشكل 13: مالك امتدادات الافتراضيّة واحد، وبرمجيّة الطرف الثالث الوحيدة التي تستطيع التعايش بينما يعمل الـ hypervisor هي برمجيّة تدعم الواجهة العامّة (WHP).

7. انظر بعينك

يمكنك أن تفحص على حاسوبك هل يعمل hypervisor.

7.1. فحص الـ hypervisor وVBS بـ PowerShell

أوّلاً، فحص يمكنك تشغيله دون صلاحيّات مدير.

# هل نعمل فوق hypervisor
(Get-CimInstance Win32_ComputerSystem).HypervisorPresent

# حالة VBS (المصدر نفسه لـ «أمان يستند إلى الظاهرية» في msinfo32)
Get-CimInstance -Namespace root/Microsoft/Windows/DeviceGuard `
    -ClassName Win32_DeviceGuard |
    Select-Object VirtualizationBasedSecurityStatus

يعيد VirtualizationBasedSecurityStatus حالة تشغيل VBS رقماً (2 تعني «Running»).⁹

تنبيه واحد. كلّ ما يخبرك به HypervisorPresent هو «هل نعمل فوق hypervisor»؛ ولا يميِّز الجذر عن الابن. إن شغَّلته على Windows داخل آلة افتراضيّة، ما يزال يعيد True، بوصفه قسماً ابناً. إن كان True على Windows على حاسوب فيزيائيّ، فذلك Windows داخل القسم الجذر؛ تقرؤه مع بيئة التنفيذ.

7.2. تمييز «يعمل» عن «المتطلّبات المسبقة» في systeminfo

ثانياً، الكلاسيكي من موجه أوامر.

systeminfo

انظر إلى «Hyper-V Requirements» في نهاية المخرجات. على جهاز لم يعمل فيه الـ hypervisor بعد، تُدرَج المتطلّبات الفرديّة، كدعم SLAT وما إذا كانت امتدادات الافتراضيّة ممكَّنة، واحداً واحداً. على جهاز يعمل فيه الـ hypervisor أصلاً، بدل المتطلّبات تحصل على سطر واحد: «A hypervisor has been detected. Features required for Hyper-V will not be displayed.»⁴

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

حتّى إن كان كلّ متطلَّب systeminfo «Yes»، يعني ذلك فقط أنّ جانب العتاد جاهز. ميزة Hyper-V نفسها متاحة على إصدارات Pro وEnterprise وEducation، وليست على Home.¹⁰

7.3. عند الفحص على الشاشة، ميِّز أيّ بند تفحص

في الواجهة الرسوميّة، افحص صفّ «Virtualization-based security» تحت «System Summary» في msinfo32. لاحظ أنّ «Virtualization: Enabled» في لوحة المعالج في مدير المهام يعرض فقط ما إذا كانت امتدادات الافتراضيّة ممكَّنة في البرنامج الثابت، وهو معلومة منفصلة عن ما إذا كان hypervisor يعمل.

flowchart TB
    accTitle: كيف تفحص ما إذا كان الـ hypervisor يعمل
    accDescr: إن قال systeminfo إنّ hypervisor قد اكتُشف فأنت تعمل على hypervisor (داخل القسم الجذر على حاسوب فيزيائيّ)؛ وإن ظهرت قائمة Hyper-V Requirements فهو لا يعمل بعد فتفحص كلّ متطلَّب كـ SLAT وVM Monitor Mode Extensions وDEP، لكن كلّ Yes يعني فقط أنّ جانب العتاد جاهز ولميزة Hyper-V أيضاً متطلَّب إصدار
    start2["شغِّل systeminfo"] --> q1{"ماذا يعرض حقل Hyper-V Requirements؟"}
    q1 -->|A hypervisor has been detected| running["الـ hypervisor يعمل (داخل الجذر على حاسوب فيزيائيّ)"]
    q1 -->|المتطلّبات مدرجة| notyet["الـ hypervisor لا يعمل بعد"]
    notyet --> q2{"كلّ المتطلّبات Yes؟"}
    q2 -->|كلّها Yes| can["جانب العتاد جاهز"]
    can -.-> ed["يحتاج Hyper-V أيضاً Pro/Enterprise/Education"]
    q2 -->|بعضها No| uefi["افحص البنود ذات الصلة في UEFI/BIOS وما شابه"]

الشكل 14: حقل «Hyper-V Requirements» في systeminfo يعمل فحص حالة تشغيل وفحص متطلّبات مسبقة كليهما.

8. ثلاث قراءات خاطئة تُتجنَّب في الممارسة

8.1. «لم نُفعِّل Hyper-V، لذا الافتراضيّة لا علاقة لها بحواسيبنا»

حتّى إن لم تُفعِّل ميزة Hyper-V (أدوات الإدارة وبيئة تنفيذ الآلات الافتراضيّة)، يعمل hypervisor Windows إن كان VBS مفعَّلاً. عندما تحقِّق في مشكلة توافق برنامج تشغيل، أو اختبار أداء، أو مشكلة مع برمجيّة افتراضيّة من طرف ثالث، افحص HypervisorPresent وحالة تشغيل VBS، لا ما إذا كانت الميزة مفعَّلة.

8.2. «مدير المهام يقول ‹الافتراضيّة: ممكَّنة›، إذن Hyper-V يعمل»

ذلك العرض عن إعداد البرنامج الثابت (ما إذا كان VT-x/AMD-V متاحاً). احكم على حالة تشغيل الـ hypervisor من «A hypervisor has been detected» في systeminfo. بالمقابل، إن قال مدير المهام «Disabled»، لا تستطيع تفعيل Hyper-V أو WSL2 أيضاً، لذا افحص إعدادات UEFI/BIOS أوّلاً.

flowchart TB
    accTitle: ثلاثة فحوص يسهل خلطها
    accDescr: يعرض حقل الافتراضيّة في مدير المهام إعداد البرنامج الثابت، وتعرض قائمة ميزات Windows حالة التثبيت، ويعرض systeminfo أو HypervisorPresent حالة التشغيل؛ وكلّ منها يجيب عن سؤال مختلف
    q3{"ماذا تريد أن تعرف؟"} --> a3["هل امتدادات الافتراضيّة ممكَّنة في البرنامج الثابت؟"]
    q3 --> b3["هل ثُبِّتت ميزة Hyper-V؟"]
    q3 --> c3["هل الـ hypervisor يعمل الآن؟"]
    a3 -.-> a3t["لوحة المعالج في مدير المهام"]
    b3 -.-> b3t["مربّع حوار ميزات Windows"]
    c3 -.-> c3t["systeminfo وHypervisorPresent"]

الشكل 15: هذه ثلاثة أسئلة مستقلّة، واستنتاج الاثنين الآخرين من أيّ عرض واحد قراءة خاطئة.

8.3. «إن كانت الآلة الافتراضيّة بطيئة، فهي مشكلة نظام تشغيل الضيف»

يعبر إدخال/إخراج الجهاز الاصطناعيّ VMBus إلى VSP في القسم الجذر ويمرّ بمكدّس الجهاز/الخلف في جانب الجذر (برامج تشغيل فيزيائيّة، زائد معالجة مبدِّل افتراضي وقرص افتراضي). إن راقبت العدّادات داخل الضيف فقط، لن تجد عنق زجاجة يجلس في تخزين جانب المضيف أو محوِّل شبكة. مبدأ مشكلات أداء الآلات الافتراضيّة المراقبة من الجانبين: الضيف والمضيف (القسم الجذر).

9. الخلاصة

• عندما تفعِّل Hyper-V، يعمل الـ hypervisor مباشرة على العتاد ويعمل Windows المضيف بوصفه القسم الجذر.²
• تظلّ نواة نظام تشغيل الضيف تعمل عند الحلقة 0، والعمليّات المضبوطة اعتراضاً زائد الاستثناءات وحدها تُسلَّم إلى الـ hypervisor عبر VM Exit. تمرّ وصولات الذاكرة العاديّة عبر ترجمة SLAT.
• القسم الجذر وحده يمسك برامج تشغيل الأجهزة الفيزيائيّة ومكدّس إدارة الافتراضيّة، وينشئ أقساماً أبناء عبر hypercall.²
• تصير الذاكرة ترجمة بمستويين GVA←GPA←SPA، ويتولّى المستوى الثاني العتاد بـ SLAT (EPT/RVI). يشترط Hyper-V الحالي SLAT.⁴
• يهيمن على إدخال/إخراج الأجهزة مسار الجهاز الاصطناعيّ VSC←VMBus←VSP، ويعتمد الأداء أيضاً على مكدّس الإدخال/الإخراج في جانب المضيف.²
• على Windows 11، لأنّ VBS يُفعَّل افتراضيّاً على أجهزة تستوفي شروطاً كتثبيت نظيف، ليس غريباً أن يعمل الـ hypervisor حتّى على حاسوب لا يستخدم آلة افتراضيّة قطّ.¹ يمكنك فحص حالة التشغيل بـ HypervisorPresent وsysteminfo.

تتكثّف الصورة الكبيرة للجزء 1 في هذا المخطّط الواحد.

flowchart TB
    accTitle: الصورة الكبيرة للجزء 1
    accDescr: يجلس الـ hypervisor تحت القسم الجذر والأقسام الأبناء؛ وتُخصَّص المعالجات بجدولة معالجات افتراضيّة (VM Exit فقط عند اعتراضات واستثناءات مضبوطة)، وتتوسّط الذاكرة ترجمة SLAT بمستويين، ويُحوَّل إدخال/إخراج الجهاز الاصطناعيّ عبر VMBus ويعالجه VSP في القسم الجذر، وللأجهزة المُحاكاة وDiscrete Device Assignment مسارات أخرى
    up["القسم الجذر والأقسام الأبناء"] --> hvS["الـ hypervisor"]
    hvS --> cpuS["المعالج: يخصِّص معالجات افتراضيّة"]
    hvS --> memS["الذاكرة: ترجمة بمستويين عبر SLAT"]
    hvS --> devS["الأجهزة: إدخال/إخراج اصطناعيّ يُحوَّل عبر VMBus"]
    cpuS -.-> cpuN["VM Exit فقط عند التدخّل"]
    devS --> vspS["يعالجه VSP في جانب الجذر"]
    devS -.-> devN["الأجهزة المُحاكاة وDDA تسلك مسارات أخرى"]

الشكل 16: جدولة المعالج وترجمة الذاكرة يتولّاهما الـ hypervisor مباشرة (VM Exit فقط عند التدخّل)، وإدخال/إخراج الجهاز الاصطناعيّ يتوسّطه القسم الجذر (VSP) في الجانب البعيد من VMBus.

يتبع في الجزء 2، «ذاكرة لا تستطيع النواة حتّى رؤيتها ── VBS وHVCI وCredential Guard».

نلتقط خيط هذا المقال، أنّ الـ hypervisor يمسك جداول ترجمة SLAT، ونتبع كيف ينشئ Windows «ذاكرة لا يستطيع مدير ولا النواة قراءتها».

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

• أعماق ذاكرة Windows (الجزء 1) — اللحظة التي يصبح فيها العنوان الافتراضي ذاكرة RAM مادّيّة: خطأ الصفحة من البداية إلى النهاية
• ماذا تعني «استخدام الذاكرة» في Windows فعليّاً ── قراءة Working Set وPrivate Bytes وCommit وملفّ الصفحات قراءة صحيحة
• بناء بيئة تحقّق لتطبيقات الأعمال بـ Windows Sandbox
• نوى P/E في Windows وجدولة المعالج

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

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

• تطوير تطبيقات Windows
• تحقيق الأعطال وتحليل الأسباب
• إعادة استخدام الأصول القائمة ودعم الترحيل
• التواصل معنا

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

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

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

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

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

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

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

عندما تفعِّل Hyper-V، أين يعمل Windows المضيف فعليّاً؟

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

هل تعني «الافتراضيّة: ممكَّنة» في مدير المهام أنّ Hyper-V يعمل؟

لا. يعرض ذلك العرض ما إذا كانت امتدادات الافتراضيّة في المعالج (Intel VT-x/AMD-V) ممكَّنة في البرنامج الثابت. لمعرفة ما إذا كان hypervisor يعمل فعليّاً، ابحث عن «A hypervisor has been detected» في systeminfo، أو افحص HypervisorPresent على Win32_ComputerSystem.

لماذا يعمل الـ hypervisor رغم أنّني لم أُنشئ آلة افتراضيّة قطّ؟

على Windows 11، يُفعَّل الأمان المستند إلى الافتراضيّة (VBS) افتراضيّاً على الأجهزة التي تستوفي الشروط، كتثبيت نظيف على عتاد متوافق، وVBS مبنيّ على hypervisor Windows. الأمر نفسه إن استخدمت WSL2 أو Windows Sandbox. ليس غريباً أن يعمل الـ hypervisor بغضّ النظر عمّا إذا كان أحد يستخدم الآلات الافتراضيّة.

ما SLAT، ولماذا يُشترَط لـ Hyper-V؟

SLAT (Second Level Address Translation) الآليّة التي يترجم بها المعالج العناوين الفيزيائيّة للضيف إلى عناوين فيزيائيّة فعليّة؛ Intel EPT وAMD RVI هما التنفيذان. بدونها سيضطرّ الـ hypervisor إلى صيانة جداول الترجمة برمجيّاً، وهو أمر غير واقعيّ من منظور الأداء، لذا يعاملها Hyper-V الحاليّ متطلَّباً صارماً.

إذا فعَّلتُ Hyper-V، هل يتوقّف VirtualBox وVMware عن العمل؟

لأنّ الـ hypervisor يستخدم امتدادات الافتراضيّة في المعالج حصريّاً، لا يمكن لـ hypervisor طرف ثالث أن يعمل بالطريقة التقليديّة. غير أنّ VirtualBox وVMware الحاليَّين يملكان وضعاً يعمل فوق hypervisor Windows (عبر Windows Hypervisor Platform)، لذا يمكن للإصدارات الحديثة من كلّ منهما التعايش.

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

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

غو كومورا

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

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