انتهاء خدمة برامج تشغيل الطابعات في Windows ── كيف تستعد تطبيقات الأعمال لطباعة التقارير والملصقات

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

أوّل ما يُمسَك أن خطّة انتهاء خدمة برامج التشغيل وتفعيل Windows protected print mode أمران منفصلان. ليس لأن تاريخ الخطّة مرّ تتوقّف الطباعة القائمة دفعة واحدة. أمّا في مواضع يتغيّر فيها اختيار برنامج التشغيل، أو عند تفعيل Windows protected print mode، فتضيع الإعدادات ووجهات الطباعة التي كان التطبيق يعتمد عليها.¹²

هذه المقالة موجَّهة إلى المطوّرين الذين يصونون تطبيقات أعمال Windows مثل WinForms وWPF، وإلى المسؤولين الذين ينشرون الطابعات، وترتب ما يتغيّر، وما يُفحص، وأين يُصلح، وكيف يُتحقَّق بهذا الترتيب. لاختيار واجهة الطباعة وطريقة إخراج PDF نفسها راجع المقالة السابقة الطباعة وإخراج PDF في تطبيقات أعمال Windows.

البيئة المفترضة Windows 11 (التحقّق من WPP على 24H2 فما بعده)، وPowerShell 5.1 فما بعده (وحدة PrintManagement)، وC# (.NET 6 فما بعده أو .NET Framework 4.x، System.Drawing.Printing / System.Printing). الصعوبة متوسّطة.

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

لا تعيد كتابة شيفرة الطباعة جملة؛ أكّد أوّلاً أن وجهة الطباعة تبقى، ثم أصلح المواضع التي تعتمد على برنامج التشغيل.

ترتيب الحكم ثلاث مراحل.

إن كنت ترسم فقط بـ PrintDocument أو FixedDocument فأنت أساساً هدف تحقّق لا إصلاح. لكن إن اختفى طابور الوجهة نفسه أمام WPP وتعذّرت إعادة التسجيل، فلن تطبع ولو كانت شيفرة الرسم سليمة. تحتاج مساراً بديلاً أوّلاً.

إن بدأت من العمل فامضِ أخذ قائمة 5.1 ← الحكم على الوجهة بجداول الفصل 4 و5.1 ← تأكيد التبعيات في 5.2–5.5 ← اختيار المسار في الفصل 6 ← التحقّق في الفصل 7. خلفية ما يلتبس في الحكم مشروحة في الفصول 2–4.

فيما يلي نختصر Windows protected print mode إلى WPP. «الطابور» وجهة طباعة مسجَّلة في Windows، و«المُبَوِّب» الآلية التي تستقبل مهام الطباعة وتسلّمها إلى الوجهة.

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

2. ماذا تقرّر ── الخطّ الزمني على ثلاث مراحل

2.1 ما ينتهي هو التوريد والتحديث، لا إيقاف جماعي للبرامج القائمة

المصدر الأوّل صفحة Microsoft Learn «End of servicing plan for third-party printer drivers on Windows». أُعلنت الخطّة في أيلول/سبتمبر 2023، ورُوجعت التواريخ في أيّار/مايو 2025. الخطّة وقت الكتابة كما يلي.¹

تبقى البرامج القائمة قابلة للتثبيت من Windows Update ومن مثبّتات الصانع، وتقول Microsoft إنّها لا تخطّط لتعطيل وظائف برامج تشغيل v3/v4. أي أنّ هذه خطّة لإنهاء توريد برامج التشغيل وتحديثها تدريجيّاً، وليست خطّة تعطيل البرامج المثبَّتة على حواسيب الميدان في ذلك اليوم.¹

flowchart TB
    accTitle: ما يتغيّر وما لا يتغيّر بانتهاء الخدمة
    accDescr: انتهاء خدمة برامج تشغيل الطابعات نفسه لا يغيّر مدخل واجهة رسم التطبيق ولا البرامج القائمة، ولا تُستبدل قائمة الورق والوظائف الخاصّة واسم الطابور التي يعيدها برنامج التشغيل إلّا عندما يُختار برنامج آخر عند إدخال جديد أو إعادة اكتشاف، وتغيّرات تفعيل Windows protected print mode بما فيها حذف الطابعات الافتراضية آلية أخرى تُعالَج في الفصل 4
    eos["انتهاء خدمة برامج تشغيل الطابعات"]
    eos --> keep["ما لا يتغيّر"]
    eos --> cond["عندما يُختار برنامج آخر عند إدخال جديد أو إعادة اكتشاف"]
    cond --> change["ما يُستبدل"]
    keep --> api["مدخل واجهة الرسم"]
    keep --> drv["البرامج القائمة"]
    change --> caps["الورق والصواني والوظائف الخاصّة"]
    change --> qname["اسم الطابور"]

الشكل 1: انتهاء الخدمة وحده لا يغيّر شيئاً؛ وعندما يُختار برنامج آخر تُستبدل المعلومات والأسماء التي كان يقدّمها البرنامج. تغيّرات تفعيل WPP بما فيها حذف الطابعات الافتراضية آلية أخرى (الفصل 4).

2.2 في الميدان يتغيّر برنامج التشغيل أساساً في موضعين

حتّى إن لم توقف الخطّة البرامج القائمة، يتغيّر ما يراه التطبيق في الموضعين التاليين.

عندما تطابق حزمة برامج تشغيل متعدّدة الجهاز نفسه، يضع Windows لكلّ منها رتبة (rank) ويختار الأفضل. تغيير 1 تمّوز/يوليو 2026 يفضّل برنامج تشغيل فئة IPP في هذا الاختيار. على أجهزة لا يكون فيها برنامج تشغيل فئة IPP مرشّحاً، قد تبقى حزمة الصانع مختارة.³¹

flowchart TB
    accTitle: مساران يتبدّل فيهما برنامج التشغيل في الميدان
    accDescr: على أجهزة يطابقها برنامج تشغيل فئة IPP، عند استبدال الحاسوب أو إعادة تثبيت نظام التشغيل أو إعادة اكتشاف الطابعة يُختار برنامج تشغيل فئة IPP بالترتيب فيتبدّل البرنامج، وعند تفعيل Windows protected print mode تُحذف طابعات برامج التشغيل من أطراف ثالثة، فإن أمكن إعادة التسجيل بـ Windows Ready Print تبدّل البرنامج، وإن تعذّرت إعادة التسجيل اختفت وجهة الطباعة
    site["حاسوب الميدان"]
    site --> r1["استبدال الحاسوب أو إعادة تثبيت نظام التشغيل أو إعادة الاكتشاف"]
    site --> r2["تفعيل Windows protected print mode"]
    r1 --> rank["يُفضَّل على أجهزة يطابقها برنامج تشغيل فئة IPP"]
    r2 --> del["حذف طابعات برامج التشغيل من أطراف ثالثة"]
    rank --> swap["يتبدّل برنامج التشغيل"]
    del --> re{"هل يمكن إعادة التسجيل بـ Ready Print؟"}
    re -->|"نعم"| swap
    re -->|"لا"| lost["تختفي وجهة الطباعة"]

الشكل 2: إن فصلت خطّة انتهاء الخدمة عن WPP، أمكن فصل مواضع تبدّل برنامج التشغيل عن مواضع فقدان وجهة الطباعة نفسها.

هنا مهمّ أيضاً ألّا تعامل توافق IPP واعتماد Mopria شرطاً واحداً.

على أجهزة تدعم IPP دون اعتماد Mopria، حتّى دون استخدام WPP قد يتبدّل برنامج التشغيل بتغيّر الترتيب. وبالعكس، اسم البرنامج «Microsoft IPP Class Driver» وحده لا يثبت أنّ الجهاز صالح لـ WPP.¹⁴

flowchart TB
    accTitle: مطابقة برنامج تشغيل فئة IPP واعتماد Mopria شرطان منفصلان
    accDescr: إن دعمت الطابعة IPP فقد يُختار برنامج تشغيل فئة IPP بتغيّر الترتيب فيتبدّل البرنامج، بينما اعتماد Mopria شرط منفصل يقرّر إمكان إعادة التسجيل تحت Windows protected print mode، وعلى أجهزة الشبكة يلزم أن يكون IPP مفعّلاً وقابلاً للوصول، وعلى USB وضع IPP over USB
    printer["طابعة"]
    printer --> q1{"هل تدعم IPP؟"}
    q1 -->|"نعم"| rank["قد يتبدّل"]
    q1 -->|"لا"| keep["تبقى من الصانع"]
    printer --> q2{"هل هي معتمدة من Mopria؟"}
    q2 -->|"لا"| ng["لا يمكن إعادة التسجيل أمام WPP"]
    q2 -->|"نعم"| q3{"هل الاتصال USB؟"}
    q3 -->|"لا"| q5{"هل IPP مفعّل ويصل؟"}
    q5 -->|"نعم"| ok["يمكن إعادة التسجيل أمام WPP"]
    q5 -->|"لا"| ng
    q3 -->|"نعم"| q4{"هل وضع IPP over USB؟"}
    q4 -->|"نعم"| ok
    q4 -->|"لا"| ng

الشكل 3: أثر الترتيب يقرّره دعم IPP، والبقاء أمام WPP يقرّره اعتماد Mopria مع كون IPP مفعّلاً وقابلاً للوصول (وعلى USB وضع IPP over USB).

2.3 لتوقيع برنامج التشغيل استثناءات، لكن الاستمرار غير مضمون

بعد 15 كانون الثاني/يناير 2026 يمكن رفع طلب استثناء توقيع للمراجعة الفردية إن انطبق أحد الشروط التالية.¹

• موجَّه لطابعة لا يمكنها الحصول على اعتماد Mopria.
• حزمة حدّ نظام التشغيل المستهدف فيها Windows 10 فما دونه.
• برنامج تشغيل ARM64 أصلي.

