كيف تعمل توافقية تطبيقات ويندوز ── إبقاء التطبيقات القديمة حيّة بوضع التوافق والـ shims وCompatibility Administrator

«تطبيق أعمال عمره عشر سنوات اختفت شيفرته المصدرية لا يبدأ على حاسوب ويندوز 11 جديد. أشّرتُ «ويندوز إكس بي» في علامة تبويب التوافق بحوار الخصائص فعمل فوراً. — ماذا يحدث فعلياً؟ هل يجوز الاستمرار بالاعتماد على هذا؟» هذا استشارة نسمعها كثيراً.

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

يُستخدم دون فهم الآلية فتصبح إطالة العمر «يجب ألا نلمسه لأننا لا نعرف لماذا يعمل» غير مستقرة. افهم الآلية وتستطيع أن تقرّر، بأسباب، إلى أيّ مدى تعتمد عليه بأمان، وما الذي سيكسره، ومتى ينبغي إعادة الكتابة.

flowchart TB
    accTitle: فهم الآلية يغيّر جودة إطالة العمر
    accDescr: استخدام وضع التوافق دون فهم الآلية يؤدّي إلى إطالة عمر غير مستقرة لا تجرؤ على لمسها؛ فهم الآلية يتيح قراراً مسبّباً إلى أي مدى تعتمد عليه وما الذي سيكسره ومتى تعيد الكتابة
    unknown["استخدام دون فهم الآلية"] --> fear["إطالة عمر غير مستقرة لا تجرؤ على لمسها"]
    known["استخدام بعد فهم الآلية"] --> judge["قرارات بأسباب"]
    judge -.-> j1["إلى أي مدى تعتمد عليه"]
    judge -.-> j2["ما الذي سيكسره"]
    judge -.-> j3["متى ينبغي إعادة الكتابة"]

الشكل 1: حتى لإطالة العمر نفسها تختلف الجودة بين قلق الجهل بالآلية وقرار مبني على فهمها.

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

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

• الهوية الحقيقية لوضع التوافق هي الـ shims (طبقة توافق). إعدادات علامة تبويب التوافق تُكتَب إلى HKCU\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers، وتُطبَّق حزمة shims على تلك العملية عند البدء.¹²
• الـ shim خطاف API في وضع المستخدم يعيد كتابة جدول عناوين الاستيراد (IAT). يعترض مسار استدعاء التطبيق لواجهات ويندوز ويعيد الإجابات نفسها التي كان ويندوز القديم يعيدها. لا يغيّر نظام التشغيل نفسه.³
• ما يستطيعه shim هو نفس نطاق ما يصلحه تعديل شيفرة في التطبيق. لا يتجاوز آليات الأمن، ولا يصلح مشكلات وضع النواة (برامج تشغيل الأجهزة).³
• مايكروسوفت تشحن عدداً كبيراً من الـ shims الجاهزة — كذب الإصدار، إعادة تعيين مسارات الملفات، تزييف السجلّ، تزييف فحوص المسؤول، وغير ذلك. تستطيع تطبيقها على ملفات EXE فردية من Compatibility Administrator.⁴
• ويندوز نفسه يستخدم الـ shims افتراضياً. تُطابَق قاعدة التوافق القياسية للنظام (.sdb) عند كلّ إطلاق، وPCA (Program Compatibility Assistant) يستطيع أيضاً كشف مشكلة وتطبيق إعداد توافق تلقائياً.¹⁵
• «الإجابة كأنّه ويندوز أقدم» صارت الافتراضي. من ويندوز 8.1 فصاعداً لا يعيد GetVersionEx إصدار نظام لم يعلنه التطبيق في بيانه. وضع التوافق امتداد لتلك الآلية.⁶⁷
• الـ shims لا تعمل على تطبيقات 16 بت ولا على اعتماد برامج تشغيل النواة ولا على الوصول المباشر للعتاد. خصوصاً تطبيقات 16 بت لا تعمل أصلاً على ويندوز 64 بت.⁸
• للتطبيقات التي «تتطلّب مسؤولاً لكنّها لا تحتاجه فعلاً» RunAsInvoker هي الخطوة القياسية. __COMPAT_LAYER=RunAsInvoker يكبت طلب الرفع ويترك التطبيق يعمل بامتيازات عادية.⁹
• العمل تحت shim يعني أنّك تستطيع إطالة العمر الآن، لكن المسار الحقيقي «تشغيله بلا shim». إن قرّرت إطالة العمر فسجّل أيّ shims تجعله يعمل وأدر ذلك كمادّة لقرار إعادة الكتابة.

2. الصورة الكبيرة لتوافق التطبيقات — طبقات التوافق الخلفي التي يملكها ويندوز أصلاً

قبل الحديث عن الـ shims، هذه قائمة بالآليات التي يملكها ويندوز أصلاً للتطبيقات القديمة. حتى عندما يقول الناس «بدأ يعمل في وضع التوافق»، ما ينقذ التطبيق فعلاً طبقة من هذه، أو مزيج من عدّة طبقات.

افتراضية UAC إجراء انتقالي يسري على عمليات تفاعلية 32 بت بلا بيان، ومايكروسوفت نفسها تقول إنّها «تقنية مؤقّتة ننوي إزالتها من إصدار مستقبلي لويندوز».¹⁰ الضرر الحقيقي لتحويل Wow6432Node وVirtualStore وكيفية التعامل معه مفصّل في «Registry 32-bit/64-bit Redirection and Virtualization Pitfalls»؛ هذا المقال يبقي الـ shims في المركز ويذكر الطبقات الأخرى بالقدر اللازم فقط.

flowchart TB
    accTitle: أين تجلس افتراضية UAC
    accDescr: افتراضية UAC إجراء انتقالي للعمليات التفاعلية 32 بت بلا بيان؛ تحوّل الكتابات إلى VirtualStore لكل مستخدم، لكن مايكروسوفت نفسها تقول إنها تقنية مؤقتة يُقصد إزالتها من ويندوز مستقبلي
    proc["عملية تفاعلية 32 بت بلا بيان"] --> uacv["تُطبَّق افتراضية UAC"]
    uacv --> vs["تُحوَّل إلى VirtualStore لكل مستخدم"]
    uacv -.-> tmp["تقنية مؤقتة يُقصد إزالتها لاحقاً"]

