جحيم ملفات DLL

قد يكون إصدار معين من مكتبة ما متوافقًا مع بعض البرامج التي تستخدمه وغير متوافق مع برامج أخرى. وقد كان نظام ويندوز عرضةً لهذه المشكلة بشكل خاص نظرًا لتركيزه على الربط الديناميكي لمكتبات C++ وكائنات OLE ( ربط وتضمين الكائنات ). تُصدّر فئات C++ العديد من الدوال، وقد يؤدي تغيير واحد في الفئة، مثل إضافة دالة افتراضية جديدة، إلى عدم توافقها مع البرامج التي بُنيت باستخدام إصدار سابق. يحتوي OLE على قواعد صارمة للغاية لمنع ذلك: إذ يجب أن تكون الواجهات مستقرة، ولا تتم مشاركة مديري الذاكرة. ومع ذلك، فإن هذا غير كافٍ، لأن دلالات الفئة قابلة للتغيير. قد يؤدي إصلاح خطأ في تطبيق ما إلى إزالة ميزة من تطبيق آخر. قبل ويندوز 2000 ، كان ويندوز عرضةً لهذه المشكلة لأن جدول فئات COM كان مشتركًا بين جميع المستخدمين والعمليات. كان من الممكن تعريف كائن COM واحد فقط في ملف DLL/EXE واحد بمعرف فئة COM عام محدد على النظام. إذا احتاج أي برنامج إلى إنشاء نسخة من تلك الفئة، فإنه يحصل على التنفيذ المُسجّل مركزيًا الحالي. ونتيجة لذلك، قد يؤدي تثبيت برنامج يقوم بتثبيت إصدار جديد من عنصر مشترك إلى تعطيل برامج أخرى مثبتة مسبقًا عن غير قصد.

تحدث مشكلة شائعة ومزعجة عندما يقوم برنامج مُثبَّت حديثًا باستبدال مكتبة DLL نظامية عاملة بإصدار أقدم غير متوافق. من الأمثلة المبكرة على ذلك ctl3d.dllمكتبات ctl3dv2.dllWindows 3.1 : وهي مكتبات أنشأتها مايكروسوفت، وكان الناشرون الخارجيون يوزعونها مع برامجهم، ولكن كل منهم كان يوزع الإصدار الذي طوّره بدلاً من أحدث إصدار. ^{[ 2 ]} يحدث استبدال مكتبة DLL للأسباب التالية:

• قامت مايكروسوفت في السابق بتوزيع ملفات DLL الخاصة بوقت التشغيل كمكونات نظام مشتركة ^{[ 3 ]} (في الأصل C:\WINDOWS و C:\WINDOWS\SYSTEM)، كوسيلة لمشاركة التعليمات البرمجية بكفاءة في نظام تشغيل ذي ذاكرة مشتركة ومساحة تخزين محدودة. ونتيجة لذلك، قام مطورو البرامج من جهات خارجية بتوزيعها بنفس الطريقة.
• عادةً ما يتم تشغيل برامج تثبيت التطبيقات في بيئة أمان ذات امتيازات، مما يتيح لها تثبيت ملفات DLL في مجلدات النظام وتعديل سجل النظام لتسجيل ملفات DLL جديدة ككائنات COM . لذلك، قد يؤدي برنامج تثبيت رديء التصميم أو غير مُهيأ بشكل صحيح إلى خفض إصدار مكتبة النظام في الإصدارات القديمة من ويندوز، حيث لا تستطيع حماية ملفات ويندوز أو حماية موارد ويندوز التراجع عن هذا التغيير. في ويندوز فيستا والإصدارات الأحدث، لا يُسمح إلا لحساب "المثبّت الموثوق" بإجراء تغييرات على مكتبات نظام التشغيل الأساسية.
• سُمح لتطبيقات ويندوز بتضمين تحديثات نظام التشغيل في برامج التثبيت الخاصة بها. أي أن العديد من مكتبات مايكروسوفت الديناميكية (DLL) قابلة لإعادة التوزيع ، مما يعني أن التطبيقات يمكنها تضمينها إذا احتاجت إلى خدمات تلك المكتبات.
• قبل برنامج Windows Installer ، كانت برامج تثبيت Windows تاريخياً منتجات تجارية؛ حاول العديد من الأشخاص كتابة برامج التثبيت الخاصة بهم، متجاهلين أو غير متعاملين مع مشاكل الإصدارات في هذه العملية.
• لم تقم بعض بيئات التطوير بإضافة مورد الإصدار تلقائيًا إلى مكتباتها المُجمّعة، لذا أغفل العديد من المطورين هذا الجانب. وكانت الخيارات المتاحة بدلاً من استخدام نظام الإصدار الصحيح هي التحقق من تواريخ الملفات، أو استبدال الملفات الموجودة، أو تخطي عملية النسخ إذا كان ملف DLL مُثبّتًا بالفعل.
• في بعض الأحيان، كان نظام التشغيل نفسه يزيل ملفات DLL أو يستبدلها بإصدارات أقدم أو مهملة. على سبيل المثال، كان نظام التشغيل Windows 2000 يقوم بتثبيت ملفات DLL الخاصة بالطابعات أحادية اللون فوق ملفات DLL الخاصة بالطابعات الملونة، إذا تم تثبيت طابعة أحادية اللون بعد تثبيت الطابعة الملونة. ^{[ 4 ]}