يُحظر التقديم افتراضيّاً سواء كان WHQL أم Attestation، ويصير مراجعة يدوية بمستند تبرير. حتّى إن انطبق الشرط، لا يُضمن أن يقدّم الصانع أو أن توافق Microsoft.⁵ كذلك إمكان الحصول على برنامج موقَّع وإمكان استخدامه في بيئة فُعِّل فيها WPP أمران منفصلان. استعداد طابعات الملصقات والإيصالات في الفصل 6.

flowchart TB
    accTitle: شروط يُقبل فيها توقيع برنامج التشغيل بعد 15 كانون الثاني/يناير 2026
    accDescr: تقديم الصانع لبرنامج التشغيل محظور افتراضيّاً، ولا يُرفع طلب الاستثناء إلى المراجعة الفردية إلّا إن انطبق أحد شروط ثلاثة: طابعة بلا اعتماد Mopria، أو حزمة حدّها Windows 10 فما دونه، أو برنامج تشغيل ARM64 أصلي، والمراجعة قد توافق دون ضمان التوقيع
    submit["تقديم الصانع لبرنامج التشغيل"]
    submit --> block["محظور افتراضيّاً"]
    block --> c1["طراز بلا اعتماد Mopria"]
    block --> c2["الحدّ Windows 10 فما دونه"]
    block --> c3["ARM64 أصلي"]
    c1 --> apply["يمكن طلب استثناء"]
    c2 --> apply
    c3 --> apply
    apply --> review["مراجعة فردية"]
    review --> maybe["قد تُوافَق (بلا ضمان)"]

الشكل 4: انطباق الشرط يضع الطلب في المراجعة فقط، ولا يضمن التوقيع.

3. الآلية ── مسار برنامج التشغيل التقليدي وWindows Ready Print

3.1 ما يتغيّر هو مسار الطباعة بعد واجهة الرسم

في طباعة Windows التقليدية يصدر التطبيق أوامر رسم GDI أو XPS، ويستقبل المُبَوِّب المهمة، ويحوّلها برنامج تشغيل الطابعة إلى لغة الطابعة (PDL) ويرسلها. مسار طباعة GDI ومسار طباعة XPS كلاهما على هذا البناء.⁶

flowchart TB
    accTitle: مسار برنامج التشغيل التقليدي
    accDescr: يبوّب المُبَوِّب بصلاحيات SYSTEM أوامر رسم GDI أو XPS من تطبيق الأعمال، ويحوّلها برنامج تشغيل v3 أو v4 من طرف ثالث إلى PDL خاصّ، داخل عملية المُبَوِّب إن لم يكن هناك عزل، أو في عملية منفصلة إن كان العزل مشتركاً أو معزولاً، ثمّ يرسلها إلى الطابعة
    app["تطبيق الأعمال (GDI / XPS)"] --> spooler["المُبَوِّب (صلاحيات SYSTEM)"]
    spooler --> iso{"عزل برنامج التشغيل هو"}
    iso -->|"لا شيء"| inproc["برنامج تشغيل طرف ثالث داخل المُبَوِّب"]
    iso -->|"مشترك / معزول"| host["برنامج تشغيل طرف ثالث في عملية أخرى"]
    inproc --> pdl["تحويل إلى PDL خاصّ"]
    host --> pdl
    pdl --> printer["الطابعة"]

الشكل 5: في المسار التقليدي تتغيّر العملية بوجود العزل أو عدمه، لكن البنية التي يتحمّل فيها رمز طرف ثالث التحويل إلى PDL داخل مكدّس الطباعة واحدة.

الخلف المعدّ هو Windows Ready Print. اسم يجمع الطباعة بـ IPP (Internet Printing Protocol) والمسح بـ eSCL وUniversal Print، ولا يحتاج برنامج تشغيل من طرف ثالث. صُمِّم لطابعات معتمدة من Mopria، ومن مزاياه أنّه لا يعتمد على معمارية CPU.⁷

من Windows 10 21H2 فما بعده يُضمَّن Microsoft IPP Class Driver للتعامل مع طابعات متوافقة مع Mopria عبر الشبكة وUSB.¹ طابور سحابة Universal Print يستخدم Universal Print Class Driver المضمَّن.⁸

flowchart TB
    accTitle: مسار Windows Ready Print
    accDescr: يستقبل المُبَوِّب أوامر رسم تطبيق الأعمال، ويرسم Microsoft IPP Class Driver المضمَّن على العميل إلى PWG Raster أو PDF ويرسلها بـ IPP إلى طابعة معتمدة من Mopria، أو يرسل Universal Print Class Driver المضمَّن بـ IPP over HTTPS إلى خدمة Universal Print، ولا يسمح Windows protected print mode إلّا بمسار Windows Ready Print هذا
    app["تطبيق الأعمال (GDI / XPS)"] --> spooler["المُبَوِّب"]
    spooler --> ipp["Microsoft IPP Class Driver"]
    ipp --> render["الرسم إلى PWG Raster / PDF"]
    render --> printer["طابعة معتمدة من Mopria (IPP)"]
    spooler --> up["Universal Print Class Driver"]
    up --> cloud["خدمة Universal Print (IPP over HTTPS)"]
    wpp["Windows protected print mode"] -.->|"لا يسمح إلّا بمسار Ready Print"| ipp
    wpp -.-> up

الشكل 6: Windows Ready Print أيضاً يمرّ بالمُبَوِّب. ما يتغيّر أنّ التحويل والإرسال ينتقلان من برنامج تشغيل طرف ثالث إلى برنامج تشغيل فئة مضمَّن.

IPP بروتوكول قائم على HTTP، ويعرّف الطابعة بـ URI مثل ipps://printer.example.com/ipp/print. أشكال PDL المستخدمة في الطباعة بلا برنامج تشغيل قليلة تستند إلى معايير علنية مثل PWG Raster وPDF، ويُرسم المستند النهائي على جهة العميل.⁹ في Universal Print يرسل المُبَوِّب المهمة إلى الخدمة بـ IPP over HTTPS.⁸

المدخل من جهة التطبيق لا يتغيّر. التطبيق الذي يرسم بـ GDI أو XPS يستدعي الواجهة نفسها. ما يتغيّر هو الآلية التي تعيد بعدها قائمة الورق والصواني، وتقدّم وظائف خاصّة، وتحوّل إلى PDL. لذلك يتأثّر التطبيق الذي يعتمد على معلومات برنامج التشغيل وإعداداته الخاصّة أكثر من تطبيق الرسم فقط. لوظائف الصانع الخاصّة تأكّد أيضاً من التوفير عبر Print Support App (PSA).¹⁰

3.2 في الجهاز متعدّد الوظائف أكّد الطباعة والفاكس والمسح كلّاً على حدة

إمكان الانتقال إلى Windows Ready Print يفترض أن الجهاز يحمل الوظيفة وينفّذ البروتوكول المقابل.¹

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

flowchart TB
    accTitle: ترتيب تأكيد وظائف الجهاز متعدّد الوظائف كلّاً على حدة
    accDescr: اختر الوظائف المستخدمة واحدة فواحدة، وأكّد الحمل على الجهاز ثمّ بروتوكول الجدول ثمّ وضع IPP over USB عند الاتصال بـ USB، ولا تُعد استخدام نتيجة وظيفة الطباعة للفاكس أو المسح، وأكّد الوظائف الباقية كلّاً على حدة
    start["اختر وظيفة مستخدمة واحدة"]
    start --> feature{"هل يحمل الجهاز هذه الوظيفة؟"}
    feature -->|"نعم"| protocol{"هل يدعم بروتوكول الجدول؟"}
    feature -->|"لا"| unmet["شرط هذه الوظيفة غير مستوفًى"]
    protocol -->|"نعم"| usb{"هل الاتصال USB؟"}
    protocol -->|"لا"| unmet
    usb -->|"نعم"| mode{"هل وضع IPP over USB؟"}
    usb -->|"لا"| checked["أُكِّدت شروط هذه الوظيفة"]
    mode -->|"نعم"| checked
    mode -->|"لا"| unmet
    checked --> next["أكّد الوظائف الباقية كلّاً على حدة"]
    unmet --> next

الشكل 7: أكّد بهذا الترتيب الحمل ثمّ البروتوكول ثمّ الشرط الإضافي عند الاتصال. لا تُعد استخدام نتيجة تأكيد الطباعة للفاكس أو المسح.

3.3 في الخلفية أمن مكدّس الطباعة

في شرح Microsoft Learn تشكّل أعطال الطباعة 9% من حالات تقارير MSRC (Microsoft Security Response Center) التي جمعتها تلك الشروح على السنوات الثلاث الماضية. يعمل المُبَوِّب بصلاحيات SYSTEM، ويصل إليه المستخدمون العاديون على نطاق واسع، ويحمّل رمز أطراف ثالثة عند الطلب. بعض البرامج القديمة غير متوافق مع تخفيفات حديثة مثل CFG وCET، فيصعب تطبيق تخفيف يحتاج توافق كلّ الرمز المشارك.⁹

flowchart TB
    accTitle: لماذا لا تنفع التخفيفات ما دام برنامج تشغيل طرف ثالث يُحمَّل
    accDescr: يحمّل المُبَوِّب بصلاحيات SYSTEM رمزاً من طرف ثالث، والبرامج القديمة غير متوافقة مع تخفيفات مثل CFG وCET، فلا يمكن تطبيق تخفيف يحتاج توافق كلّ المشاركين على المُبَوِّب، فيسهل استغلال الثغرات
    sys["المُبَوِّب بصلاحيات SYSTEM"]
    load["يحمّل رمز طرف ثالث عند الطلب"]
    old["البرامج القديمة غير متوافقة مع التخفيفات"]
    sys --> risk["يسهل استغلال الثغرات"]
    load --> nomit["لا يمكن تطبيق التخفيفات (CFG / CET / ACG)"]
    old --> nomit
    nomit --> risk

