الحبّ الشاذّ للمطوّر، أو كيف تعلّمت أن أكفّ عن القلق وأن أحبّ Windows

هذه مقالة انطباعية عن كيفية التعامل مع شعور «أخاف أن يتعطل التطبيق باختلاف البيئة» في تطوير تطبيقات Windows. ليست شرحاً لكيفية استخدام واجهات API.

DLL، COM، 32-bit / 64-bit، الصلاحيات، DPI، التوزيع. أتحدث عن سبب حمل Windows لهذه الهموم، وعن كيفية تحويل ذلك القلق إلى تصميم واختبار وملاحظة. إن أردت شيئاً عملياً تأخذه معك، يكفي أن تنظر إلى جدول «القلق / إجراء التصميم / طريقة التحقّق» في الفصل 6.

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

عند بناء تطبيقات Windows، يكثر ما يدعو إلى القلق.

هل سيُقلع على هذا الحاسوب؟ هل سيعمل في بيئة بلا صلاحيات مدير (administrator)؟ هل سيتعطل بسبب الفرق بين 32-bit و64-bit؟ مسارات يابانية، مسارات طويلة، أقراص شبكة، DLL قديمة، مكوّنات COM، ActiveX، طابعات، اتصال تسلسلي (serial)، برامج مكافحة الفيروسات، Windows Update.

ما إن تبدأ التفكير حتى لا ينتهي القلق.

لكن منذ حين صرت أرى الأمر على نحو آخر.

لعلّ هذا ليس عيباً، بل دليلاً على أنّ Windows حمل أعمالاً واقعية.

Windows ليس مدينة فاضلة نقيّة. لكنّه يحمل في داخله البرمجيات والأجهزة وسير العمل وعادات الناس التي ظلّت تعمل في الميدان عقوداً.

هذا الاختلاط نفسه هو ما يجعل Windows مثيراً، وما يجعله، من منظور المطوّر، جديراً بالمواجهة.

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

2. تطوير تطبيقات Windows يحمل هموماً كثيرة

في تطوير تطبيقات Windows، لا يكفي أن يكون «الكود صحيحاً».

يعمل في البيئة المحلّية. يعمل على حاسوب المطوّر. يعمل حتى على الجهاز الافتراضي (VM) الخاص بالاختبار.

ومع ذلك، لا ضمانة أن يعمل على حاسوب العميل.

على سبيل المثال، تحدث أمور كهذه:

• تعذّر العثور على DLL
• بيئة تشغيل Visual C++ غير مثبَّتة
• إصدار .NET Framework غير متطابق
• فشل تحميل DLL بـ 32-bit من عملية (process) بـ 64-bit
• تسجيل COM تالف
• الخلط بين نسختَي regsvr32.exe الخاصتَين بـ 32-bit و64-bit
• كود يفترض دليلاً حالياً (current directory) ثابتاً ينهار تحت جدولة المهام (Task Scheduler)
• محاولة الكتابة داخل Program Files تؤدّي إلى خطأ في الصلاحيات
• الخلط بين استخدام AppData\Roaming وAppData\Local
• انهيار عند وجود أسماء مستخدمين أو أسماء مجلدات باليابانية
• تعذّر فتح الملفات بسبب مسارات طويلة
• يعمل على قرص شبكة مُعرَّف (mapped) لكن لا يعمل عبر مسار UNC
• انهيار الواجهة في بيئات DPI العالي
• انزياح حسابات الإحداثيات مع تعدّد الشاشات
• اختلاف نتيجة الطباعة باختلاف مشغّل الطابعة (printer driver)
• عدم التعرّف على أجهزة USB والكاميرات وأجهزة القياس والاتصال التسلسلي بحسب البيئة
• حجب برنامج مكافحة الفيروسات جزءاً من المعالجة
• تغيّر السلوك بعد Windows Update

عند سرد كلّ هذا، يصيب المرء دوار خفيف.

المشكلات التي تُحصر في تطبيق ويب بين المتصفّح والخادم، تتّسع في تطبيق Windows لتشمل الحاسوب كلّه. نظام الملفات، السجلّ (Registry)، ملفّ تعريف المستخدم، الطابعة، الأجهزة، الشبكة، سياسات الأمن، المثبِّت، بيئة التشغيل (runtime).