في COM وأجزاء أخرى من نظام التشغيل Windows، قبل إدخال التجميعات المتجاورة غير المعتمدة على سجل النظام، ^{[ 5 ]} كان سجل النظام يُستخدم لتحديد مكتبة الارتباط الديناميكي (DLL) الأساسية المراد استخدامها. إذا تم تسجيل إصدار مختلف من وحدة نمطية، فسيتم تحميل مكتبة الارتباط الديناميكي هذه بدلاً من الإصدار المتوقع. قد يحدث هذا السيناريو نتيجةً لتثبيتات متضاربة تُسجل إصدارات مختلفة من المكتبات نفسها، وفي هذه الحالة، يُعتمد آخر تثبيت.

تقوم إصدارات ويندوز ذات 16 بت (وويندوز على ويندوز ) بتحميل نسخة واحدة فقط من أي مكتبة DLL؛ حيث تشير جميع التطبيقات إلى نفس النسخة الموجودة في الذاكرة، إلى أن يتوقف استخدامها ويتم إلغاء تحميلها من الذاكرة. (بالنسبة لإصدارات ويندوز ذات 32 بت و64 بت، لا يحدث التشارك بين العمليات إلا عندما تقوم ملفات تنفيذية مختلفة بتحميل وحدة نمطية من نفس الدليل تمامًا؛ حيث تتم مشاركة الكود، وليس مكدس الاستدعاءات ، بين العمليات من خلال عملية تسمى "تعيين الذاكرة"). وبالتالي، حتى عندما تكون مكتبة DLL المطلوبة موجودة في دليل يُتوقع وجودها فيه، مثل دليل النظام أو دليل التطبيق، فلن يتم استخدام أي من هاتين النسختين إذا بدأ تطبيق آخر بإصدار غير متوافق من دليل ثالث. قد تظهر هذه المشكلة على شكل خطأ في التطبيق ذي 16 بت، والذي يحدث فقط عند بدء تشغيل التطبيقات بترتيب معين.

يتعارض هذا الأمر بشكل مباشر مع مشكلة استبعاد مكتبات الارتباط الديناميكي (DLL): إذا لم تؤثر تحديثات مكتبة الارتباط الديناميكي على جميع التطبيقات التي تستخدمها، يصبح من الصعب للغاية "صيانة" المكتبة، أي إزالة المشاكل الموجودة في الإصدارات الحالية منها. (تُعدّ إصلاحات الأمان حالةً بالغة الصعوبة والتعقيد). بدلاً من إصلاح أحدث إصدار من المكتبة فقط، يجب على المطور، في الوضع الأمثل، إجراء إصلاحاته واختبار توافقها مع كل إصدار مُتاح من المكتبة.

يبحث نظام ويندوز في مواقع متعددة عن ملفات DLL غامضة، أي تلك التي لم يتم تحديدها بالكامل. يمكن للبرامج الضارة استغلال هذا السلوك بعدة طرق تُعرف مجتمعةً باسم اختطاف ترتيب البحث عن ملفات DLL . إحدى هذه الطرق هي التحميل المسبق لملفات DLL أو هجوم زرع الملفات الثنائية . حيث يتم وضع ملفات DLL بنفس الاسم في موقع يتم البحث فيه مسبقًا، مثل دليل العمل الحالي . عندما يحاول البرنامج المُعرَّض للاختراق تحميل ملف DLL، يتم تشغيل النسخة الضارة، وربما بصلاحيات عالية إذا كان البرنامج يعمل على هذا المستوى. ^{[ 6 ]}