الشكل 8: التخفيف لا ينفع إلّا عندما يتوافق كلّ المشاركين، فلا تُحمى المُبَوِّب ما لم تُخرَج برامج التشغيل.

موضع تشغيل برنامج تشغيل الطرف الثالث يتغيّر بإعداد عزل برنامج تشغيل الطابعة.¹¹

البرنامج الذي يعلن DriverIsolation=2 في INF يستخدم افتراضيّاً عملية مشتركة، والذي لا يعلن يعمل افتراضيّاً داخل المُبَوِّب. يمكن للمسؤول التجاوز من وحدة تحكّم إدارة الطباعة أو Group Policy. لكن في أيّ وضع يبقى رمز طرف ثالث يعمل داخل مكدّس الطباعة.¹¹ WPP وضع تشغيل يُخرج هذه التبعية لرمز الطرف الثالث.

flowchart TB
    accTitle: كيف تُقرَّر العملية التي يعمل فيها برنامج تشغيل طرف ثالث
    accDescr: البرنامج الذي يعلن DriverIsolation=2 في INF يعمل افتراضيّاً في عملية مشتركة منفصلة عن المُبَوِّب، والذي بلا إعلان يعمل افتراضيّاً داخل المُبَوِّب، ويمكن للمسؤول التجاوز من وحدة التحكّم أو السياسة إلى مشترك أو داخل المُبَوِّب أو عملية مخصّصة (عزل)
    inf{"إعلان DriverIsolation=2 في INF"}
    inf -->|"نعم"| shared["يعمل في عملية مشتركة أخرى (افتراضي)"]
    inf -->|"لا"| inproc["يعمل داخل المُبَوِّب (افتراضي)"]
    admin["تجاوز بإعداد المسؤول أو السياسة"] -.-> shared
    admin -.-> inproc
    admin -.-> isolated["يعمل في عملية مخصّصة (عزل)"]

الشكل 9: وضع العزل يقرّره إعلان INF وإعداد المسؤول، والبرامج القديمة بلا إعلان تعمل افتراضيّاً داخل المُبَوِّب.

4. ماذا يختفي في Windows protected print mode

4.1 WPP وضع تشغيل «يستخدم Windows Ready Print فقط»

أُدخل WPP في Windows 11 24H2. في وقت كتابة هذه المقالة معطّل افتراضيّاً، وما دام معطّلاً فلا قيد على تثبيت برامج التشغيل ولا على وظائف الطباعة.¹²¹³ نفصل طريقة التفعيل عمّن يمكنه الإرجاع.

إن فُعِّل بـ Group Policy لا يستطيع المستخدم الإلغاء دون الاتصال بالمسؤول. OMA-URI في Intune مسار يطبّق سياسة جهاز قائمة على ADMX نفسها. ما يمكن للشخص إرجاعه من شاشة الإعدادات هو ما فعّله هو من شاشة الإعدادات.¹⁴²¹³

flowchart TB
    accTitle: ثلاثة مسارات لتفعيل Windows protected print mode
    accDescr: يمكن تفعيل Windows protected print mode من تطبيق الإعدادات أو Group Policy أو OMA-URI في Intune، ولا يستطيع الشخص الإرجاع من تطبيق الإعدادات إلّا إن فعّله هو من تطبيق الإعدادات، وإن وُزِّعت السياسة بـ Group Policy أو Intune لا يُلغى دون تغيير السياسة من جهة المسؤول
    s["تطبيق الإعدادات (يفعّله الشخص)"] --> wpp["تفعيل Windows protected print mode"]
    g["Group Policy"] --> wpp
    i["Intune (OMA-URI)"] --> wpp
    s -.->|"يمكن للشخص الإرجاع من تطبيق الإعدادات"| off["إلغاء"]
    g -.->|"لا يستطيع الشخص الإرجاع"| adm["الإلغاء تغيير سياسة من جهة المسؤول"]
    i -.->|"لا يستطيع الشخص الإرجاع"| adm

الشكل 10: مسارات التفعيل ثلاثة، ولا يستطيع الشخص الإرجاع إلّا إن فعّله هو من تطبيق الإعدادات.

4.2 طوابير تبقى، وطوابير تختفي، وطوابير تحتاج إعادة تسجيل

أثر التفعيل لا يتغيّر بجسم الطابعة وحده، بل أيضاً بـ برنامج التشغيل الذي سُجِّلت به الآن.²

flowchart TB
    accTitle: ما يحدث للطابعات عند تفعيل Windows protected print mode
    accDescr: عند التفعيل تُحذف الطابعات المثبَّتة ببرنامج تشغيل طرف ثالث والطابعات الافتراضية غير المدعومة وXPS Document Writer وطابعة الفاكس الافتراضية، والطراز المعتمد من Mopria والذي على الشبكة يكون IPP فيه مفعّلاً وقابلاً للوصول وعلى USB في وضع IPP over USB يمكن إعادة تسجيله بـ Windows Ready Print، وغير المتوافق لا يُستخدم ما دام الوضع مفعّلاً
    on["تفعيل WPP"]
    on --> third["حذف طابعات برامج التشغيل من أطراف ثالثة"]
    on --> soft["حذف الطابعات الافتراضية غير المتوافقة"]
    soft --> xps["حذف XPS Document Writer والفاكس أيضاً"]
    third --> mopria{"هل هي معتمدة من Mopria؟"}
    mopria -->|"نعم"| conn{"الاتصال هو"}
    conn -->|"شبكة"| ipp{"هل IPP مفعّل ويصل؟"}
    conn -->|"USB"| usb{"هل وضع IPP over USB؟"}
    ipp -->|"نعم"| re["إعادة التسجيل بـ Windows Ready Print"]
    usb -->|"نعم"| re
    ipp -->|"لا"| no["لا تُستخدم ما دام مفعّلاً"]
    usb -->|"لا"| no
    mopria -->|"لا"| no

الشكل 11: طابور برنامج تشغيل الصانع يختفي مرّة حتّى مع اعتماد Mopria. أكّد شروط إعادة التسجيل على حدة.

ما دام WPP مفعّلاً لا تُستخدم برامج التشغيل المحذوفة من أطراف ثالثة. وإرجاع WPP إلى التعطيل لا يعيد تلقائيّاً الطابعة التي أُعيد إدخالها بـ Windows Ready Print إلى برنامج التشغيل الأصلي.²¹⁰

من جهة التطبيق، هدف التأكيد المعالجة التي تفترض الورق والصواني والوظائف الخاصّة التي يعيدها برنامج تشغيل الصانع، والطابعة الافتراضية من نوع DLL مراقب المنافذ، وXPS Document Writer. توليد ملفّ XPS مباشرة بـ XpsDocument ونحوه ليس طباعة إلى الطابور الافتراضي XPS Document Writer، وليس هدف هذا الحذف.

4.3 تغييرات أيضاً في الإدارة وداخل المُبَوِّب

تحت WPP لا تُحمَّل ثنائيات أطراف ثالثة مثل DLL مراقب المنافذ. واجهات تحميل الوحدات مثل AddPrintProvidorW لا تحمّل وحدات جديدة، ولا يُحمَّل إلّا الثنائيات الموقَّعة من Microsoft اللازمة لـ IPP. AddPrintProvidorW الإملاء التاريخي في winspool.h، وفي شروح Microsoft Learn يُكتب AddPrintProviderW.⁹

بهذا القيد يعمل رسم XPS بصلاحيات المستخدم لا SYSTEM، وتستخدم عملية عامل المُبَوِّب الجديدة رمزاً مقيَّداً أُزيلت منه امتيازات مثل SeTcbPrivilege. يُحظر إنشاء عمليات ابنة، وتُفعَّل CFG وCET وACG أيضاً.⁹

flowchart TB
    accTitle: تغيّر المُبَوِّب في Windows protected print mode
    accDescr: بعدم تحميل ثنائيات أطراف ثالثة يصير ممكناً تقييد تحميل الوحدات، ورسم XPS بصلاحيات المستخدم، وعملية عامل برمز مقيَّد، وحظر إنشاء عمليات ابنة، وتفعيل CFG وCET وACG
    nodrv["عدم تحميل ثنائيات أطراف ثالثة"]
    nodrv --> r["تقييد التحميل"]
    nodrv --> l["تقليص الصلاحيات"]
    nodrv --> m["تفعيل التخفيفات"]
    r --> r2["الثنائيات الموقَّعة من Microsoft فقط"]
    l --> l2["XPS بصلاحيات المستخدم ورمز مقيَّد"]
    m --> m2["حظر العمليات الابنة وCFG / CET / ACG"]

الشكل 12: التخفيفات التي لم تنفع في الشكل 8 لا تُفعَّل إلّا بإخراج ثنائيات الأطراف الثالثة.

Point and Print يُبقي تكوين IPP لكنّه لا يعود يثبّت برامج تشغيل من أطراف ثالثة. إجراءات التجهيز التي تفترض «الاتصال بخادم الطباعة فيُوزَّع برنامج التشغيل» تحتاج مراجعة أيضاً.⁹

هل WPP مفعّل الآن يمكن تأكيده بواجهة WinRT على Windows 11 24H2 فما بعده: Windows.Graphics.Printing.ProtectedPrint.WindowsProtectedPrintInfo.IsProtectedPrintEnabled.¹⁵ قيمة إعداد Group Policy هي WindowsProtectedPrintGroupPolicyState تحت HKLM\Software\Policies\Microsoft\Windows NT\Printers\WPP.¹³

من عميل فُعِّل فيه WPP لا يمكن إدارة خادم طباعة WPP فيه معطّل من إدارة الطباعة. هيّئ لمسؤولي الإدارة عميلاً إداريّاً منفصلاً معطّل فيه WPP.¹⁴