الشكل 2: افتراضية UAC إجراء انتقالي لعمليات 32 بت بلا بيان، ولا يمكن الاعتماد عليها دائماً.

ملاحظة جانبية عن افتراضية DPI: تطبيقاً لم يعلن وعي DPI يُعامَل كأنّه يرسم عند 96 DPI (100٪)، وويندوز يمدّد الصورة النقطية للعرض. لذلك تبدو التطبيقات القديمة «ضبابية» على شاشة عالية الـ DPI، و«تجاوز سلوك تحجيم DPI العالي» في علامة التوافق هو المفتاح الذي يغيّر سلوك هذه الافتراضية.¹¹

flowchart TB
    accTitle: كيف تعمل افتراضية DPI
    accDescr: تطبيق لم يعلن وعي DPI يُعامل كأنه يرسم عند 96 DPI؛ ويندوز يمدد الصورة النقطية فتبدو ضبابية، وتجاوز إعدادات DPI العالي في علامة التوافق يبدّل سلوك هذه الافتراضية
    app["تطبيق لا يعلن وعي DPI"] --> treat["يُعامل كأنه يرسم عند 96 DPI"]
    treat --> stretch["تُمدَّد الصورة النقطية للعرض"]
    stretch --> blur["يبدو ضبابياً على شاشة عالية DPI"]
    tab["تجاوز سلوك تحجيم DPI العالي"] -.->|يبدّل سلوك الافتراضية| treat

الشكل 3: تطبيق غير واعٍ بـ DPI يُعامَل كـ 96 DPI ويُمدَّد؛ تجاوز علامة التوافق هو مفتاح هذه الافتراضية.

3. ما هو الـ Shim حقّاً — اعتراض بين الواجهات بإعادة كتابة الـ IAT

3.1. «المترجم» الذي يقف بين التطبيق ونظام التشغيل

تنفيذي ويندوز (صيغة PE) يستدعي واجهات في مكتبات DLL خارجية عبر جدول عناوين الاستيراد (IAT). عندما يستدعي التطبيق GetVersionEx فإنّه يقفز فقط إلى العنوان المكتوب في الـ IAT. آلية الـ shim تستغل ذلك. عند التحميل تعيد كتابة مدخل الـ IAT للواجهة المستهدفة إلى عنوان شيفرة الـ shim وتُدخل نفسها بين التطبيق وويندوز. الواجهات المحصولة ديناميكياً عبر GetProcAddress تُعالَج بخطف GetProcAddress نفسه.³

بعد الاعتراض قد يعيد shim رقم إصدار قديماً على «ما إصدار نظام التشغيل الحالي؟»، أو يعيد تعيين وصول ملف إلى موضع غير قابل للكتابة إلى موضع آخر، ثم يستدعي الواجهة الحقيقية إن لزم. من وجهة نظر التطبيق كأنّه «يعمل على ويندوز قديم»؛ من وجهة نظر النظام كأنّ «تطبيقاً حسن السلوك يعمل» — الـ shim هو المترجم بينهما.

flowchart TB
    accTitle: مسار اعتراض Shim لاستدعاء API
    accDescr: استدعاء API من التطبيق يمر عبر IAT؛ إعادة كتابة مدخل IAT إلى الـ shim عند التحميل تتيح الاعتراض وتزييف الاستجابة نفسها التي كان ويندوز القديم يعطيها ثم استدعاء الواجهة الحقيقية إن لزم
    app["التطبيق"] -->|استدعاء API| iat["مدخل IAT"]
    iat -->|يُعاد كتابته إلى الـ shim عند التحميل| shim["Shim (مترجم)"]
    shim -->|إن لزم| api["واجهة ويندوز الحقيقية"]
    shim -.-> lie["يزيّف الاستجابة نفسها التي كان ويندوز القديم يعطيها"]
    gpa["استدعاءات عبر GetProcAddress"] -.->|تُعالَج بخطف| shim

الشكل 4: يعترض الـ shim بين التطبيق وواجهة ويندوز. ما يُعاد كتابته هو IAT جانب التطبيق؛ النظام نفسه لا يتغيّر.

ثلاث خصائص مهمّة تتبع هذا التصميم.³

1. الـ shim يعمل كشيفرة جانب التطبيق. ليس جزءاً من النظام، لذا يخضع لقيود الأمن نفسها التي يخضع لها التطبيق. لا يستطيع shim تجاوز آليات أمن النظام، ولا تحتاج إلى تخفيف إعدادات الأمن لاستخدام shim.
2. ما يصلحه shim يصلحه أيضاً تعديل شيفرة في التطبيق. الـ shim بديل لحالات «لا شيفرة / لا نستطيع الإصلاح»؛ ليس أقوى من تعديل الشيفرة.
3. وضع المستخدم فقط. مشكلات التوافق في برامج تشغيل الأجهزة التي تعمل في وضع النواة لا يصلحها shim.

3.2. قاعدة بيانات الـ Shim (.sdb) والمطابقة

جدول التقابل «أيّ shim يُطبَّق على أيّ EXE» هو قاعدة بيانات الـ shim، ملف ثنائي بامتداد .sdb. تُسجَّل تنفيذيات التطبيق المستهدف في القاعدة بصفات مثل اسم الملف والحجم والمجموع الاختباري والإصدار (صفات المطابقة)، وتُطابَق عند بدء العملية. العلاجات تشمل Appfix (shim) الذي يحقن خطاف API، وApphelp الذي يعرض رسالة «لهذا التطبيق مشكلة توافق». حزمة من عدّة shims وأعلام هي طبقة توافق (وضع التوافق).¹

يسهل تفويته: هذه المطابقة لا تجري فقط على تطبيقات ضُبط لها وضع التوافق، بل عند كلّ إطلاق عملية. ويندوز يشحن قاعدة قياسية للنظام بإصلاحات لآلاف التطبيقات المعروفة (الملفات تحت %WINDIR%\AppPatch)، وعلى حاسوبك اليوم يكاد يكون تطبيق قديم ما يبدأ وshim ملحق به دون أن ينتبه أحد. إصلاحات التوافق التي تقدّمها مايكروسوفت تُشحَن كجزء من ويندوز وتُحدَّث عبر Windows Update.³