هناك طريقة أخرى تُعرف باسم اختطاف مكتبة الارتباط الديناميكي (DLL) عبر المسار النسبي ، حيث يتم نقل البرنامج المُعرّض للاختراق إلى موقع مُحدد مع مكتبة الارتباط الديناميكي الخبيثة. يتم تحميل مكتبة الارتباط الديناميكي الخبيثة لأن دليل التطبيق يُبحث فيه مُبكرًا. ووفقًا لشركة كراود سترايك ، تُعد هذه الطريقة الأكثر شيوعًا. ^{[ 7 ]} أما التحميل الجانبي لمكتبة الارتباط الديناميكي فيُتيح تحميل كلٍ من البرنامج الشرعي والمكتبة الخبيثة. وقد يُجنّب هذا الأسلوب الكشف عنه لأن تنفيذه يبدو وكأنه تشغيل برنامج موثوق. ^{[ 8 ]}

وتشمل الطرق الأخرى اختطاف ملفات DLL الوهمية ، حيث يتم إنشاء ملف DLL خبيث مقابل مراجع لمكتبة غير موجودة، وتغيير قيم التسجيل لاستغلال إعادة توجيه DLL ، مما يغير ترتيب البحث عن ملفات DLL. ^{[ 6 ]}

استخدمت جماعات مدعومة من الدولة، بما في ذلك مجموعة لازاروس وفرقة تروبيك تروبر، تقنية اختطاف ملفات DLL . ^{[ 8 ]}

يُعدّ الربط الثابت لجميع المكتبات حلاً بسيطاً لمشكلة تعارض مكتبات DLL في التطبيقات ، أي تضمين إصدار المكتبة المطلوب في البرنامج بدلاً من استخدام مكتبة نظام باسم مُحدد. ^{[ 9 ]} يُعدّ هذا شائعاً في تطبيقات C/C++، حيث يتم تجميع التطبيق ليتم ربطه ثابتاً بنفس المكتبات بدلاً من القلق بشأن إصدار المكتبة MFC42.DLLالمُثبّتة. يُلغي هذا الربط الثابت مكتبات DLL تماماً، وهو ممكن في التطبيقات المستقلة التي تستخدم فقط المكتبات التي تُوفّر خيار الربط الثابت، كما هو الحال في مكتبة Microsoft Foundation Class Library . مع ذلك، يتم التضحية بالهدف الرئيسي لمكتبات DLL، وهو مشاركة المكتبات أثناء التشغيل بين البرامج لتقليل استهلاك الذاكرة؛ إذ يُؤدي تكرار كود المكتبة في عدة برامج إلى تضخم حجم البرنامج ويُعقّد عملية نشر التحديثات الأمنية أو الإصدارات الأحدث من البرامج التابعة.

تم الحدّ من مشكلة استبدال ملفات DLL (التي تُعرف في مايكروسوفت باسم "DLL stomping ") إلى حدٍّ ما مع ميزة حماية ملفات ويندوز (WFP) ^{[ 10 ]} ، التي طُرحت في ويندوز 2000 ^{[ 11 ]} . تمنع هذه الميزة التطبيقات غير المصرح لها من استبدال ملفات DLL الخاصة بالنظام، إلا إذا كانت تستخدم واجهات برمجة تطبيقات ويندوز (APIs) المحددة التي تسمح بذلك. قد يبقى هناك احتمال أن تكون تحديثات مايكروسوفت غير متوافقة مع التطبيقات الحالية، ولكن هذا الاحتمال عادةً ما يقلّ في الإصدارات الحالية من ويندوز من خلال استخدام التجميعات المتجاورة .

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

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