5. جرد التطبيق القائم ── أربعة مواضع تُرى

flowchart TB
    accTitle: أربعة مواضع تُجرد في تطبيق الأعمال
    accDescr: من شيفرة طباعة تطبيق الأعمال، حفظ الإعدادات الخاصّة ببرنامج التشغيل، وتبعية اسم الطابور (بما في داخل SDK والمكتبات)، والتبعية لطابعة افتراضية غير مدعومة أمام WPP، وإرسال RAW إلى طابور لا يصمد أمام WPP أربعة مواضع هدف إصلاح، والشيفرة التي ترسم فقط هدف تحقّق
    app["شيفرة طباعة تطبيق الأعمال"]
    app --> deps["جرد أربع تبعيات"]
    app --> d0["رسم فقط"]
    deps --> d1["حفظ إعدادات خاصّة"]
    deps --> d2["تبعية اسم الطابور"]
    deps --> d3["تبعية طابعة افتراضية"]
    deps --> d4["إرسال RAW"]
    d2 -.-> d2n["يشمل داخل SDK"]
    d3 -.-> d3n["غير المتوافق مع WPP"]
    d4 -.-> d4n["موجَّه لطابور لا يبقى"]
    d1 --> fix["أصلح"]
    d2 --> fix
    d3 --> fix
    d4 --> fix
    d0 --> verify["تحقّق"]

الشكل 13: التبعيات الأربع وحدها هدف إصلاح، والشيفرة التي لا تفعل سوى الرسم تُحال إلى التحقّق.

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

حاجة الإصلاح تُقرَّر بعد رؤية ما هو مثبَّت في الميدان. خذ قائمة الطوابير وبرامج التشغيل بوحدة PrintManagement في PowerShell. أخذ القائمة بـ Get-Printer وGet-PrinterDriver لا يحتاج صلاحيات مسؤول، أمّا pnputil في النصف الثاني فيحتاجها.¹⁶¹⁷

# لكلّ طابور، صفّ اسم برنامج التشغيل والإصدار الرئيس (3 = v3, 4 = v4) والجهة المقدِّمة واسم ملفّ INF
Get-Printer |
    Select-Object Name, DriverName, PortName,
        @{ Name = "DriverMajorVersion"; Expression = { (Get-PrinterDriver -Name $_.DriverName).MajorVersion } },
        @{ Name = "Manufacturer"; Expression = { (Get-PrinterDriver -Name $_.DriverName).Manufacturer } },
        @{ Name = "InfName"; Expression = { Split-Path -Leaf (Get-PrinterDriver -Name $_.DriverName).InfPath } } |
    Sort-Object DriverName |
    Format-Table -AutoSize

# عدّد حزم برامج التشغيل من أطراف ثالثة فقط مع الاسم المنشور (oemN.inf) واسم INF الأصلي والجهة المقدِّمة (يلزم صلاحيات مسؤول)
pnputil /enum-drivers /class Printer

يميّز MajorVersion بين v3 وv4.¹⁸ لكن تمييز v3/v4 وتمييز المضمَّن / من طرف ثالث أمران منفصلان. صنّف كما يلي.

InfPath في Get-PrinterDriver مسار إلى INF داخل مخزن برامج التشغيل، ولا يضمن إعادة الاسم المنشور oemN.inf. طابق الاسم المنشور واسم INF الأصلي والجهة المقدِّمة التي يعيدها pnputil /enum-drivers باسم ملفّ InfPath وManufacturer. يعدّد pnputil /enum-drivers حزم الأطراف الثالثة فقط، ولا تظهر الحزم المضمَّنة في القائمة.¹⁹¹⁷

flowchart TB
    accTitle: إجراء جرد قائمة طابعات الميدان
    accDescr: خذ قائمة الطوابير وبرامج التشغيل بـ PowerShell، وقسّم بـ DriverName وبمطابقة Manufacturer وقائمة حزم الأطراف الثالثة من pnputil إلى طابور برنامج تشغيل فئة IPP وطابور Universal Print (متوافق مع WPP) وطابور برنامج تشغيل مضمَّن آخر (XPS والفاكس يُحذفان، وGeneric / Text Only لا يُفترض بقاؤهما، وMicrosoft Print to PDF غير مذكور ضمن أهداف الحذف فاحكم فرديّاً) وطابور برنامج تشغيل الصانع (مرشّح للتبدّل)، وطابور برنامج تشغيل فئة IPP يؤكَّد فيه على حدة اعتماد Mopria وعلى الشبكة أن IPP مفعّل ويصل وعلى USB وضع IPP over USB، ثمّ طابق كلا الطابورين بالطابور الذي تشير إليه إعدادات التطبيق أو شيفرة الطباعة واحكم
    list["خذ القائمة بـ Get-Printer / Get-PrinterDriver"]
    list --> cls{"DriverName والجهة المقدِّمة هما"}
    cls -->|"IPP Class"| ipp["طابور برنامج تشغيل فئة IPP"]
    cls -->|"Universal Print Class"| up["طابور Universal Print"]
    cls -->|"مضمَّن آخر"| inbox["احكم فرديّاً بجدول الفصل 4 هل يبقى"]
    cls -->|"من الصانع"| vendor["مرشّح للتبدّل"]
    ipp --> mop["أكّد Mopria ووصول IPP وUSB"]
    mop --> match["طابق إعدادات التطبيق والشيفرة"]
    up --> match
    inbox --> match
    vendor --> match
    match --> judge["وزّع بجدول القرار"]

الشكل 14: أخذ القائمة والتقسيم بالاسم يتمّان بلا صلاحيات مسؤول، ومطابقة الجهة المقدِّمة تحتاج صلاحيات مسؤول لـ pnputil.

طابق هذه القائمة بالطوابير التي تشير إليها إعدادات التطبيق وشيفرة الطباعة وSDK المستخدم. إن سجّلت لكلّ جهة تسليم برنامج التشغيل واعتماد Mopria وطريقة الاتصال ووصول IPP ووضع تشغيل USB، أمكن الحكم بجدول الفصل 4.

إن لم تبقَ وجهة الطباعة أمام WPP وتعذّرت إعادة التسجيل، فقبل جرد الشيفرة أعدّ المسار البديل في الفصل 6 أو قرّر عدم استخدام WPP. إن كان الجهاز قد يتلقّى تغيّر ترتيب IPP حتّى دون استخدام WPP، فتابع التأكيد من 5.2 فما بعده. إن لم تستخدم WPP ولم يكن لأثر تبدّل برنامج التشغيل موضع، صار الحكم الإبقاء على المسار الحالي.

للتأكيد على اسم برنامج التشغيل من داخل التطبيق يمكن قراءة PrintQueue.QueueDriver.Name بـ System.Printing في WPF.²⁰

using System.Printing;

// من أداة إدارة أو تطبيق سطح مكتب، عدّد اسم برنامج تشغيل كلّ طابور
using var server = new LocalPrintServer();
foreach (PrintQueue queue in server.GetPrintQueues(
    new[] { EnumeratedPrintQueueTypes.Local, EnumeratedPrintQueueTypes.Connections }))
{
    Console.WriteLine($"{queue.Name}\t{queue.QueueDriver?.Name}\t{queue.QueuePort?.Name}");
}

لكن فضاء الأسماء System.Printing غير مدعوم داخل خدمات Windows. إن كانت الطباعة من خدمة مقيمة، ضع معالجة التشخيص هذه في جهة أداة الإدارة.²¹ قيود الطباعة من خدمة في كيفية بناء خدمات Windows وتشغيلها والفصل 7 من المقالة السابقة.

5.2 التأكيد 1: هل تُحفظ إعدادات خاصّة ببرنامج التشغيل وتُعاد؟

أصعب ما يُوجد حفظ إعدادات الطباعة. سبب الكسر يختلف بطريقة الحفظ.

يمكن لـ DEVMODE أن يحمل بعد الأعضاء العامّة بيانات غير عامّة يبيّن حجمها dmDriverExtra. ما يتحقّق منه Windows هو الجزء العام فقط، والبيانات غير العامّة التالفة قد تُسقط برنامج التشغيل في عملية التطبيق أو المُبَوِّب.²²

flowchart TB
    accTitle: الجزء العام والجزء غير العام من DEVMODE
    accDescr: بنية DEVMODE تحمل بعد الأعضاء العامّة بيانات غير عامّة يعرّفها برنامج التشغيل ويبيّنها dmDriverExtra، والجزء العام وحده يتحقّق منه Windows، والجزء غير العام لا يفسّره إلّا ذلك البرنامج، فحفظ الجملة يفقد المعنى عند تبدّل البرنامج
    dm["بنية DEVMODE"]
    dm --> pub["الجزء العام (dmSize)"]
    dm --> priv["الجزء غير العام (dmDriverExtra)"]
    pub --> chk["يتحقّق منه Windows"]
    priv --> only["لا يفسّره إلّا ذلك البرنامج"]
    only --> lost["يفقد المعنى عند تبدّل البرنامج"]

الشكل 15: ممّا يُحفظ جملة، ما ينكسر هو الجزء غير العام.

PrinterSettings الذي استقبل الإعداد بـ SetHdevmode ينسخ هذا الحيّز غير العام داخليّاً.²³ لنسخة .NET Framework من PrinterSettings سمة Serializable، والتسلسل الثنائي يشمل افتراضيّاً الحقول الخاصّة أيضاً، فالحفظ الكامل للكائن يخفي التبعية نفسها.²⁴²⁵

أمّا نسخة .NET من PrinterSettings فلا سمة Serializable لها، والتنفيذ الذي يحفظ الخصائص العامّة فرادى بصيغة خاصّة لا يحفظ مخزن DEVMODE الأصلي ولا حيّز dmDriverExtra.²⁴ ما تنتبه إليه هنا قيم تعتمد على برنامج التشغيل.