flowchart TB
    accTitle: مطابقة قاعدة بيانات الـ shim عند بدء العملية
    accDescr: كل إطلاق عملية يُطابق مع قاعدة الـ shim؛ إن طابق تسجيل صفات المطابقة يحقن Appfix شيمًا أو يعرض Apphelp رسالة وإلا تبدأ العملية كما هي
    start["بدء العملية"] --> db["مطابقة مع .sdb"]
    db -.-> attr["اسم الملف والحجم وغيرها"]
    db --> hit{"تسجيل؟"}
    hit -->|نعم| appfix["Appfix: حقن shim"]
    hit -->|نعم| apphelp["Apphelp: رسالة"]
    hit -->|لا| plain["ابدأ كما هي"]
    layer["طبقة توافق"] -.->|حزمة shims وأعلام| appfix

الشكل 5: المطابقة تجري عند كلّ إطلاق عملية، لا على التطبيقات المضبوط لها وضع التوافق فقط.

3.3. PCA — الآلية التي تطبّق الـ Shims تلقائياً

مسار آخر يمكن أن يُطبَّق فيه shim دون قصد المسؤول هو PCA (Program Compatibility Assistant). يراقب PCA تنفيذ التطبيق، وعندما يكشف علامات مشكلة توافق معروفة يقترح على المستخدم تطبيق إصلاح أو، في بعض الحالات، يطبّق إعداد توافق تلقائياً. مثلاً تطبيق ينهار باستدعاء شيفرة داخل DLL محرَّرة يُسنَد إليه PINDLL، وتطبيق يفشل في الكتابة إلى ملف ويندوز محمي يُسنَد إليه WRPMITIGATION.⁵

flowchart TB
    accTitle: كيف يطبّق PCA إعداد توافق تلقائياً
    accDescr: يراقب PCA تنفيذ التطبيق وعندما يكشف علامات مشكلة توافق معروفة يقترح تطبيق إصلاح على المستخدم أو في بعض الحالات يطبّق إعداد توافق تلقائياً
    run["تنفيذ التطبيق"] --> pca["PCA يراقب"]
    pca --> sign{"علامات مشكلة معروفة؟"}
    sign -->|نعم| resp{"أي حالة؟"}
    resp -->|تُعالَج باقتراح| suggest["اقتراح تطبيق إصلاح"]
    resp -->|بعض الحالات| auto["تطبيق إعداد توافق تلقائياً"]
    sign -->|لا| none["شغّل كما هو"]
    auto -.-> ex["مثال: PINDLL أو WRPMITIGATION"]

الشكل 6: يراقب PCA تنفيذ التطبيق، وعندما يكشف علامات مشكلة معروفة يقترح إصلاحاً أو يطبّقه تلقائياً.

هوية «لم أضبط شيئاً، لكن في لحظة كان مربّع وضع التوافق مؤشَّراً» هي في حالات كثيرة هذا. ليست عطلاً ولا نقراً خاطئاً؛ إنّه ويندوز يتصرّف كما صُمّم.

4. ما تستطيعه الـ Shims التمثيلية

من الـ shims الجاهزة التي تنشرها مايكروسوفت، هذا اختيار يظهر كثيراً فعلاً عند إطالة عمر تطبيق أعمال.⁴

بالنظر إلى القائمة، معظم الـ shims «كذبة تعيد الإجابة التي يتوقّعها التطبيق القديم». القرص 2 جيجابايت كحدّ أقصى، النظام إكس بي، أنت مسؤول — تعيد داخل تلك العملية فقط رؤية العالم في عصر ولادة التطبيق.

تزييف الإصدار صار «سلوكاً افتراضياً رسمياً»

تزييف الإصدار ليس خدعة خاصّة. من ويندوز 8.1 فصاعداً تعتمد القيمة التي يعيدها GetVersionEx على بيان التطبيق. تطبيق بلا إعلان <supportedOS> في قسم <compatibility> من البيان يُعطى دائماً ما يعادل ويندوز 8 (6.2)، مهما كان النظام الفعلي. عند وجود إعلان تُعاد القيمة حتى أعلى نظام معلَن (مثلاً إن أعلنت حتى معرّف ويندوز 8.1 تحصل على 6.3 حتى على ويندوز 11).⁶⁷

إذن «إصدار ويندوز الذي يراه التطبيق» يُقرَّر في هذه المراحل المتراكبة.

1. تُعاد القيمة حتى النظام المعلَن في البيان (6.2 إن لم يكن إعلان)
2. إن طُبِّق وضع التوافق (shim من عائلة VersionLie) يُعاد إصدار النظام المختار⁶

flowchart TB
    accTitle: كيف يُقرَّر إصدار النظام الذي يراه التطبيق
    accDescr: القيمة التي يعيدها GetVersionEx تُقرَّر بوجود إعلان supportedOS في البيان؛ بلا إعلان يُعاد 6.2 المعادل لويندوز 8 ومع إعلان تُعاد القيمة حتى أعلى نظام معلن وإن طُبّق shim من عائلة VersionLie تُكتب فوقها بإصدار النظام المختار
    q["استعلام GetVersionEx"] --> m{"هل يوجد إعلان supportedOS؟"}
    m -->|لا| v62["يُعاد معادل ويندوز 8 (6.2)"]
    m -->|نعم| decl["القيمة حتى أعلى نظام معلن"]
    v62 --> lie{"هل طُبّق shim من عائلة VersionLie؟"}
    decl --> lie
    lie -->|نعم| fake["قيمة النظام المختارة في وضع التوافق"]
    lie -->|لا| asis["تُعاد القيمة كما هي"]

الشكل 7: إصدار ويندوز الذي يراه التطبيق يُقرَّر بمراحل متراكبة من البيان ومن الـ shims.

إن كان تطبيق داخلي «يتفرّع حسب إصدار النظام، وبشكل مربك يُحكَم عليه بأنّه 8 رغم أنّ هذا ويندوز 11»، اشتبه أوّلاً في إعلان supportedOS في البيان. بالعكس، تطبيقاً قديماً يرفض البدء بناء على فحص إصدار يمكن، باحتمال عالٍ، تمريره بـ shim من عائلة VersionLie. في حالات كثيرة ينظر إلى رقم الإصدار فقط، والسلوك الفعلي سليم على نظام أحدث.