التطبيق لا يعمل «فوق نظام التشغيل» بقدر ما يُوضع داخل بيئة العمل.

لذلك يصعب تطوير تطبيقات Windows. غير أنّني أرى أنّ رمي الأمر بعبارة «Windows سيّئ» يجانب الصواب قليلاً.

ما يركب عليه هو تعقيد العالم الواقعي.

3. Windows هو «نظام تشغيل الميدان»

Windows ليس نظام تشغيل لأحدث التقنيات وحدها.

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

وليس فيها خدمات ويب حديثة وحدها.

هناك وحدات ماكرو Excel. وهناك Access. وهناك تطبيقات VB قديمة. وهناك تطبيقات أعمال بـ .NET Framework. وهناك تطبيقات مقيمة (resident) مكتوبة بـ C++. وهناك مكوّنات COM. وهناك ActiveX. وهناك اتّصالات ODBC. وهناك مشغّلات طابعات. وهناك قارئات باركود. وهناك أجهزة قياس باتّصال تسلسلي. وهناك حزم SDK يقدّمها البائعون.

وهي لا توجد منفردة.

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

Windows ليس مجرّد قاعدة لإقلاع التطبيقات. إنّه منصّة تستوعب عمل الميدان، والأصول القائمة، والأجهزة المحيطة، وعادات الناس.

لذلك يبدو أحياناً قديماً. وأحياناً معقّداً. وأحياناً تتساءل لماذا ما زال هذا موجوداً.

غير أنّ ذلك يعني أيضاً أنّه لم يتخلّ عن القديم باستخفاف.

4. التوافق مع الإصدارات السابقة بوصفه ضرباً من المحبّة

إن كان المراد تجميل نظام التشغيل فحسب، فأسهل شيء هو قطع الآليات القديمة.

احذف واجهات API القديمة. احذف بيئات التشغيل القديمة. احذف شاشات الإعداد القديمة. عامل التطبيقات القديمة على أنّها لن تعمل.

قد يصبح التصميم أنظف. وقد تقصر الوثائق. وقد يخفّ مزاج المطوّر قليلاً.

لكن في المقابل تتعطّل تطبيقات أعمال. وتتوقّف أجهزة. ويقع الميدان في حرج.

التوافق مع الإصدارات السابقة في Windows مزعج تقنياً. هناك WOW64 (Windows 32-bit On Windows 64-bit) لتشغيل تطبيقات 32-bit على Windows بـ 64-bit. وقد يختلف مظهر السجلّ وملفات DLL بين 32-bit و64-bit. وهناك بنية تربك من يراها أوّل مرّة: C:\Windows\System32 للجانب 64-bit، وC:\Windows\SysWOW64 للجانب 32-bit.

COM (Component Object Model؛ آلية Windows لتبادل المكوّنات بين التطبيقات) مزعج أيضاً. وضع DLL وحده قد لا يكفي، وقد يلزم التسجيل. هل وجهة التسجيل على مستوى المستخدم أم على مستوى الجهاز؟ هل المكوّن COM بـ 32-bit أم بـ 64-bit؟ هل تلزم صلاحيات مدير؟

وينطبق الأمر نفسه على .NET Framework. اليوم يمكن اختيار .NET أحدث مثل .NET 8 / .NET 9. غير أنّ الميدان ما زال فيه تطبيقات .NET Framework 4.x. وليست قديمة فحسب؛ فقد ساندت العمل بذلك الإصدار سنوات طويلة.

التوافق مع الإصدارات السابقة ليس مفهوماً جميلاً فحسب. إنّه، بالأحرى، مسؤولية ثقيلة.

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

أرى هنا ما يستحقّ أن يُحبّ في Windows.

5. Windows نظام تشغيل كالطبقات الجيولوجية

في Windows تتراكم تقنيات العصور كطبقات الأرض.

Win32. COM. ActiveX. Windows Forms. WPF. .NET Framework. UWP. WinUI. Windows App SDK. MSIX. PowerShell. Windows Terminal. WSL.