flowchart TB
    accTitle: حفظ DEVMODE وحفظ القيم المُدارة ينكسران على نحو مختلف
    accDescr: التنفيذ الذي يحفظ مخزن DEVMODE جملة والذي يسلسل PrinterSettings جملة بعد استقبال الحيّز غير العام بـ SetHdevmode يحملان الجزء غير العام فيفقدان المعنى عند تبدّل البرنامج، والتنفيذ الذي يحفظ قيم الخصائص العامّة يحمل أرقام ورق وصوانٍ Custom أو خاصّة بالصانع مقابل قائمة برنامج تشغيل الصانع فلا ضمان أن تحمل المعنى نفسه في برنامج تشغيل فئة IPP، وكلاهما يُستبدل بتصميم يحفظ المقصد فقط
    a["حفظ DEVMODE جملة"]
    a --> a1["يحمل الجزء غير العام معه"]
    s["الحفظ جملة بعد SetHdevmode"] --> a1
    a1 --> a2["يفقد المعنى عند تبدّل البرنامج"]
    b["حفظ قيم الخصائص العامّة"]
    b --> b1["يحمل أرقام ورق وصوانٍ مخصّصة"]
    b1 --> b2["لا ضمان للمعنى نفسه في البرنامج الجديد"]
    a2 --> c["كلاهما إلى حفظ المقصد فقط"]
    b2 --> c

الشكل 16: الحفظ الكامل للكائن بعد SetHdevmode يدخل جانب الجزء غير العام، وطريقة الكسر تختلف لكن كليهما يحمل حالة برنامج التشغيل.

إن مثّل RawKind قيمة PaperKind أو PaperSourceKind قياسية، بقي المعنى بعد تبدّل البرنامج. ما لا يُضمن أن تشير أرقام Custom أو أرقام الصانع إلى الورق والصينية نفسها في برنامج تشغيل آخر. لا تعامل القيم القياسية كأنّها تنكسر جملة.²⁶²⁷

flowchart TB
    accTitle: ممّا يُحفظ من قيم الورق والصواني ما ينكسر
    accDescr: من RawKind القيم المقابلة لورق قياسي مثل A4 (PaperKind) أو مصدر تغذية قياسي مثل Upper وLower (PaperSourceKind) تحفظ المعنى بعد تبدّل البرنامج، وقيم Custom أو الخاصّة بالصانع أرقام مقابل قائمة برنامج تشغيل الصانع فلا ضمان أن يفسّرها برنامج تشغيل فئة IPP الورق والصينية نفسها
    raw["RawKind المحفوظ"]
    raw --> std["قيمة قياسية (PaperKind ونحوه)"]
    raw --> cus["قيمة Custom أو خاصّة بالصانع"]
    std --> keep["يحفظ المعنى بعد تبدّل البرنامج"]
    cus --> lost["لا ضمان تفسير الورق والصينية نفسها"]

الشكل 17: ما ينكسر ليس القيمة القياسية بل القيمة المخصّصة مقابل قائمة برنامج تشغيل الصانع.

في PrintTicket أيضاً تُعرَّف الكلمات المفتاحية العامّة في فضاء أسماء psk، لكن يمكن تضمين امتدادات خاصّة بالجهاز. عناصر الطرف الثالث توضع بحكم في فضاء أسماء مرتبط بوضوح بذلك الطرف. إن اختلط فضاء أسماء الصانع في XML المحفوظ فأكّده إعداداً خاصّاً ببرنامج التشغيل.²⁸²⁹

المعالجة: احفظ «المقصد» فقط

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

في WPF اجلب القدرات بـ PrintQueue.GetPrintCapabilities واجعل الطلب PrintTicket ومرّره إلى MergeAndValidatePrintTicket.³⁰ ما تنتبه إليه هنا أن الطلب غير المدعوم لا يصير خطأ بالضرورة. قد يحلّ برنامج التشغيل التعارض ويعيد عادة تذكرة صالحة استُبدلت بقيم افتراضية ونحوها.

إن كان ValidationResult.ConflictStatus هو ConflictResolved فقارن الوجهين والصينية في ValidatedPrintTicket بالطلب، وابقِ الفرق في السجلّ وأعلم المستخدم.³¹

flowchart TB
    accTitle: تصميم يحفظ المقصد فقط ويطابقه بالقدرات قبيل الطباعة
    accDescr: يحمل ملفّ الإعدادات مقصد الورق والاتجاه والوجهين وعدد النسخ والصينية فقط بكلمات مفتاحية عامّة، وقبيل الطباعة تُجلب قدرات الطابعة الحالية بـ GetPrintCapabilities وتُمرَّر إلى MergeAndValidatePrintTicket، فإن كان ConflictStatus هو NoConflict طُبع كما هو، وإن كان ConflictResolved قورنت العناصر المستبدلة بالطلب وأُحيلت إلى السجلّ والإشعار
    cfg["ملفّ الإعدادات: المقصد فقط (ورق واتجاه ووجهان وعدد نسخ)"]
    cfg --> caps["GetPrintCapabilities قبيل الطباعة"]
    caps --> merge["MergeAndValidatePrintTicket"]
    merge --> st{"ConflictStatus هو"}
    st -->|"NoConflict"| print["طباعة"]
    st -->|"ConflictResolved"| tell["فرق الطلب إلى السجلّ والإشعار"]

الشكل 18: احفظ مقصد الإعداد وتحقّق منه بقدرات الوقت الحالي عند الطباعة. لا تستخدم الإعداد المستبدل صامتاً؛ أكّد الفرق.

في WinForms اختر الورق من PrinterSettings.PaperSizes بـ Kind أو الأبعاد لا بالاسم. مصدر التغذية PaperSources يمكن إعادة استخدام قيم قياسية فريدة مثل Upper وLower، لكن صواني خاصّة متعدّدة قد تُعاد جملة بوصفها PaperSourceKind.Custom. وليس لـ PaperSource أبعاد ورق. لا تحدّد صينية خاصّة بـ Kind وحده؛ أعد التعيين صراحة إلى القدرات الحالية أو اطلب من المستخدم الاختيار من جديد.²⁷

5.3 التأكيد 2: هل هناك تبعية لاسم الطابعة أو اسم الطابور؟

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

مواضع التأكيد ثلاثة: ملفّ الإعدادات، والاسم المكتوب في الشيفرة، وداخل SDK ومكتبة التقارير. حتّى إن لم يكن في شيفرتك اسم ثابت، قد يستدعي SDK الصانع داخليّاً طابوراً أو برنامج تشغيل معيّناً. طابق وثائق SDK بقائمة 5.1.

flowchart TB
    accTitle: ثلاثة مواضع تختبئ فيها تبعية اسم الطابور
    accDescr: تبعية اسم الطابور تختبئ في الاسم الثابت في ملفّ الإعدادات، والاسم الثابت المكتوب في الشيفرة، والطابور أو برنامج التشغيل الذي يستدعيه داخليّاً SDK الصانع أو مكتبة التقارير، والأوّلان يُوجدان بالبحث في الشيفرة والإعدادات، والأخير يُؤكَّد بوثائق SDK وقائمة 5.1
    dep["تبعية اسم الطابور"]
    dep --> cfg["اسم ثابت في ملفّ الإعدادات"]
    dep --> code["اسم ثابت مكتوب في الشيفرة"]
    dep --> sdk["ثابت داخل SDK أو المكتبة"]
    cfg --> grep["يُوجد بالبحث في الشيفرة والإعدادات"]
    code --> grep
    sdk --> doc["يُؤكَّد بوثائق SDK وقائمة 5.1"]

الشكل 19: حتّى إن لم يكن في شيفرتك اسم طابور، قد تبقى تبعية داخل SDK أو المكتبة.

المعالجة أن تؤكّد عند البدء أن الاسم المضبوط موجود في PrinterSettings.InstalledPrinters، فإن لم يُوجد أبقِ سجلاً وأعلم المستخدم. هيّئ أيضاً إعادة اختيار الوجهة من شاشة الإعدادات.

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

flowchart TB
    accTitle: التحقّق من اسم الطابعة عند البدء
    accDescr: عند البدء أكّد أن اسم الطابعة في ملفّ الإعدادات موجود في InstalledPrinters، فإن وُجد فاطبع، وإن لم يُوجد فأبقِ سجلاً وأعلم المستخدم ليختار من جديد، ولا تسقط صامتاً إلى الطابعة الافتراضية
    start["عند البدء: اسم الطابعة في الإعدادات"]
    start --> exists{"هل هو في InstalledPrinters؟"}
    exists -->|"نعم"| print["اطبع إلى ذلك الطابور"]
    exists -->|"لا"| log["أبقِ سجلاً وأعلم المستخدم"]
    log --> pick["أعد الاختيار من شاشة الإعدادات"]
    exists -.->|"لا تفعل هذا"| silent["سقوط صامت إلى الطابعة الافتراضية"]

الشكل 20: التنفيذ الذي يرسل صامتاً إلى طابعة أخرى عند عدم الوجود يصنع أبطأ الحوادث اكتشافاً.

5.4 التأكيد 3: هل تُستخدم طابعة افتراضية لتوليد ملفّ؟

أرشيف تقارير يطبع إلى طابعة PDF من طرف ثالث ويراقب مجلّد الإخراج، أو معالجة تصنع ملفّاً وسيطاً بـ XPS Document Writer، يتوقّف إن حُذف الطابور المستخدم أمام WPP.

لكن ما يُحذف هو الطابعة البرمجية غير المدعومة أمام WPP. لا تخلط منتجات غير متوافقة من نوع DLL مراقب المنافذ بمنتجات حُدِّثت لتتوافق مع WPP مثل OneNote. في الخطوة 3 من الفصل 7 أكّد هل الطابور المستخدم فعليّاً هدف حذف.²