flowchart TB
    accTitle: عَرَضان بسبب الإصدار وكيفية التعامل
    accDescr: إن حُكم على تطبيق داخلي بأنه 8 رغم أن هذا ويندوز 11 فاشتبه في إعلان supportedOS في البيان؛ تطبيقاً قديماً يرفض البدء بفحص إصدار يمكن تمريره غالباً بـ VersionLie
    sym1["حُكم عليه بأنه 8 رغم أن هذا ويندوز 11"] --> fix1["اشتبه في إعلان supportedOS"]
    sym2["رفض البدء بفحص إصدار"] --> fix2["جرّب التمرير بـ VersionLie"]
    fix2 -.-> why["السلوك الفعلي غالباً سليم على نظام أحدث"]

الشكل 8: عندما يكون الحكم قديماً اشتبه في البيان؛ عندما يُرفض البدء اشتبه في VersionLie.

5. ماذا يفعل مربّع وضع التوافق

إعدادات خصائص → علامة تبويب التوافق تُخزَّن في مفتاح السجلّ AppCompatFlags\Layers. إعدادات توافق تطبيقات DXGI ونحوها تستخدم المفتاح نفسه مكاناً لتحديد طبقة توافق.² لننظر فعلاً.

reg query "HKCU\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers"

لـ EXE ضبطت عليه «ويندوز إكس بي (حزمة الخدمة 3)» و«تشغيل هذا البرنامج كمسؤول» و«تجاوز سلوك تحجيم DPI العالي» في علامة التوافق سترى قيمة مثل التالية.

HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers
    C:\LegacyApp\Gyomu.exe    REG_SZ    ~ WINXPSP3 RUNASADMIN HIGHDPIAWARE

تقابلات تمثيلية بين عناصر المربّع والقيم (مؤكَّدة على ويندوز 11؛ أسماء العناصر والقيم قد تتغيّر حسب إصدار النظام).

ثلاث نقاط تُحفَظ.

• «تشغيل هذا البرنامج كمسؤول» يُكتَب في المكان نفسه. وضع التوافق وعلم الرفع يعيشان معاً في مفتاح Layers نفسه، ومن هناك يولد الالتباس «ضبطت وضع التوافق فجاء الرفع / اختفى». النظر إلى القيمة مباشرة يفصل الاثنين.
• ما يُكتَب في HKCU هو «إعداد ذلك المستخدم». إن ضبطته من «تغيير الإعدادات لجميع المستخدمين» في العلامة يُكتَب إلى المفتاح الذي يحمل الاسم نفسه في جانب HKLM ويسري على جميع المستخدمين. عند التوزيع بالتصوير انتبه إلى أيّ جانب تكتب.
• المربّع مدخل إلى الطبقات الجاهزة فقط. العلامة تتيح اختيار طبقات تمثيلية فقط؛ لا تستطيع اختيار shims فردية وتركيبها. ذلك ما يفعله Compatibility Administrator في الفصل التالي.

flowchart TB
    accTitle: المسار من إعداد علامة التوافق إلى السريان
    accDescr: إعدادات علامة التوافق تُخزَّن كمسار EXE وقيمة في مفتاح Layers لـ AppCompatFlags؛ في المرة التالية التي يبدأ فيها ذلك الـ EXE يقرأ المحمّل القيمة ويطبّق طبقة التوافق المقابلة على العملية
    tab["ضبط في علامة التوافق"] --> reg["تخزين مسار EXE والقيمة في مفتاح Layers"]
    reg --> boot["بدء EXE التالي"]
    boot --> loader["المحمّل يقرأ القيمة"]
    loader --> apply["تطبيق طبقة التوافق على العملية"]
    reg -.-> hkcu["HKCU لذلك المستخدم فقط"]
    reg -.-> hklm["HKLM يسري على جميع المستخدمين"]

الشكل 9: المربّع في الواقع كتابة إلى مفتاح Layers، والتطبيق يحدث عند البدء التالي.

6. Compatibility Administrator عملياً — بناء قاعدة .sdb مخصّصة وتوزيعها

6.1. كيف تحصل عليه، والتحفّظات

Compatibility Administrator أداة مضمَّنة في Windows ADK (Windows Assessment and Deployment Kit).¹² بعد التثبيت توجد النسختان 32 بت و64 بت، ويجب استخدام نسخة 32 بت لتطبيقات 32 بت ونسخة 64 بت لتطبيقات 64 بت.¹³

هناك تحفّظ مهمّ آخر. إن بدأت Compatibility Administrator مرفوعاً (كمسؤول) واختبرت، فإنّ افتراضية UAC والتحويل لا يتصرّفان كما يتصرّفان لمستخدم حقيقي، وقد تحكم خطأً أنّ «الأمر أُصلح». أكّد دائماً أثر الإصلاح بنفس الحساب والامتيازات التي للمستخدم الفعلي.⁴

flowchart TB
    accTitle: تحفّظان عند استخدام Compatibility Administrator
    accDescr: استخدم نسخة 32 بت لتطبيقات 32 بت ونسخة 64 بت لتطبيقات 64 بت، وأكّد أثر الإصلاح بنفس حساب وامتيازات المستخدم الفعلي لا في حالة رفع
    app32["تطبيق 32 بت"] --> tool32["استخدم نسخة 32 بت"]
    app64["تطبيق 64 بت"] --> tool64["استخدم نسخة 64 بت"]
    elev["اختبار في حالة رفع"] -.-> wrong["قد تحكم خطأً على إصلاح"]
    user["اختبار بامتيازات المستخدم الفعلي"] --> ok["أكّد الأثر"]

الشكل 10: اختيار نسخة 32 بت أو 64 بت، والتأكيد بنفس امتيازات المستخدم الفعلي، هما تحفّظا المدخل.

6.2. إجراء بناء قاعدة توافق مخصّصة

المخطّط كالتالي.¹⁴

1. في الجزء الأيسر من Compatibility Administrator أنشئ قاعدة جديدة تحت «Custom Databases» واختر «Create New» → «Application Fix»
2. أدخل اسم التطبيق واسم البائع وحدّد ملف الـ EXE المستهدف
3. اختر وضع التوافق (الطبقة) المراد تطبيقه — تجربة حزمة مثل «توافق ويندوز إكس بي» أوّلاً هي الطريق القصير
4. إن لزم أضف إصلاحات توافق فردية (shims) — تستطيع تضييقها إلى مجموعة دنيا مثل VersionLie فقط أو CorrectFilePaths فقط
5. أكّد شروط المطابقة (حجم الملف والمجموع الاختباري والإصدار وما إليه) واحفظ