لكلّ منها عصر ظهور، وميدان تتفوّق فيه، ومواقع استُخدمت فيها.

إن نظرت إلى الجديد وحده، بدا القديم عائقاً. غير أنّ تطوير تطبيقات Windows كثيراً ما يمنعك من تجاهل الطبقات القديمة.

مثلاً، حتى إن بنيت تطبيقاً بـ WPF، قد تصطدم في الطباعة بمشكلات GDI (Graphics Device Interface؛ آلية الرسم والطباعة التي يحملها Windows منذ زمن بعيد) أو مشغّل الطابعة. وحتى إن كتبت بـ C#، إن كان SDK البائع DLL أصليّاً فستصطدم بـ P/Invoke (Platform Invoke؛ آلية استدعاء دوال DLL الأصلي من C#) أو بمسألة عدد البتّات. وحتى إن صنعت شاشة جديدة، قد يلزم الإبقاء على مكوّن COM قائم أو على تكامل مع Excel.

Windows ليس حديقة منسّقة حتى النهاية. هو أقرب إلى مدينة ضخمة أُعيد توسيعها مراراً.

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

يسهل أن تضيع. لكن في أعماق تلك الأزقّة ما زال عمل مهمّ يدور.

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

ما يحتاجه المطوّر ليس الحكم بأنّ «القديم غير لازم». بل تمييز أيّ طبقة تقنية تسند أيّ عمل.

6. تحويل الثقل إلى تصميم

كتبت في العنوان «أكفّ عن القلق».

غير أنّ الكفّ عن القلق ليس تراخياً. وليس تجاهلاً للمشكلة.

الكفّ عن القلق يعني تحويل القلق إلى تصميم.

مثلاً، إن كنت تقلق من الإقلاع، فاجعل تأكيد الإقلاع اختبار دخان (smoke test).

Start-Process .\MyApp.exe

ولا تكتفِ بالإقلاع العادي. جرّب أيضاً غياب ملفّ الإعداد، وغياب مجلد السجلّات، وصلاحيات مستخدم عادي، وانقطاع الشبكة، وغياب إعداد الطابعة، وDPI العالي، والمسار الطويل، والمسار الياباني.

إن كنت تقلق من DLL، فتأكّد من التبعيات. إن لزم Visual C++ runtime، فقرر هل تضمّه في المثبِّت أم تنصّ عليه كشرط مسبق. إن استخدمت DLL أصليّاً، فلا تترك علاقة x86 / x64 / AnyCPU غامضة.

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

# 64bit COM DLL の登録例
C:\Windows\System32\regsvr32.exe .\SomeComponent64.dll

# 32bit COM DLL の登録例
C:\Windows\SysWOW64\regsvr32.exe .\SomeComponent32.dll

إن كنت تقلق من الصلاحيات، فتجنّب تصميماً لا يعمل إلا بصلاحيات مدير. ضع إعدادات المستخدم في AppData، والإعدادات المشتركة في ProgramData. تجنّب تصميماً يكتب السجلّات تحت Program Files.

إن كنت تقلق من المسارات، فأدخل اليابانية، والمسافات، وأسماء المجلدات الطويلة، ومسارات UNC في الاختبار.

New-Item -ItemType Directory -Path "C:\テスト 用\とても長いフォルダー名\さらに深いフォルダー" -Force

إن كنت تقلق من DPI، فتحقّق عند 100%، و125%، و150%، و200%. وانظر هل ينهار العرض عند عبور شاشات بمعدّلات تكبير مختلفة. WinForms وWPF وWinUI تختلف في فكر دعم DPI، فتحقّق بحسب تقنية الشاشة.

إن كنت تقلق من الذاكرة أو المقابض (handles)، فاستخدم Application Verifier وWinDbg وProcDump وProcess Explorer وغيرها. إن كنت تقلق من الانهيار، فاترك سجلّ الأحداث، وملفات dump، وسجلّ التطبيق.

Get-EventLog -LogName Application -Newest 20

أو، في بيئة أحدث، راجع سجلّ الأحداث كما يلي.