إن أردت PDF فانقل، كما شرح الفصل 5 من المقالة السابقة، إلى تكوين يولّد مباشرة بمكتبة PDF، وهو تصميم أقل اعتماداً على تغيّر مكدّس الطباعة.

5.5 التأكيد 4: هل يمرّ إرسال RAW بطابور يختفي أمام WPP؟

إرسال RAW أسلوب يمرّر بيانات لغة الطابعة عبر المُبَوِّب بـ OpenPrinter ← StartDocPrinter (نوع البيانات «RAW») ← WritePrinter ← EndDocPrinter. يلزم أن يصف جانب المستند إعدادات الطباعة كاملة بلغة العتاد، ولا تُستخدم إعدادات DEVMODE.³²³³

شائع في الملصقات والإيصالات، لكن إرسال RAW ليس «اتصالاً مباشراً لا يمرّ بالمُبَوِّب». حتّى إن استخدمت برنامج التشغيل عمليّاً ممراً إلى المنفذ، إن اختفى ذلك الطابور أمام WPP فقدت الممرّ.

flowchart TB
    accTitle: مسار إرسال RAW والموضع الذي يختفي أمام WPP
    accDescr: يمرّر التطبيق بيانات لغة الطابعة إلى المُبَوِّب بـ OpenPrinter وStartDocPrinter وWritePrinter، وطابور لا يصمد أمام WPP (مثل طابور برنامج تشغيل الصانع) يكون الممرّ فيصل من المنفذ إلى الطابعة، فإن اختفى ذلك الطابور أمام WPP لم يبقَ ممرّ
    app["التطبيق: StartDocPrinter (RAW) وWritePrinter"]
    app --> spooler["المُبَوِّب"]
    spooler --> queue["طابور لا يصمد أمام WPP (ممرّ)"]
    queue --> port["المنفذ"]
    port --> printer["طابعة ملصقات أو إيصالات"]
    wpp["تفعيل WPP"] -.->|"يختفي الطابور"| queue

الشكل 21: إرسال RAW لا يستخدم برنامج التشغيل إلّا ممراً، لكن الممرّ نفسه يختفي.

ما ينبغي تأكيده هو تركيب الطابور وبرنامج التشغيل والمنفذ الذي تُرسل إليه. ليس طابور برنامج تشغيل الصانع وحده؛ برامج التشغيل المضمَّنة الموجَّهة لطابعة مادية غير برنامج تشغيل فئة IPP مثل Generic / Text Only لا تُفترض باقية. ما تأكّد اختفاؤه في قائمة الحذف في الفصل 7 يحتاج بالمثل مساراً بديلاً.¹³

كذلك لا يرد في Microsoft Learn أنّه يمكن تمرير PDL خاصّ RAW إلى طابور برنامج تشغيل فئة IPP. ذلك يعتمد على PDL الذي تقبله تنفيذ IPP في جهة الطابعة، فلا تحكم بأن «الاستبدال إلى IPP يمرّر بيانات RAW نفسها».

6. مهرب طابعات الملصقات والإيصالات

توصي كومورا سوفت بأن تحتفظ لطباعة الملصقات والإيصالات بمسار إخراج واحد على الأقل لا يعتمد على المُبَوِّب.

حتّى إن انطبق استثناء التوقيع في الفصل 2، لا يُضمن استمرار توريد برنامج تشغيل الصانع ولا الاستخدام أمام WPP.¹ في استكشاف أعطال Microsoft أيضاً حالات توقّفت فيها طابعات إيصالات وملصقات متّصلة بـ USB عن الطباعة بعد تحديث 2021 ثمّ حُلّت بـ Known Issue Rollback.³⁴ فصل مسارات الإخراج وفهمها استعداد.

لتصميم إعادة اتصال TCP يمكن استخدام أفكار مزالق تطبيقات الاتصالات التسلسلية. لاختيار أسلوب USB راجع كيفية التعامل مع أجهزة USB في تطبيقات Windows. IPP قد يكون معطّلاً افتراضيّاً حسب الطابعة ويلزم تفعيله.⁴

اسم SDK وحده لا يبيّن هل المسار مستقل. بوثائق SDK وقائمة 5.1 تأكّد هل يتواصل مباشرة مع الجهاز أم يستدعي في النهاية طابور Windows.

عند استخدام طابور Windows، Universal Print في الجانب المتوافق مع WPP لكنّه أيضاً يمرّ بالمُبَوِّب. الطابور الذي ليس برنامج تشغيل فئة IPP ولا Universal Print يتوقّف أمام WPP إن كان برنامج تشغيل طرف ثالث أو XPS أو فاكس، والطابور المضمَّن غير المذكور ضمن أهداف الحذف مثل Microsoft Print to PDF يُحكم فرديّاً. «متوافق مع WPP» و«مستقل عن المُبَوِّب» تصنيفان منفصلان.

flowchart TB
    accTitle: تدفّق الحكم هل يعتمد مسار الإخراج على المُبَوِّب
    accDescr: إن أرسل المسار المرشّح إلى طابور طباعة Windows فطابور برنامج تشغيل فئة IPP لطابعة معتمدة من Mopria وعلى الشبكة IPP مفعّل ويصل وعلى USB وضع IPP over USB وطابور Universal Print الذي هو جزء من Windows Ready Print يعتمد على المُبَوِّب لكنّه متوافق مع WPP، وطراز بلا اعتماد Mopria وطابور برنامج تشغيل طرف ثالث وطابور يُحذف بجدول الفصل 4 مثل XPS Document Writer والفاكس قد يتوقّف أمام WPP، والطابور المضمَّن غير المذكور ضمن أهداف الحذف مثل Microsoft Print to PDF يُحكم فرديّاً كما في 5.1، وإن لم يُرسل إلى طابور فإن استدعى SDK داخليّاً طابوراً أو برنامج تشغيل عاد إلى الحكم نفسه، وSDK الذي لا يستدعي ومسار الإرسال المباشر إلى الجهاز مهرب لا يعتمد على المُبَوِّب
    route["مسار الإخراج المرشّح"]
    route --> q1{"هل يرسل إلى طابور طباعة Windows؟"}
    q1 -->|"نعم"| q4{"هل هو طابور برنامج تشغيل فئة IPP؟"}
    q4 -->|"نعم"| q5{"هل هي معتمدة من Mopria؟"}
    q5 -->|"نعم"| q9{"هل يصل IPP (وعلى USB over USB)؟"}
    q9 -->|"نعم"| depok["يعتمد لكنّه متوافق مع WPP"]
    q9 -->|"لا"| dep["يعتمد وقد يتوقّف أمام WPP"]
    q5 -->|"لا"| dep
    q4 -->|"لا"| q6{"هل هو طابور Universal Print؟"}
    q6 -->|"نعم"| depok
    q6 -->|"لا"| q7{"هل يُحذف بجدول الفصل 4؟"}
    q7 -->|"نعم (طرف ثالث أو XPS أو فاكس)"| dep
    q7 -->|"لا (Print to PDF ونحوه)"| indiv["احكم فرديّاً (5.1)"]
    q1 -->|"لا"| q2{"هل عبر SDK صانع؟"}
    q2 -->|"نعم"| q3{"هل يستدعي داخليّاً طابوراً أو برنامج تشغيل؟"}
    chk["التأكيد: وثائق SDK وقائمة 5.1"] -.-> q3
    q3 -->|"نعم"| q4
    q3 -->|"لا"| indep["مهرب لا يعتمد"]
    q2 -->|"لا"| indep

الشكل 22: يُقرَّر بما يمرّ به في النهاية من طابور، وما عدا طابور برنامج تشغيل فئة IPP لطراز معتمد من Mopria وطابور Universal Print قد يتوقّف أمام WPP عدا الطابور المضمَّن غير المذكور ضمن أهداف الحذف.

7. إجراء التحقّق ── عند استخدام WPP وعند عدم استخدامه

أكّد أوّلاً تفرّع التحقّق حسب استخدام WPP أو عدمه. في الحالتين أبقِ الإخراج قبل التغيير وتأكّد على وجهة الطباعة المستخدمة فعليّاً.

flowchart TB
    accTitle: إجراء تحقّق الطباعة يُقسَم باستخدام WPP أو عدمه
    accDescr: أعد كلّ الطوابير على جهاز التحقّق واحفظ الإخراج قبل التغيير، فإن استخدمت WPP فعّله وسجّل الطوابير المحذوفة وقارن الإخراج بعد إعادة تسجيل المتوافق وأكّد المسار البديل لغير المتوافق، وإن لم تستخدمه فأعد اكتشاف الجهاز المادي هدف تغيّر ترتيب IPP مع إبقاء التعطيل وقارن الإخراج، وما سواه أكّد الطباعة على الطابور الفعلي
    prepare["أعد كلّ الطوابير وسجّل"]
    prepare --> baseline["احفظ نتيجة الطباعة قبل التغيير"]
    baseline --> use{"هل تستخدم WPP؟"}
    use -->|"نعم"| enable["فعّل وسجّل طوابير الحذف"]
    enable --> compatible["المتوافق أعد تسجيله إن لزم"]
    compatible --> compare["قارن بالطباعة نفسها قبل التغيير"]
    enable --> alternate["غير المتوافق أكّد بمسار بديل"]
    use -->|"لا"| physical{"هل هو جهاز IPP مادي هدف تغيّر الترتيب؟"}
    physical -->|"نعم"| redetect["احذف وأعد الاكتشاف مع إبقاء التعطيل"]
    redetect --> compare
    physical -->|"لا"| existing["أكّد الطباعة على الطابور الفعلي"]
    compare --> finish["سجّل النتيجة واستعد جهاز التحقّق"]
    alternate --> finish
    existing --> finish

الشكل 23: اجعل الإخراج قبل التغيير معياراً مشتركاً، ولا تفعّل إلّا في بيئة تستخدم WPP. في بيئة لا تستخدمه أكّد تغيّر ترتيب IPP والطباعة على الطابور الفعلي.