شروط المطابقة مفتاح «طبّق هذا على هذا الـ EXE فقط». الشروط الأساسية الافتراضية تكفي عادة، لكنّنا نوصي بترك شرط يستطيع تحديد إصدار التطبيق. ذلك يمنع حادث استمرار كذبة قديمة على إصدار جديد عندما يشحن البائع لاحقاً طبعة مصلحة.¹⁴¹⁵

flowchart TB
    accTitle: إجراء بناء قاعدة توافق مخصّصة
    accDescr: أنشئ Application Fix في قاعدة جديدة وحدّد اسم التطبيق والـ EXE المستهدف وجرّب حزمة وضع توافق أولاً ثم ضيّق إلى shims فردية إن لزم وأكّد شروط المطابقة واحفظ
    new["إنشاء قاعدة جديدة"] --> fix["اختيار Application Fix"]
    fix --> info["تحديد اسم التطبيق والـ EXE المستهدف"]
    info --> layer["تجربة حزمة وضع توافق"]
    layer --> single["إن لزم التضييق إلى shims فردية"]
    single --> match["تأكيد شروط المطابقة والحفظ"]
    match -.-> ver["ترك شرط يحدّد الإصدار"]

الشكل 11: لـ Application Fix جرّب حزمة وضع توافق أوّلاً، ضيّق إلى مجموعة دنيا، وقيّد الهدف بشروط المطابقة.

اختبر ملف الـ .sdb الذي أنشأته على آلة تحقّق أوّلاً. متى عمل كما قُصد تُنشره على المنظّمة.

6.3. التوزيع بـ sdbinst

الأمر الذي يطبّق .sdb مخصّصاً على كلّ حاسوب هو sdbinst.exe (يتطلّب امتيازات مسؤول).¹⁵

:: Install (-q is silent with no confirmation)
sdbinst -q "C:\Deploy\MyCorpFixes.sdb"

:: Uninstall (by file)
sdbinst -q -u "C:\Deploy\MyCorpFixes.sdb"

:: Uninstall (by database GUID)
sdbinst -q -u -g {database GUID}

كاستراتيجية نشر تنظيمي توصي مايكروسوفت بالدمج في قاعدة مخصّصة واحدة على مستوى الشركة (أو القسم) وإدارتها مركزياً، بدل شحن .sdb منفصل مع مثبّت كلّ تطبيق. كلّما كثرت الإصلاحات سهُل تحديث قاعدة واحدة وإعادة توزيعها أكثر من توزيع قواعد سطر واحد كثيرة. للقاعدة المخصّصة GUID خاص، وتثبيت إصدار جديد بنفس الـ GUID يستبدل الإصدار القديم تلقائياً، فتبقى عمليات التحديث بسيطة أيضاً. ضع التوزيع نفسه على مسار قائم يستطيع التشغيل بامتيازات مسؤول، مثل التعبئة كـ MSI أو سكربت بدء تشغيل.¹⁵

flowchart TB
    accTitle: المسار من إنشاء .sdb مخصّص إلى توزيعه
    accDescr: أنشئ قاعدة توافق مخصّصة في Compatibility Administrator واختبرها على آلة تحقّق وطبقها على كل حاسوب بـ sdbinst وعند التحديث ثبّت إصداراً جديداً بنفس الـ GUID فيُستبدل القديم تلقائياً
    make["الإنشاء في Compatibility Administrator"] --> test["الاختبار على آلة تحقّق"]
    test --> deploy["التطبيق على كل حاسوب بـ sdbinst"]
    deploy --> update["تثبيت إصدار جديد بنفس الـ GUID"]
    update -.-> replace["يُستبدل الإصدار القديم تلقائياً"]
    deploy -.-> inv["التسجيل في البرامج والميزات"]

الشكل 12: يُنشر .sdb مخصّص عبر الإنشاء والتحقّق وتوزيع sdbinst، وتُدار التحديثات بالـ GUID.

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

7. الحالات التي لا تعمل فيها، والحدود

الـ shims ليست رصاصة فضّية. بالتصميم لا تعمل في الحالات التالية.

• مشكلات وضع النواة. الـ shim يعمل داخل عملية وضع مستخدم، لذا لا يُصلح عدم توافق برنامج تشغيل جهاز. إن كان برنامج تشغيل جهاز قياس قديم أو قفل USB أو طابعة لا يدعم ويندوز 11، فلن يحلّ شيء تطبّقه على جانب التطبيق. الشيفرة التي تعمل في النواة، مثل أجزاء من برمجيات مكافحة الفيروسات، سواء.³
• تطبيقات 16 بت. ويندوز 64 بت لا يدعم تشغيل تطبيقات 16 بت. للمقابض 32 بتّاً صالحاً على ويندوز 64 بت ولا يمكن اقتطاعها لتمريرها إلى تطبيق 16 بت، لذا يفشل البدء بـ ERROR_BAD_EXE_FORMAT.⁸ حتى عندما يكون التطبيق نفسه 32 بت توجد حزم من ذلك العصر كعب المثبّت فيها 16 بت، وتظهر كـ «التطبيق كان سيعمل، لكنّنا لا نستطيع تثبيته».
• الوصول المباشر للعتاد. تطبيقات صناعية تفترض أنّها تستطيع لمس منافذ الإدخال/الإخراج أو الذاكرة المادية مباشرة غير مسموح لها بذلك من وضع المستخدم على ويندوز الحديث أصلاً، وذلك خارج نطاق ما يستطيع shim تزييفه.
• تجاوز آليات الأمن. لأنّ الـ shim يعمل تحت قيود الأمن نفسها التي للتطبيق، لا يستطيع جعل «شيء لا تستطيعه لانعدام الامتياز» ممكناً. ForceAdminAccess وWRPMitigation فقط يزيّفان نجاح فحص أو كتابة كي يتابع التطبيق؛ ليسا إعادة كتابة مورد محمي فعلاً.³⁴
• تطبيقات تفحص سلامتها بنفسها. تطبيقات بحماية نسخ قديمة أو كشف عبث قد تعامل خطاف الـ API نفسه كشذوذ وتتوقف.