كان الحل اليدوي السهل لمشكلة التعارضات هو وضع الإصدارات المختلفة من ملف DLL المُسبب للمشكلة في مجلدات التطبيقات نفسها، بدلاً من مجلد مشترك على مستوى النظام. ينجح هذا الحل عمومًا طالما أن التطبيق يعمل بنظام 32 بت أو 64 بت، وأن ملف DLL لا يستخدم ذاكرة مشتركة. أما في حالة التطبيقات ذات 16 بت، فلا يمكن تشغيل التطبيقين في وقت واحد على منصة 16 بت، أو في نفس الجهاز الظاهري ذي 16 بت ضمن نظام تشغيل 32 بت. وقد منع OLE حدوث ذلك قبل نظامي التشغيل Windows 98 SE/2000، لأن الإصدارات السابقة من Windows كانت تحتوي على سجل واحد لكائنات COM لجميع التطبيقات.

قدّم نظاما التشغيل Windows 98 SE/2000 حلاً يُسمى التجميع جنبًا إلى جنب ، ^{[ 12 ]} حيث يتم تحميل نسخ منفصلة من مكتبات DLL لكل تطبيق يحتاجها (مما يسمح بتشغيل التطبيقات التي تتطلب مكتبات DLL متضاربة في وقت واحد). يُزيل هذا الأسلوب التعارضات من خلال السماح للتطبيقات بتحميل إصدارات فريدة من الوحدة النمطية في مساحة عناوينها، مع الحفاظ على الفائدة الأساسية لمشاركة مكتبات DLL بين التطبيقات (أي تقليل استخدام الذاكرة) باستخدام تقنيات تعيين الذاكرة لمشاركة التعليمات البرمجية المشتركة بين العمليات المختلفة التي لا تزال تستخدم نفس الوحدة النمطية. مع ذلك، لا يمكن لمكتبات DLL التي تستخدم بيانات مشتركة بين عمليات متعددة اتباع هذا الأسلوب. ^{[ 13 ]} من الآثار الجانبية السلبية أن النسخ اليتيمة من مكتبات DLL قد لا يتم تحديثها أثناء العمليات المؤتمتة.

اعتمادًا على بنية التطبيق وبيئة التشغيل، قد تكون التطبيقات المحمولة وسيلة فعّالة للحد من بعض مشاكل مكتبات الارتباط الديناميكي (DLL)، حيث يضم كل برنامج نسخًا خاصة به من أي مكتبات DLL يحتاجها. ^{[ 11 ]} تعتمد هذه الآلية على عدم تحديد التطبيقات لمسارات مكتبات DLL التابعة لها بشكل كامل عند تحميلها، وعلى قيام نظام التشغيل بالبحث في دليل الملفات التنفيذية قبل أي موقع مشترك. ^{[ 14 ]} مع ذلك، يمكن استغلال هذه التقنية من قِبل البرامج الضارة، ^{[ 15 ]} وقد تأتي هذه المرونة المتزايدة على حساب الأمان إذا لم يتم تحديث مكتبات DLL الخاصة بتصحيحات الأمان بنفس طريقة تحديث المكتبات المشتركة.

يمكن أن تسمح تقنية المحاكاة الافتراضية للتطبيقات أيضًا بتشغيل التطبيقات في "فقاعة"، مما يتجنب تثبيت ملفات DLL مباشرة في نظام التشغيل.

هناك تدابير مضادة أخرى لتجنب مشكلة DLL hell، وقد يتطلب استخدام بعضها في وقت واحد؛ ومن الميزات الأخرى التي تساعد في تخفيف المشكلة ما يلي:

• أصبحت أدوات التثبيت الآن مُدمجة في Microsoft Visual Studio ، أحد البيئات الرئيسية لتطوير تطبيقات Windows. تقوم هذه الأدوات بفحص الإصدارات قبل تثبيت ملفات DLL، ويمكنها تضمين حزم تثبيت مُحددة مسبقًا في ملف MSI. يتيح ذلك لتطبيقات الطرف الثالث دمج تحديثات مكونات نظام التشغيل دون الحاجة إلى كتابة برامج تثبيت خاصة بها لهذه المكونات.
• يمكن لخاصية استعادة النظام إصلاح النظام بعد تثبيت خاطئ، بما في ذلك تلف سجل النظام. ورغم أن هذا لا يمنع المشكلة، إلا أنه يُسهّل عملية التعافي منها.
• دليل WinSxS ( Windows Side-by-Side )، الذي يسمح بتعايش إصدارات متعددة من نفس المكتبات.
• قم بتشغيل تطبيقات 16 بت في مساحة ذاكرة منفصلة ضمن إصدار 32 بت من نظام التشغيل Windows للسماح لتطبيقين باستخدام إصدارات متعارضة من نفس ملف DLL في نفس الوقت.
• استخدم إصدارًا من نظام التشغيل ويندوز يتضمن ميزة حماية ملفات النظام . يدعم كل من ويندوز مي وويندوز 2000 ، اللذان صدرا عام 2000، هذا النوع من حماية ملفات النظام، وكذلك ويندوز إكس بي وويندوز سيرفر 2003. أما بديلها، حماية موارد النظام ، فقد طُرح في ويندوز فيستا وويندوز سيرفر 2008 ، ويستخدم طريقة مختلفة لحماية ملفات النظام من التغيير.
• تقنية COM بدون تسجيل: قدم نظام التشغيل Windows XP نمطًا جديدًا لتسجيل كائنات COM يُسمى " COM بدون تسجيل ". تُمكّن هذه الميزة التطبيقات التي تحتاج إلى تثبيت كائنات COM من تخزين جميع معلومات سجل COM المطلوبة في دليل التطبيق نفسه، بدلاً من سجل النظام العام. وبالتالي، توفر آلية لتسجيل إصدارات متعددة من نفس مكتبة الارتباط الديناميكي (DLL) في الوقت نفسه بواسطة تطبيقات متعددة (تُطلق مايكروسوفت على هذا " التجميع جنبًا إلى جنب " ^{[ 16 ]} ). يمكن تجنب مشكلة تعارض مكتبات الارتباط الديناميكي (DLL hell) بشكل كبير باستخدام تقنية COM بدون تسجيل، مع العلم أنها تتطلب على الأقل نظام التشغيل Windows XP أو إصدارات أحدث من Windows، ويجب عدم استخدامها لخوادم EXE COM أو مكونات النظام مثل MDAC و MSXML و DirectX و Internet Explorer .
• يُتيح نظام التشغيل ، المُضمّن في Windows Me و Windows 2000 وجميع الإصدارات اللاحقة ، إمكانية تتبع تبعيات ملفات DLL، مما يُشجع على استخدام مدير الحزم ويُثني عن التثبيت اليدوي لهذه الملفات. ويوفر Windows Installer هذه الوظيفة.
• وجود قاعدة بيانات مركزية أو جهة مسؤولة عن حلّ تعارضات ملفات DLL وتوزيع البرامج. يمكن إرسال التغييرات التي تُجرى على المكتبة إلى هذه الجهة، ما يضمن الحفاظ على التوافق في الفروع المطوّرة. في حال عدم توافق برنامج قديم مع المكتبة الحالية، يمكن للجهة المسؤولة توفير واجهة توافق له، أو تضمين الإصدار القديم في حزمة منفصلة.
• إذا احتاج مطورو البرامج إلى تخصيص مكتبة، وإذا كان من غير المرجح أن يتضمن إصدار المكتبة الرئيسي التغييرات التي يحتاجونها، فيمكنهم شحن ملف DLL المخصص للاستخدام الخاص للبرنامج (عادةً عن طريق وضعه في الدليل الخاص بالبرنامج) أو ربط البرنامج بشكل ثابت بالمكتبة المخصصة.
• على الرغم من أن مكتبات الارتباط الديناميكي (DLLs) تُعدّ مثالية لتقسيم التطبيقات ومكونات النظام إلى وحدات، وكمكتبات خارجية، إلا أن استخدامها ليس ضروريًا في جميع الحالات على الأنظمة الحديثة حيث لم تعد الذاكرة عائقًا. على سبيل المثال، إذا احتاج تطبيق ما إلى مكتبة لن تُستخدم في أي مكان آخر، فيمكن ربطها بشكل ثابت، دون أي تأثير على المساحة، مع تحسين السرعة.
• يستخدم نظاما التشغيل Windows Vista والإصدارات الأحدث خدمة TrustedInstaller الخاصة لتثبيت ملفات نظام التشغيل. ولا تملك حسابات المستخدمين الأخرى، بما في ذلك حساب النظام (SYSTEM)، صلاحية الكتابة فوق الملفات الثنائية الأساسية للنظام. أما نظام Windows 7، فيوسع هذه الوظيفة لتشمل بعض الأجزاء الحيوية من سجل النظام (Registry).