7.1 إعداد مشترك: أعد كلّ وجهات الطباعة على جهاز تحقّق لا على الإنتاج

استخدم للتحقّق حاسوباً Windows 11 24H2 فما بعده، ولا تجره على حاسوب الإنتاج. على الشبكة يمكن التحقّق في آلة افتراضية تصل إلى الطابعة نفسها. لتقييم إعادة التسجيل على USB أو الاتصال المباشر استخدم جهاز تحقّق ماديّاً، عدا آلة افتراضية يمكنها تمرير واجهة USB نفسها.

سواء استخدمت WPP أم لا، أبقِ الحالة قبل التغيير بالخطوتين 1 و2 التاليتين.

1. أعد كلّ الطوابير التي يستخدمها التطبيق في الميدان. ليس طابعة مادية ببرنامج تشغيل الصانع فقط؛ أدخل أيضاً الطابعة الافتراضية PDF من طرف ثالث والطابور المضمَّن مثل Generic / Text Only بالتكوين نفسه. سجّل اسم برنامج التشغيل والإصدار بسكربت 5.1. ما يمكن الحكم عليه بفرق الحذف هو الطابور الموجود على جهاز التحقّق فقط.
2. شغّل وظائف الطباعة جملة واحفظ الإخراج. أكّد شاشة إعداد الورق والصينية والوجهين وعدد النسخ، والطباعة لكلّ تقرير، وإخراج PDF، وطباعة الملصقات، واصنع معياراً يمكن مقارنته لاحقاً.

flowchart TB
    accTitle: الطوابير التي تُعاد على جهاز التحقّق
    accDescr: من الطوابير التي يستخدمها التطبيق كما تبيّن جرد 5.1 أعد على جهاز التحقّق بالتكوين نفسه في الميدان طابعة مادية ببرنامج تشغيل الصانع وطابعة افتراضية مثل PDF من طرف ثالث وطابور برنامج تشغيل مضمَّن مثل Generic / Text Only، وما يمكن الحكم عليه بقائمة الحذف في الخطوة 3 هو الطابور الموجود على جهاز التحقّق فقط
    inv["جرد 5.1: الطوابير التي يستخدمها التطبيق"]
    inv --> phys["طابعة مادية (من الصانع)"]
    inv --> virt["طابعة افتراضية (PDF من طرف ثالث ونحوه)"]
    inv --> inbox["برنامج تشغيل مضمَّن (Generic / Text Only ونحوه)"]
    phys --> vm["أعد بالتكوين نفسه على جهاز التحقّق"]
    virt --> vm
    inbox --> vm
    vm --> judge["احكم بالبقاء بقائمة الحذف في الخطوة 3"]
    note["الطابور الغائب لا يظهر في فرق الحذف"] -.-> judge

الشكل 24: الطابور الغائب عن جهاز التحقّق لا يظهر في فرق الحذف، فأعد أوّلاً كلّ الطوابير التي تبيّنها الجرد.

7.2 بيئة تستخدم WPP: فعّل وتحقّق بما في ذلك وجهات الطباعة التي اختفت

بعد الخطوتين 1 و2 امضِ بهذا الترتيب.

3. فعّل WPP وسجّل الطوابير التي تُحذف. من «الطابعات والماسحات» في تطبيق الإعدادات اختر «إعداد» لـ «Windows protected print mode» فيظهر هدف الحذف في حوار.² إن فعّلت بـ Group Policy لا يظهر الحوار، فاحفظ ناتج Get-Printer قبل التطبيق وأعد تشغيل جهاز التحقّق بعده. أكّد التفعيل بـ IsProtectedPrintEnabled أو شاشة الإعدادات ثمّ خذ القائمة من جديد وسجّل الفرق.¹⁴
4. أعد تثبيت الطابعات المتوافقة المحذوفة. أعد الإدخال بـ Windows Ready Print، وأكّد بسكربت 5.1 أن DriverName للطابعة المادية صار Microsoft IPP Class Driver.
5. كرّر الطباعة نفسها وقارن بما قبل التغيير. أكّد خيارات شاشة الإعدادات، واستعادة الإعدادات المحفوظة، وفقدان الوجهة بتغيّر اسم الطابور. طابق أيضاً الهوامش والخطوط والخطوط الشبكية في الإخراج بإخراج الخطوة 2.
6. غير المتوافق اطبعه بالمسار البديل في الفصل 6. أكّد أنّه يخرج بعد إعادة حالة «الطابعة ليست في القائمة». هدف التحقّق ليس الشيفرة المصلحة وحدها بل المسار المعدّ أيضاً.

7.3 بيئة لا تستخدم WPP: لا تفعّل، وتحقّق من تغيّر اختيار برنامج التشغيل

في بيئة قرّرت عدم استخدام WPP لا تُجرَ الخطوتان 3 و4. تفعيل WPP يحذف الطابور جملة فيختفي أثر الترتيب وحده.

7.4 الاستعادة بعد التحقّق وترتيب إجراء التجهيز

جهاز التحقّق الذي فُعِّل فيه WPP من تطبيق الإعدادات المحلي يمكن إرجاعه بـ «إيقاف». إن طُبِّق من Group Policy أو Intune لزم تغيير السياسة من جهة المسؤول، فهيّئ إجراء الاستعادة وفق مسار التفعيل.²¹³

إرجاع WPP إلى التعطيل لا يغيّر الطابعة التي أُعيد إدخالها بـ Windows Ready Print. الطابعة التي كانت غير متوافقة تُعاد تثبيتها يدوياً.²¹⁰

في التجهيز تُدمج سياسة WPP وإجراء إعادة تسجيل الطابعة في آلية التوزيع التي رُتّبت في من Group Policy إلى Intune. توزيع برامج التشغيل من أطراف ثالثة بـ Point and Print صار يحتاج افتراضيّاً بيانات اعتماد المسؤول منذ KB5005652 في 2021،³⁴ وأمام WPP لا يجري التوزيع نفسه.⁹ في بيئة تستخدم WPP استبدل الإجراء المعتمد على توزيع برنامج التشغيل بهذا تطبيق السياسة وإعادة التسجيل.

flowchart TB
    accTitle: مراجعة إجراء التجهيز
    accDescr: الإجراء الذي كان يوزّع برامج تشغيل من أطراف ثالثة بـ Point and Print يحتاج منذ 2021 بيانات اعتماد المسؤول ولا يجري التوزيع نفسه أمام WPP فيُخرَج، ويُدمَج بدلاً منه سياسة WPP (Group Policy أو OMA-URI) وإجراء إعادة تسجيل الطابعة في آلية التوزيع
    old["توزيع برامج تشغيل من أطراف ثالثة بـ Point and Print"]
    old --> why1["منذ 2021 تلزم بيانات اعتماد المسؤول"]
    old --> why2["أمام WPP لا يجري التوزيع نفسه"]
    why1 --> drop["أخرجه من الإجراء"]
    why2 --> drop
    drop --> add["أدمج سياسة WPP وإجراء إعادة التسجيل"]

الشكل 25: إجراء توزيع برنامج التشغيل يُستبدل بإجراء توزيع سياسة WPP وإعادة تسجيل الطابعة.

8. الخلاصة

ما يلزم من تعامل يُقرَّر بهذا الترتيب: «هل تبقى وجهة الطباعة» ← «علامَ تعتمد الشيفرة» ← «بأيّ شرط تتحقّق».

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

flowchart TB
    accTitle: شجرة قرار هل تصلح أم يكفي التأكيد
    accDescr: احكم أوّلاً هل يبقى طابور الوجهة أمام WPP (طابور سحابة Universal Print أو طابعة افتراضية متوافقة مع WPP) أو يمكن إعادة تسجيل الطابعة المادية بـ Windows Ready Print، فإن تعذّر فاختر إعداد مسار بديل أو عدم استخدام WPP، وإن كان الجهاز يدعم IPP وقد يتبدّل بتغيّر الترتيب فأكّد بهذا الترتيب حفظ الإعدادات الخاصّة ببرنامج التشغيل ثمّ تبعية اسم الطابور أو الطابعة الافتراضية (بما في داخل SDK والمكتبات) ثمّ إرسال RAW وأصلح إن انطبق ثمّ امضِ، وأخيراً إن استخدمت WPP فإلى تحقّق تفعيل WPP في الفصل 7، وإن لم تستخدمه فالجهاز المادي الداعم لـ IPP إلى تحقّق إعادة الاكتشاف مع إبقاء WPP معطّلاً، وطابور السحابة أو الافتراضي إلى تأكيد الإخراج الفعلي، وإن لم تستخدم WPP ولم يكن لأثر التبدّل موضع فالتشغيل بالمسار الحالي
    q0{"هل يبقى الطابور أمام WPP أو يمكن إعادة التسجيل؟"}
    q0 -->|"لا"| alt{"ماذا تفعل؟"}
    alt -->|"أعدّ مساراً بديلاً"| qi{"هل يدعم IPP وقد يتبدّل؟"}
    alt -->|"لا تستخدم WPP"| qi2{"هل يدعم IPP وقد يتبدّل؟"}
    qi -->|"نعم"| q1{"هل تُحفظ إعدادات خاصّة ببرنامج التشغيل؟"}
    qi -->|"لا"| verify["تحقّق فقط (الفصل 7)"]
    qi2 -->|"نعم"| q1
    qi2 -->|"لا"| keep["التشغيل بالمسار الحالي"]
    q0 -->|"نعم"| q1
    q1 -->|"نعم"| fix1["أصلح (5.2)"]
    fix1 --> q2{"هل هناك تبعية لاسم الطابور أو لطابعة افتراضية؟"}
    sdk["يشمل التبعية داخل SDK والمكتبة"] -.-> q2
    q1 -->|"لا"| q2
    q2 -->|"نعم"| fix2["أصلح (5.3 و5.4)"]
    fix2 --> q3{"هل يُمرَّر إرسال RAW إلى طابور لا يصمد أمام WPP؟"}
    q2 -->|"لا"| q3
    q3 -->|"نعم"| fix3["هيّئ الممرّ (الفصل 6)"]
    fix3 --> vq{"هل تستخدم WPP؟"}
    q3 -->|"لا"| vq
    vq -->|"نعم"| verify
    vq -->|"لا"| pq{"هل هو جهاز IPP مادي؟"}
    pq -->|"نعم"| redetect["تحقّق إعادة الاكتشاف بلا WPP (7.3)"]
    pq -->|"لا"| outchk["تأكيد الإخراج على الطابور الفعلي"]