flowchart TB
    accTitle: حالات لا يعمل فيها الـ shim
    accDescr: الـ shim يعمل داخل عملية وضع مستخدم لذا لا يعمل على مشكلات برامج تشغيل النواة ولا تطبيقات 16 بت ولا الوصول المباشر للعتاد ولا تجاوز آليات الأمن
    shim["Shim (يعمل في وضع المستخدم)"] -->|لا يعمل| drv["برنامج تشغيل النواة"]
    shim -->|لا يعمل| b16["تطبيق 16 بت"]
    shim -->|لا يعمل| hw["وصول مباشر للعتاد"]
    shim -->|لا يعمل| sec["تجاوز آليات الأمن"]
    b16 -.-> fmt["على 64 بت يفشل البدء نفسه"]
    sec -.-> fake["يزيّف النجاح فقط كي يتابع التطبيق"]

الشكل 13: الـ shim وضع مستخدم فقط ولا يصل إلى النواة ولا تطبيقات 16 بت ولا الوصول المباشر للعتاد ولا تجاوز الأمن.

والحدّ الجوهري المشترك لكلّ shim أنّه ترقيع. الـ shim كذبة مفصّلة لاستخدام معيّن لواجهة معيّنة، وإن تغيّر تنفيذ جانب النظام ينهار الافتراض. الـ shims التي تقدّمها مايكروسوفت تُصان كجزء من ويندوز عبر Windows Update،³ لكن رعاية الأكاذيب التي طبّقتها بقاعدة مخصّصة عمل منظّمتك. احسب، ككلفة إطالة العمر، عملية تحقّق من «قائمة التطبيقات المُبقاة حيّة بالـ shims» عند كلّ تحديث ميزات.

flowchart TB
    accTitle: الـ shims كترقيع ومن المسؤول عن صيانتها
    accDescr: الـ shim كذبة مفصّلة لاستخدام واجهة معيّن وينهار الافتراض إن تغيّر تنفيذ جانب النظام؛ shims مايكروسوفت تُصان عبر Windows Update أما رعاية أكاذيب القاعدة المخصّصة فعمل المنظّمة والتحقّق عند كل تحديث ميزات كلفة إطالة العمر
    shim["Shim = كذبة ترقيعية"] --> break["تغيير النظام يكسرها"]
    ms["Shims مايكروسوفت"] --> wu["عبر Windows Update"]
    own["أكاذيب القاعدة المخصّصة"] --> self["المنظّمة ترعاها"]
    self --> cost["التحقّق عند كل تحديث كلفة إطالة العمر"]

الشكل 14: مسؤولية صيانة كذبة الـ shim منقسمة بين المجموعة التي تقدّمها مايكروسوفت والمجموعة المخصّصة لمنظّمتك.

8. القيمة العملية لـ RunAsInvoker — إسكات طلب الرفع فقط

بين الـ shims، الأكثر ظهوراً في عمل تقنية المعلومات اليومي هو RunAsInvoker.

بعض تطبيقات الأعمال القديمة تعلن requireAdministrator في البيان، أو تُكشَف خطأً كمثبّت من اسم الـ EXE أو محتواه، وتطلب رفع UAC في كلّ بدء. كثير منها مع ذلك يطلب المسؤول من قصور عصر إكس بي ولا يستخدم امتيازات المسؤول فعلاً. تطبيق Shim RunAsInvoker يكتب فوق كشف المثبّت والبيان معاً، ويبدأ التطبيق بالرمز الموروث من العملية الأم (= امتيازات مستخدم عادي).⁹

flowchart TB
    accTitle: كيف يكبت RunAsInvoker طلب الرفع
    accDescr: إعلان requireAdministrator في البيان أو الكشف الخطأ كمثبّت يسبّب طلب رفع UAC عند البدء لكن تطبيق RunAsInvoker يكتب فوق الاثنين ويبدأ التطبيق برمز العملية الأم
    manifest["إعلان requireAdministrator"] --> shim{"هل طُبّق RunAsInvoker؟"}
    detect["كُشف خطأً كمثبّت"] --> shim
    shim -->|لا| uac["طلب رفع UAC عند كل بدء"]
    shim -->|نعم| token["يبدأ برمز العملية الأم"]
    token -.-> limit["العمل الذي يحتاج مسؤولاً حقاً يفشل داخل التطبيق"]

الشكل 15: RunAsInvoker يكتب فوق سبب طلب الرفع فقط؛ الامتيازات لا تزيد.

حتى دون بناء .sdb في Compatibility Administrator تستطيع تطبيق الطبقة نفسها مؤقّتاً بمتغيّر البيئة __COMPAT_LAYER.

:: Apply RunAsInvoker to child processes started from this command prompt
set __COMPAT_LAYER=RunAsInvoker
start "" "C:\LegacyApp\Gyomu.exe"

# In PowerShell
$env:__COMPAT_LAYER = 'RunAsInvoker'
Start-Process 'C:\LegacyApp\Gyomu.exe'

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

flowchart TB
    accTitle: أثر توزيع دفعة RunAsInvoker
    accDescr: توزيع دفعة سطرين تضبط RunAsInvoker كاختصار يعني تجنّب تسليم امتيازات المسؤول للمستخدمين العاديين وعدم استدعاء تقنية المعلومات لكلمة مرور UAC وتشغيل يتبع أقل امتياز
    bat["توزيع دفعة سطرين"] --> noadmin["تستطيع تجنّب تسليم امتيازات المسؤول"]
    bat --> nocall["لا تُستدعى تقنية المعلومات لأجل UAC"]
    noadmin --> lp["تشغيل يتبع أقل امتياز"]
    nocall --> lp

الشكل 16: توزيع دفعة وحدها يستطيع تقليل تسليم امتيازات المسؤول والاستدعاء لأجل UAC معاً.

التحفّظات أيضاً، بوضوح.