Get-WinEvent -LogName Application -MaxEvents 20

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

حوّل القلق إلى شكل يمكن ملاحظته.

هذا مهمّ جداً في تطوير تطبيقات Windows.

إن لخّصنا ما سبق في صفحة واحدة، صار كالتالي.

العمود الأيسر في هذا الجدول هو قائمة الهموم كما هي. بوجود العمودين الأيمنين يتحوّل القلق إلى عمل.

7. الهدف النهائي هو «أن يعمل على حاسوب العميل»

أن يعمل في بيئة التطوير أمر مهمّ. وأن تمرّ الاختبارات في CI أمر مهمّ. وأن يعمل على VM نظيف أمر مهمّ أيضاً.

لكن في تطبيقات Windows، ما يقف في النهاية هو «هل يعمل على حاسوب العميل».

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

لذلك تصير طريقة التوزيع مهمّة أيضاً.

هل يكفي تسليم exe؟ هل تجعله MSI؟ أم ClickOnce؟ أم MSIX؟ هل يمكن توزيعه بـ winget؟ هل يُحمَّل على نظام توزيع داخلي؟ هل يلزم مثبِّت دون اتصال؟ هل يلزم توقيع الرمز (code signing)؟ هل سيتوقّف عند SmartScreen أو برنامج مكافحة الفيروسات؟

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

في تطوير تطبيقات Windows، البرنامج لا ينتهي عند التسليم. يلزم أن يُقلع غداً كما أقلع اليوم، في بيئة العميل.

8. ومع ذلك، لماذا أحبّ Windows

في Windows مواضع مزعجة. هذا واقع.

DLL. COM. السجلّ (Registry). UAC. DPI. الطابعة. بيئة التشغيل (runtime). 32-bit / 64-bit. أقراص الشبكة. المسارات الطويلة. البيئة اليابانية. برامج الأمن. Windows Update.

إن سردت المزعج، فالقائمة لا تنتهي.

للتوضيح، UAC هو User Account Control (التحكّم بحساب المستخدم)، وDPI هو Dots Per Inch (إعداد تكبير الشاشة). كلاهما صياغة أخرى لفكرة أنّ «التطبيق لا يكتمل بنفسه».

غير أنّ كثيراً من هذا الثقل يأتي من أنّ Windows حمل أعمالاً واقعية زمناً طويلاً.

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

ليست هذه عقيدة واحدة جميلة.

لكنّها قويّة.

ومن منظور المطوّر، تستحقّ المواجهة.

صنع برمجيات تعمل بثبات على Windows ليس مجرّد استدعاء API. هو قراءة قيود الميدان، وفهم الأصول القائمة، وإيجاد المواضع القابلة للكسر، والاختبار، والملاحظة، وإصلاح ما يلزم.

عمل رتيب. لكنّه ذو قيمة.

9. الخلاصة

في تطوير تطبيقات Windows لا ينتهي القلق.

غير أنّ كثيراً من ذلك القلق نتيجة أنّ نظام التشغيل هذا استوعب، على مدى زمن طويل، أعمالاً واقعية وميداناً وأجهزة وتشغيل بشر.

لذلك لا أرى Windows مجرّد نظام قديم.

إنّه منصّة ضخمة معقّدة، قليلة اللباقة قليلاً، ظلّت تعمل وهي تساوم الواقع.

وصنع برمجيات تعمل بثبات فوقها ما زال يحمل قيمة كبيرة.

أكفّ عن القلق.

لكنّني لا أتراخى.

أحوّل القلق إلى تصميم واختبار وملاحظة.

وهكذا صرت، شيئاً فشيئاً، أحبّ Windows.

روابط مرجعية

• Application Verifier - Overview - Microsoft Learn
• High DPI Desktop Application Development on Windows - Microsoft Learn
• Setting the default DPI awareness for a process - Microsoft Learn
• Running 32-bit Applications - Microsoft Learn
• Maximum Path Length Limitation - Microsoft Learn
• MSIX documentation - Microsoft Learn
• Version compatibility in .NET Framework - Microsoft Learn

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

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

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

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

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

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

غو كومورا

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

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