الشكل 26: احكم أوّلاً هل يبقى الطابور أمام WPP، وتبعيات الشيفرة تمضي إلى التأكيد التالي ولو أُصلح واحد، والمسار المصلح يُتحقَّق منه أخيراً. إن لم تستخدم WPP فليس تفعيل WPP في الفصل 7 بل إعادة اكتشاف جهاز IPP المادي مع إبقاء WPP معطّلاً، وطابور السحابة أو الافتراضي بالإخراج الفعلي.

موعد الاستعداد تضعه في خطّة النشر لديكم لا في تواريخ Microsoft

يُقال إن WPP سيُفعَّل افتراضيّاً لاحقاً، لكن الموعد غير مبيَّن.¹⁰ موعد الاستعداد تضعه قبل تفعيل WPP لديكم، أو قبل نشر تحديث ميزات Windows 11 24H2 فما بعده في الميدان. 1 تمّوز/يوليو 2027 محطّة جهة توريد برامج التشغيل، وليس موعداً نهائيّاً لجهة تطبيق الأعمال.¹

flowchart TB
    accTitle: كيف تضع جهة تطبيق الأعمال موعد الاستعداد
    accDescr: خذ القائمة واجرد الآن، وأنهِ تغيير المسار والتحقّق قبل الموعد لديكم وهو قبل تفعيل WPP لديكم أو قبل نشر تحديث الميزات 24H2 فما بعده، وتوقّف تحديث برامج التشغيل في 1 تمّوز/يوليو 2027 محطّة جهة التوريد لا موعد استعداد، فاصنع أوّلاً حالة لا تتأثّر متى جاء تفعيل WPP الافتراضي غير المحدَّد الموعد
    now["الآن: أخذ القائمة والجرد"]
    now --> prep["تغيير المسار والتحقّق"]
    prep --> deadline["الموعد: قبل تفعيل WPP لديكم / قبل نشر تحديث الميزات"]
    deadline --> fine["لا تتأثّر إن جاء تفعيل WPP الافتراضي (موعد غير محدَّد)"]
    ms["1 تمّوز/يوليو 2027: توقّف تحديث برامج التشغيل"] -.->|"محطّة جهة التوريد لا موعد"| prep

الشكل 27: ضع الموعد في خطّة النشر لديكم، ولا تجعل تواريخ محطّات Microsoft موعداً نهائيّاً.

ابدأ بأخذ قائمة جهة التسليم وفهم تبعية الإعدادات ووجهة الطباعة ومسار الإخراج. ولّد PDF مباشرة، واحتفظ لطباعة الملصقات والإيصالات بمسار واحد مستقل عن مكدّس الطباعة. ثمّ تأكّد من الطباعة وفق شرط النشر الفعلي.

البيئة التي تبقى على Windows 10 خارج هذه الخطّة، لكن دعم القناة العادية لـ Windows 10 (22H2) انتهى في تشرين الأوّل/أكتوبر 2025. لـ Enterprise LTSC وIoT Enterprise LTSC مواعيد تختلف حسب الإصدار فيلزم تأكيد دورة الحياة. للحكم بما يشمل ESU وLTSC راجع الحلول الواقعية بعد انتهاء دعم Windows 10، وللحاسوب الصناعي أي Windows ينبغي تثبيته على الحاسوب الصناعي. استعداد الطباعة يمتدّ إلى إعادة تحقّق الفصل 7 على Windows 11 وجهة الترحيل.

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

• الطباعة وإخراج PDF في تطبيقات أعمال Windows ── التمييز بين System.Drawing.Printing وWPF ومكتبة التقارير
• كيفية بناء إخراج تقارير Excel - COM/Open XML/قوالب
• كيفية بناء خدمات Windows وتشغيلها ── من التمييز عن جدولة المهام إلى تحويل BackgroundService إلى خدمة
• كيفية التعامل مع أجهزة USB في تطبيقات Windows ── اختيار COM افتراضي وHID وWinUSB
• مزالق تطبيقات الاتصالات التسلسلية - حتّى إعادة الاتصال وتصميم السجلّ
• من Group Policy إلى Intune ── ترحيل إدارة الأجهزة في المؤسّسات الصغيرة والمتوسّطة
• الحلول الواقعية بعد انتهاء دعم Windows 10 ── حكم ESU وLTSC والاستبدال

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

تتناول شركة كومورا سوفت ذ.م.م. جرد تبعية تطبيقات الأعمال ذات طباعة التقارير والملصقات لبرامج تشغيل الطابعات، ومراجعة مسار الطباعة (التوليد المباشر لـ PDF والتحكّم المباشر بطابعة الملصقات)، وتصميم خطّة تحقّق تفترض Windows protected print mode.

• استشارة تقنية ومراجعة تصميم
• تطوير تطبيقات Windows
• اتصل بنا

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

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

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

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

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

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

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

هل تتوقّف الطابعات والتطبيقات العاملة اليوم فجأة عن الطباعة بعد تمّوز/يوليو 2026 أو تمّوز/يوليو 2027؟

لا. خطّة Microsoft قطع تدريجي من جهة التوريد: «عدم نشر برامج تشغيل جديدة من أطراف ثالثة على Windows Update»، و«تفضيل برنامج تشغيل فئة IPP في الترتيب»، و«عدم قبول التحديثات». وهي تنصّ صراحة على أنّها لا تعطّل البرامج القائمة. ويمكن تثبيت البرامج القائمة من مثبّتات الصانع أيضاً. الخطر في جهازين: أجهزة يطابقها برنامج تشغيل فئة IPP، عند استبدال الحاسوب أو إعادة تثبيت نظام التشغيل فيُستبدل البرنامج تلقائيّاً ببرنامج تشغيل فئة IPP، وعند تفعيل Windows protected print mode.

هل يُفعَّل Windows protected print mode افتراضيّاً؟

في وقت كتابة هذه المقالة (أيلول/سبتمبر 2026) معطّل افتراضيّاً، ويُفعَّل من تطبيق الإعدادات أو Group Policy أو Intune. لكن أسئلة Microsoft الشائعة تصرّح بأنّه «سيُفعَّل افتراضيّاً في وقت لاحق». لم يُذكر الموعد، فالاستعداد أن تصل إلى حالة لا تضرّك إن فُعِّل.

ماذا عن طابعات الملصقات وطابعات الإيصالات؟

الطابعات التي لا يمكنها الحصول على اعتماد Mopria مذكورة ضمن شروط يُسمح فيها استثنائيّاً بتوقيع برنامج التشغيل بعد 15 كانون الثاني/يناير 2026. أي قد يبقى برنامج تشغيل الصانع لفترة، لكن في بيئة فُعِّل فيها Windows protected print mode تُزال الطابعات التي تستخدم برامج تشغيل من أطراف ثالثة، فلا تُستخدم كما هي. إن احتفظت بمسار يتواصل فيه SDK الصانع مباشرة عبر TCP/USB/تسلسلي مع الجهاز، أو يرسل لغة الطابعة مباشرة، انفصلت عن تغيّر Print Spooler. أمّا SDK يستدعي داخليّاً طابور Windows أو برنامج التشغيل فيتوقّف بالمثل إن اختفى برنامج الطرف الثالث، فلا يكون مهرباً.

هل يمكن الإبقاء على شيفرة الطباعة على PrintDocument؟

مسار طباعة GDI ومسار طباعة XPS يبقيان، وتصرّح Microsoft بأنّها لا تخطّط لتعطيل وظائف برامج تشغيل v3/v4. التطبيق الذي يرسم فقط بـ PrintDocument أو FixedDocument ليس هدفاً للإصلاح بل للتحقّق. هدف الإصلاح الشيفرة التي تحفظ وتعيد إعدادات خاصّة ببرنامج التشغيل (الجزء غير العام من DEVMODE أو فضاء أسماء PrintTicket الخاص)، والشيفرة التي تعتمد على اسم طابور معيّن أو اسم طابعة افتراضية (بما في ذلك ما يستدعيه SDK الصانع أو مكتبة التقارير داخليّاً)، والشيفرة التي تمرّر بيانات RAW عبر المُبَوِّب إلى طابور لا يصمد أمام WPP (مثل طابور برنامج تشغيل الصانع). لكن إن كان جهاز الوجهة نفسه لا يمكن إعادة تسجيله بـ Windows Ready Print، فحتّى إن كانت الشيفرة رسماً فقط يختفي الطابور تحت Windows protected print mode، فيسبق ذلك إعداد مسار بديل.

من أين أبدأ؟

من أخذ قائمة طابعات وبرامج تشغيل جهة التسليم. بـ Get-Printer وGet-PrinterDriver في PowerShell تُؤخذ بلا صلاحيات مسؤول أيّ طابور يستخدم أيّ برنامج تشغيل (v3 أم v4، أم برنامج تشغيل فئة IPP). ثمّ تطابق من تلك القائمة الطوابير التي يسمّيها التطبيق أو يحفظ إعداداتها أو يرسل إليها RAW، وتوزّعها بجدول القرار في هذه المقالة إلى «كما هي» و«تحقّق» و«غيّر المسار».

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

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

غو كومورا

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

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