• الامتيازات لا تزيد. العمل الذي يحتاج امتيازات مسؤول حقاً (كتابات إلى HKLM، تحديثات تحت Program Files، وما إليه) سيخطئ داخل التطبيق، أو، إن تحقّقت الشروط، سيُحوَّل إلى VirtualStore بافتراضية UAC.¹⁰ إن «توقّف» حفظ الإعدادات فجأة فاشتبه في الافتراضية.
• طريقة متغيّر البيئة تسري على العمليات الابن فقط. لتطبيق دائم، إعداد مباشر في مفتاح Layers (ليس لـ RUNASINVOKER عنصر في العلامة) أو توزيع عبر .sdb موثوق.
• إصلاح وجهة الكتابة هو المسار الحقيقي. إن استطعت تغيير التطبيق فانقل ملف الإعدادات تحت %APPDATA% وأعلن asInvoker في البيان — ذلك الشكل الصحيح.⁹

flowchart TB
    accTitle: التطبيق المؤقّت والدائم لـ RunAsInvoker
    accDescr: التطبيق عبر متغيّر COMPAT_LAYER يسري فقط على العمليات الابن التي تبدأ من هناك؛ للتطبيق الدائم استخدم إعداداً مباشراً في مفتاح Layers أو توزيعاً عبر .sdb
    env["ضبط عبر متغيّر بيئة"] --> child["يسري على العمليات الابن فقط"]
    child -.-> tmp["تطبيق مؤقّت"]
    layers["ضبط مباشر في مفتاح Layers"] --> always["تطبيق دائم"]
    sdb["توزيع عبر sdb"] --> always

الشكل 17: طريقة متغيّر البيئة تطبيق مؤقّت محدود بالعمليات الابن؛ جعله دائماً يتمّ بمفتاح Layers أو .sdb.

9. القرار بين إطالة العمر والترحيل — ماذا تفكّر بعد أن يعمل تحت Shim

لحظة عمله تحت shim راحة، لكن المهمّ ألا يتوقّف التفكير هناك. العمل تحت shim يعني فقط أنّه صادف وعاءً أعدّه ويندوز. محاور القرار، في جدول.

إن قرّرت إطالة العمر فأدخل النقاط الثلاث التالية في التشغيل كمجموعة.

1. سجّل. أيّ EXE، أيّ shim/طبقة، ولماذا. اترك قيمة مفتاح Layers وGUID الـ .sdb في دفتر. «لا أحد يعرف لماذا يعمل» أكبر دين تتركه للشخص التالي. هذه نفس عقلية الحفظ المشروحة في «عندما ترث نظاماً بلا شيفرة مصدريّة ولا مواصفات».
2. تحقّق. أدخل بدء العمليات الرئيسية للتطبيقات المُبقاة حيّة بالـ shims في بنود التحقّق لتحديث ميزات ويندوز. اربطه أيضاً بخطة استبدال النظام (Practical Options After Windows 10 End of Support).
3. ضع مهلة. قرّر نهاية إطالة العمر — «حتى التحديث التالي للنظام الجوهري»، «حتى مارس 2028» — وأدر اعتبار الترحيل بالتوازي.

flowchart TB
    accTitle: مجموعة التشغيل ذات النقاط الثلاث بعد قرار إطالة العمر
    accDescr: سجّل في دفتر أي shim يجعله يعمل وتحقّق من سلوك التطبيقات المُبقاة حيّة بالـ shims عند كل تحديث ميزات وضع مهلة لنهاية إطالة العمر وأدر اعتبار الترحيل بالتوازي
    decide["قرار إطالة العمر"] --> rec["سجّل: أي shim يجعله يعمل في دفتر"]
    rec --> verify["تحقّق: أكّد السلوك عند كل تحديث ميزات"]
    verify --> deadline["مهلة: قرّر نهاية إطالة العمر"]
    deadline --> mig["أدر اعتبار الترحيل بالتوازي"]

الشكل 18: تُدار إطالة العمر كمجموعة من ثلاث نقاط: تسجيل وتحقّق ومهلة، بما فيه اعتبار الترحيل بالتوازي.

في جانب الترحيل تتغيّر الخيارات القياسية مع تقنية التطبيق. لـ VB6 الاختيار الثلاثي لإعادة الكتابة الكاملة والتحويل التلقائي والترحيل المرحلي المنظَّم في «إلى متى ستستمرّ تطبيقات VB6 في العمل»؛ لاعتماد ActiveX/OCX جدول قرار الإبقاء / التغليف / الاستبدال في «كيف تتعامل مع ActiveX / OCX اليوم». الطريقة السليمة لوضع shim هي شراء وقت كي تسير فترة الاعتبار والتحضير لمشروع الترحيل ذلك بأمان.

flowchart TB
    accTitle: خيارات جانب الترحيل وأين يجلس الـ shim
    accDescr: خيارات الترحيل القياسية تتغيّر مع تقنية التطبيق؛ لـ VB6 الاختيار الثلاثي إعادة كتابة أو تحويل تلقائي أو ترحيل مرحلي ولاعتماد ActiveX جدول الإبقاء أو التغليف أو الاستبدال والـ shim يُوضع كشراء وقت لاعتبار مشروع الترحيل وتحضيره
    tech{"ما تقنية التطبيق؟"} -->|VB6| vb["إعادة كتابة أو تحويل تلقائي أو ترحيل مرحلي"]
    tech -->|اعتماد ActiveX| ax["إبقاء أو تغليف أو استبدال"]
    shim["إطالة عمر عبر shim"] -.->|يشتري وقتاً للاعتبار والتحضير| tech

الشكل 19: تُقرَّر خيارات الترحيل القياسية بتقنية التطبيق، ويُوضَع الـ shim كشراء وقت لذلك الاعتبار.

10. الخلاصة

• الهوية الحقيقية لوضع التوافق هي الـ shims. إعدادات علامة التوافق تُكتَب إلى مفتاح AppCompatFlags\Layers وتُحقَن في العملية عند البدء كخطاف API عبر إعادة كتابة الـ IAT.
• الـ shims مجموعة «أكاذيب تعيد الإجابة التي يتوقّعها التطبيق القديم». تُوفَّر shims جاهزة لتزييف الإصدار وإعادة تعيين المسارات وتزييف السجلّ وتزييف فحوص المسؤول ونحوها.
• ويندوز نفسه يستخدم عدداً كبيراً من الـ shims افتراضياً، وPCA يستطيع تطبيقها تلقائياً. الاعتماد على وضع التوافق نفسه اختيار معقول يركب آلية رسمية للنظام.
• هناك حدّ مبدئي لوضع المستخدم فقط بلا تجاوز أمن، وبرامج تشغيل النواة وتطبيقات 16 بت والوصول المباشر للعتاد لا تُنقَذ.
• النشر التنظيمي بناء .sdb مخصّص في Compatibility Administrator (Windows ADK) وتوزيعه بـ sdbinst. اختيار نسخة 32 بت/64 بت والاختبار بحساب المستخدم الفعلي وإدارة التحديثات بالـ GUID هي النقاط العملية.
• التطبيقات التي «تتطلّب مسؤولاً لكنّها لا تحتاجه فعلاً» يمكن إنزالها إلى امتيازات عادية بـ __COMPAT_LAYER=RunAsInvoker. تقنية دفاعية تُسكت طلب الرفع بدل تسليم الامتيازات.
• العمل تحت shim إطالة عمر لا حلّ. تسجيل ما يجعله يعمل والتحقّق عند كلّ تحديث ميزات ووضع مهلة كي يسير الترحيل بالتوازي — تلك المجموعة الثلاثية داخلة في قرار «الاعتماد على وضع التوافق».

في المرّة التالية التي يبدأ فيها تطبيق قديم يعمل بعد مربّع وضع التوافق، اسأل هذا من جديد. «بأيّ كذبة يعمل هذا التطبيق؟ إلى متى ستبقى تلك الكذبة تعمل؟» إن استطعت الإجابة فإطالة العمر استراتيجية محترمة.

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

• Registry 32-bit/64-bit Redirection and Virtualization Pitfalls — Wow6432Node and the “The Value I Wrote Isn’t There” Problem
• إلى متى ستستمرّ تطبيقات VB6 في العمل ── وضع دعم بيئة التشغيل والمسار العمليّ للترحيل إلى .NET
• كيف تتعامل مع ActiveX / OCX اليوم - جدول قرار للإبقاء / التغليف / الاستبدال
• Practical Options After Windows 10 End of Support — A Decision Table for ESU, LTSC, and Replacement
• عندما ترث نظاماً بلا شيفرة مصدريّة ولا مواصفات ── الإجراءات العمليّة لتشغيله وصيانته دون توقّف
• تكامل صدفة ويندوز اليوم ── قوائم السياق وارتباطات الملف وما تغيّر في ويندوز 11

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

شركة كومورا سوفت ذ.م.م. تتولّى التحقيق في كيف تتصرّف تطبيقات أعمال قديمة بلا شيفرة مصدرية وتصميم إطالة عمرها (اختيار الـ shims ووضع التوافق، وبناء .sdb مخصّص ونشره)، وتحقّق توافق التطبيقات القائمة لترحيل ويندوز 11، وتخطيط إعادة كتابة أو ترحيل يسير بالتوازي مع إطالة العمر. الاستشارة من مرحلة «بدأ يعمل في وضع التوافق، لكن هل يجوز تركه هكذا؟» جائزة.

• دعم إعادة استخدام الأصول القديمة وترحيلها
• تطوير تطبيقات ويندوز
• الاستشارات التقنية ومراجعة التصميم
• التواصل معنا

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

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

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

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

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

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

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

إذا بدأ التطبيق يعمل بعد أن أشّرت وضع التوافق، هل يجوز الاستمرار هكذا؟

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

ماذا يفعل مربّع وضع التوافق فعلياً؟

عندما تحفظ الإعدادات في علامة تبويب التوافق بحوار الخصائص، يكتب ويندوز مسار الـ EXE المستهدف وقيمة مثل "WINXPSP3" أو "HIGHDPIAWARE" تحت المفتاح HKCU\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers. في المرّة التالية التي يبدأ فيها ذلك الـ EXE، يقرأ محمّل ويندوز القيمة ويطبّق طبقة التوافق المقابلة (حزمة shims) على العملية. وضع توافق ويندوز إكس بي مثلاً يزوّر إصدار نظام التشغيل بإرجاع قيمة قديمة من واجهات استعلام الإصدار. النظام نفسه لا يتغيّر؛ فقط تلك العملية تُعرَض عليها ويندوز أقدم مزعومة.

هل يمكن تشغيل تطبيقات عصر 16 بت تحت وضع التوافق على ويندوز 64 بت؟

لا. ويندوز 64 بت يشغّل تطبيقات 32 بت عبر WOW64، لكنّه لا يدعم تشغيل تطبيقات 16 بت، ومحاولة البدء تفشل بـ ERROR_BAD_EXE_FORMAT. هذا حدّ معماري لا يستطيع shim تجاوزه. الحزم القديمة التي كعب المثبّت فيها 16 بت تفشل للسبب نفسه. إن احتجتها حقاً فانظر خارج وضع التوافق — مثلاً آلة افتراضية تتضمّن ويندوز 32 بت.

هل يمكن تشغيل تطبيق «لن يبدأ إلا كمسؤول» تحت حساب مستخدم عادي؟

RunAsInvoker يستحق التجربة. إذا نفّذت set __COMPAT_LAYER=RunAsInvoker في موجّه الأوامر ثم بدأت التطبيق، تُكبت طلبات الرفع الآتية من بيان requireAdministrator أو من كشف المثبّت، ويبدأ التطبيق بنفس امتيازات المستدعي (مستخدم عادي). لتطبيق يطلب صلاحيات المسؤول ولا يستخدمها فعلاً، يكفي هذا لإخراج الرفع من التشغيل اليومي. الامتيازات لا تزيد، فالعمل الذي يحتاج صلاحيات مسؤول حقاً سيفشل داخل التطبيق. اعتمده فقط بعد التحقّق من السلوك.

من أين أحصل على Compatibility Administrator؟

مضمّن في Windows ADK (Windows Assessment and Deployment Kit). نزّل الـ ADK من موقع مايكروسوفت، وعند التثبيت اختر ميزات Application Compatibility Tools. تُثبَّت النسختان 32 بت و64 بت؛ يجب استخدام نسخة 32 بت لتطبيقات 32 بت ونسخة 64 بت لتطبيقات 64 بت. طبّق قاعدة توافق مخصّصة (.sdb) أنشأتها بتشغيل أمر sdbinst على كلّ حاسوب.

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

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

غو كومورا

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

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