مكتبة الارتباط الديناميكي

الموسوعة الحرة

مكتبة الارتباط الديناميكي ( DLL ) هي تطبيق مايكروسوفت لمفهوم المكتبة المشتركة في أنظمة تشغيل مايكروسوفت ويندوز و OS/2 . عادةً ما تحمل هذه المكتبات امتداد الملف .dll (للمكتبات التي تحتوي على عناصر تحكم ActiveX )، أو .dll ( لبرامج تشغيل الأنظمة القديمة ). تتشابه تنسيقات ملفات DLL مع تنسيقات ملفات EXE في ويندوز ، أي ملف تنفيذي محمول (PE) لأنظمة ويندوز 32 بت و 64 بت ، وملف تنفيذي جديد (NE) لأنظمة ويندوز 16 بت . وكما هو الحال مع ملفات EXE، يمكن أن تحتوي ملفات DLL على التعليمات البرمجية والبيانات والموارد ، بأي تركيبة.DLLOCXDRV

يمكن تسمية ملفات البيانات التي لها نفس تنسيق ملف DLL، ولكن بامتدادات ملفات مختلفة، والتي قد تحتوي فقط على أقسام الموارد، بملفات DLL للموارد . ومن أمثلة هذه الملفات مكتبات الأيقونات ، التي تحمل أحيانًا الامتداد .dl ICL، وملفات الخطوط ، التي تحمل الامتدادين .dlFON و .dlFOT .

خلفية

كانت الإصدارات الأولى من مايكروسوفت ويندوز تُشغّل البرامج معًا في مساحة عنوان واحدة . وكان الهدف من كل برنامج هو التعاون فيما بينها عن طريق إتاحة وحدة المعالجة المركزية (CPU) للبرامج الأخرى، مما يسمح لواجهة المستخدم الرسومية (GUI) بأداء مهام متعددة والاستجابة بأقصى سرعة. كان نظام التشغيل الأساسي، MS-DOS ، يوفر جميع عمليات مستوى نظام التشغيل . أما الخدمات ذات المستوى الأعلى فكانت تُوفّرها مكتبات ويندوز (مكتبة الارتباط الديناميكي). تم تنفيذ واجهة برمجة تطبيقات الرسم (GDI)، وهي واجهة المستخدم في نظام DOS، ضمن مكتبة ارتباط ديناميكي (DLL) . كان لا GDI.EXEبد USER.EXEمن مشاركة هذه الطبقات الإضافية فوق نظام DOS بين جميع برامج ويندوز قيد التشغيل، ليس فقط لتمكين ويندوز من العمل على جهاز بذاكرة وصول عشوائي (RAM) أقل من ميغابايت، بل لتمكين البرامج من التعاون فيما بينها. كان على الكود الموجود في GDI ترجمة أوامر الرسم إلى عمليات على أجهزة محددة. فعلى الشاشة، كان عليه معالجة وحدات البكسل في مخزن الإطارات. وعند الرسم على طابعة، كان لا بد من تحويل استدعاءات واجهة برمجة التطبيقات إلى طلبات إلى الطابعة. على الرغم من إمكانية توفير دعم مُبرمج مسبقًا لمجموعة محدودة من الأجهزة (مثل شاشة محول الرسومات الملونة ، ولغة أوامر طابعة HP LaserJet )، إلا أن مايكروسوفت اختارت نهجًا مختلفًا. يعمل GDI عن طريق تحميل أجزاء مختلفة من التعليمات البرمجية، تُسمى " برامج تشغيل الأجهزة "، للعمل مع أجهزة إخراج مختلفة.

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

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

في الإصدارات الأولى من نظام التشغيل ويندوز (من 1.0 إلى 3.11)، كانت ملفات DLL هي الأساس لواجهة المستخدم الرسومية بأكملها. ولذلك، كانت برامج تشغيل الشاشة مجرد ملفات DLL بامتداد .DRV، توفر تطبيقات مخصصة لواجهة برمجة تطبيقات الرسم نفسها من خلال واجهة برنامج تشغيل جهاز موحدة (DDI). أما واجهات برمجة تطبيقات الرسم (GDI) وواجهة المستخدم الرسومية (USER) فكانت مجرد استدعاءات للدوال التي تصدرها ملفات DLL النظامية GDI وUSER بامتداد .EXE.

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

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

في أنظمة ويندوز 1.x و2.x و3.x، كانت جميع تطبيقات ويندوز تتشارك نفس مساحة العناوين ونفس الذاكرة. وكان يتم تحميل مكتبة الارتباط الديناميكي (DLL) مرة واحدة فقط في مساحة العناوين هذه؛ ومنذ ذلك الحين، كانت جميع البرامج التي تستخدم المكتبة تصل إليها. وكانت بيانات المكتبة مشتركة بين جميع البرامج. وقد يُستخدم هذا كشكل غير مباشر من أشكال التواصل بين العمليات ، أو قد يؤدي عن غير قصد إلى تلف البرامج المختلفة. مع إدخال مكتبات 32 بت في ويندوز 95 ، أصبحت كل عملية تعمل في مساحة عناوين خاصة بها. وبينما يمكن مشاركة كود مكتبة الارتباط الديناميكي، تظل البيانات خاصة إلا إذا طلبت المكتبة صراحةً بيانات مشتركة. ومع ذلك، فقد بُنيت أجزاء كبيرة من ويندوز 95 وويندوز 98 وويندوز Me باستخدام مكتبات 16 بت، مما حدّ من أداء معالج بنتيوم برو عند التشغيل، وبالتالي حدّ من استقرار وقابلية التوسع لإصدارات ويندوز المستندة إلى نظام DOS.

على الرغم من أن ملفات DLL تُعدّ جوهر بنية نظام ويندوز، إلا أنها تعاني من عدة عيوب، تُعرف مجتمعةً باسم " جحيم ملفات DLL ". [ 2 ] اعتبارًا من عام 2015تروّج مايكروسوفت لإطار عمل .NET كأحد حلول مشكلة تداخل مكتبات الارتباط الديناميكي (DLL)، مع أنها تروج حاليًا لحلول تعتمد على المحاكاة الافتراضية مثل Microsoft Virtual PC و Microsoft Application Virtualization ، نظرًا لما توفره من عزل أفضل بين التطبيقات. ويُعدّ تطبيق التجميع جنبًا إلى جنب حلاً بديلاً للتخفيف من مشكلة تداخل مكتبات الارتباط الديناميكي .

سمات

بما أن ملفات DLL هي في الأساس نفس ملفات EXE، فإن اختيار أي منهما يتم إنتاجه كجزء من عملية الربط هو من أجل الوضوح، حيث أنه من الممكن تصدير الوظائف والبيانات من أي منهما.

لا يمكن تنفيذ ملف DLL بشكل مباشر، لأنه يتطلب ملف EXE ليقوم نظام التشغيل بتحميله من خلال نقطة دخول ، ومن هنا تأتي الحاجة إلى أدوات مساعدة مثل RUNDLL.EXE أو RUNDLL32.EXE التي توفر نقطة الدخول والإطار الأدنى لملفات DLL التي تحتوي على وظائف كافية للتنفيذ دون الحاجة إلى الكثير من الدعم.

توفر مكتبات الارتباط الديناميكي (DLLs) آليةً لتبادل التعليمات البرمجية والبيانات، مما يسمح لمطوري هذه المكتبات بترقية وظائفها دون الحاجة إلى إعادة ربط التطبيقات أو إعادة تجميعها. من وجهة نظر تطوير التطبيقات، يمكن اعتبار نظامي التشغيل Windows وOS/2 مجموعةً من مكتبات الارتباط الديناميكي التي يتم ترقيتها، مما يسمح لتطبيقات إصدار معين من نظام التشغيل بالعمل على إصدار أحدث، شريطة أن يضمن مُصنِّع نظام التشغيل توافق الواجهات والوظائف.

يتم تنفيذ ملفات DLL في مساحة الذاكرة الخاصة بالعملية المستدعِية وبنفس أذونات الوصول، مما يعني وجود حمل زائد ضئيل في استخدامها، ولكن هذا يعني أيضًا عدم وجود حماية للبرنامج المستدعي إذا كان ملف DLL يحتوي على أي نوع من الأخطاء.

إدارة الذاكرة

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

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

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

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

مكتبات الاستيراد

كما هو الحال مع المكتبات الثابتة، تُعرف مكتبات الاستيراد لملفات DLL .libبامتداد الملف. على سبيل المثال، يتم ربط kernel32.dll ، وهي المكتبة الديناميكية الأساسية لوظائف نظام التشغيل Windows الأساسية مثل إنشاء الملفات وإدارة الذاكرة، عبر امتداد .dll kernel32.lib. والطريقة المعتادة للتمييز بين مكتبة الاستيراد والمكتبة الثابتة هي الحجم: فمكتبة الاستيراد أصغر بكثير لأنها تحتوي فقط على رموز تشير إلى ملف DLL الفعلي، الذي تتم معالجته أثناء الربط. ومع ذلك، فإن كليهما ملفات بتنسيق ar الخاص بنظام Unix .

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

في Cygwin/MSYS وMinGW، تُعطى مكتبات الاستيراد عادةً اللاحقة . .dll.a، التي تجمع بين لاحقة DLL الخاصة بنظام Windows ولاحقة ar الخاصة بنظام Unix. يتشابه تنسيق الملف، لكن الرموز المستخدمة لتمييز الاستيرادات مختلفة ( _head_foo_dllمقابل __IMPORT_DESCRIPTOR_foo). [ 4 ] على الرغم من أن مجموعة أدوات GNU Binutils الخاصة بها قادرة على إنشاء مكتبات استيراد وربطها، إلا أن الربط المباشر بملف DLL أسرع. [ 5 ] يمكن استخدام أداة تجريبية في MinGW تُسمى genlib لإنشاء مكتبات استيراد برموز على نمط MSVC.

حل الرموز وربطها

تُعرَّف كل دالة مُصدَّرة من مكتبة الارتباط الديناميكي (DLL) برقم ترتيبي، واسم اختياري. وبالمثل، يمكن استيراد الدوال من مكتبة الارتباط الديناميكي إما بالرقم الترتيبي أو بالاسم. يُمثِّل الرقم الترتيبي موضع مؤشر عنوان الدالة في جدول عناوين التصدير الخاص بمكتبة الارتباط الديناميكي. من الشائع تصدير الدوال الداخلية بالرقم الترتيبي فقط. بالنسبة لمعظم دوال واجهة برمجة تطبيقات ويندوز (Windows API)، تُحفظ الأسماء فقط عبر إصدارات ويندوز المختلفة، بينما تخضع الأرقام الترتيبية للتغيير. لذا، لا يمكن استيراد دوال واجهة برمجة تطبيقات ويندوز بشكل موثوق باستخدام أرقامها الترتيبية.

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

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

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

الربط الصريح في وقت التشغيل

يمكن تحميل ملفات DLL بشكل صريح أثناء التشغيل، وهي عملية تُعرف ببساطة باسم الربط الديناميكي أثناء التشغيل من قِبل مايكروسوفت، وذلك باستخدام دالة API LoadLibrary(أو LoadLibraryEx). GetProcAddressتُستخدم دالة API للبحث عن الرموز المُصدَّرة بالاسم، بينما FreeLibraryتُستخدم دالة أخرى لإلغاء تحميل ملف DLL. تُشابه هذه الدوال دوال dlopenو dlsymو dlcloseفي واجهة برمجة تطبيقات POSIX القياسية.

إن إجراء الربط الصريح في وقت التشغيل هو نفسه في أي لغة تدعم المؤشرات إلى الدوال ، لأنه يعتمد على واجهة برمجة تطبيقات Windows بدلاً من بنيات اللغة.

تأخر التحميل

في الوضع الطبيعي، يفشل تشغيل أي تطبيق مرتبط بمكتبة استيراد DLL إذا تعذر العثور على DLL، لأن نظام التشغيل Windows لا يُشغّل التطبيق إلا بعد العثور على جميع ملفات DLL التي قد يحتاجها. مع ذلك، يمكن ربط التطبيق بمكتبة استيراد للسماح بتحميل المكتبة الديناميكية لاحقًا. [ 6 ] في هذه الحالة، لا يحاول نظام التشغيل البحث عن DLL أو تحميله عند بدء تشغيل التطبيق؛ بل يُضمّن الرابط في التطبيق دالة وسيطة (stub) تحاول البحث عن DLL وتحميله عند استدعاء إحدى وظائفها. إذا تعذر العثور على DLL أو تحميله، LoadLibraryأو GetProcAddressإذا كانت الوظيفة المستدعاة غير موجودة، فسيُصدر التطبيق استثناءً ، والذي يمكن التقاطه ومعالجته بشكل مناسب. إذا لم يعالج التطبيق الاستثناء، فسيلتقطه نظام التشغيل، الذي سيُنهي البرنامج مع عرض رسالة خطأ.

كما توفر آلية التحميل المؤجل خطافات الإشعارات ، مما يسمح للتطبيق بإجراء معالجة إضافية أو معالجة الأخطاء عند تحميل ملف DLL و/أو استدعاء أي وظيفة من وظائف DLL.

اعتبارات المترجم واللغة

دلفي

في ملف المصدر، libraryتُستخدم الكلمة المفتاحية بدلاً من program. وفي نهاية الملف، تُدرج الدوال المراد تصديرها في exportsعبارة .

لا يحتاج دلفيLIB إلى ملفات لاستيراد الوظائف من مكتبات الارتباط الديناميكي (DLLs)؛ للربط بمكتبة ارتباط ديناميكي، externalيتم استخدام الكلمة الرئيسية في تعريف الوظيفة للإشارة إلى اسم مكتبة الارتباط الديناميكي، متبوعة nameبتسمية الرمز (إذا كان مختلفًا) أو indexلتحديد الفهرس.

مايكروسوفت فيجوال بيسك

في لغة Visual Basic (VB)، يتم دعم الربط في وقت التشغيل فقط؛ ولكن بالإضافة إلى استخدام وظائف API، LoadLibraryيُسمح بتصريحات الوظائف المستوردة .GetProcAddress

عند استيراد دوال DLL عبر التصريحات، سيُصدر VB خطأً أثناء التشغيل إذا DLLلم يتم العثور على الملف. يمكن للمطور رصد الخطأ ومعالجته بالشكل المناسب.

عند إنشاء مكتبات DLL في VB، لا تسمح بيئة التطوير المتكاملة (IDE) إلا بإنشاء مكتبات ActiveX DLL، ولكن تم تطوير طرق [ 7 ] تُمكّن المستخدم من توجيه الرابط صراحةً لتضمين ملف .DEF الذي يُحدد الترتيب والاسم لكل دالة مُصدّرة. يُمكّن هذا المستخدم من إنشاء مكتبة DLL قياسية لنظام Windows باستخدام Visual Basic (الإصدار 6 أو أقدم) والتي يُمكن الرجوع إليها من خلال عبارة "Declare".

لغة C ولغة C++

توفر Microsoft Visual C++ (MSVC) العديد من الإضافات للغة C++ القياسية ، والتي تسمح بتحديد الدوال كمستوردة أو مُصدَّرة مباشرةً في كود C++؛ وقد اعتمدتها مُجمِّعات C وC++ الأخرى لنظام Windows، بما في ذلك إصدارات Windows من GCC . تستخدم هذه الإضافات السمة __declspecقبل تعريف الدالة. تجدر الإشارة إلى أنه عند الوصول إلى دوال C من C++، يجب تعريفها أيضًا extern "C"في كود C++، لإعلام المُجمِّع بضرورة استخدام الربط الخاص بلغة C. [ 8 ]

إلى جانب تحديد الدوال المستوردة أو المصدرة باستخدام __declspecالسمات، يمكن إدراجها في قسمي IMPORT أو EXPORTS من DEFالملف المستخدم في المشروع. DEFتتم معالجة هذا الملف بواسطة الرابط، وليس المترجم، وبالتالي فهو ليس خاصًا بلغة C++.

ينتج عن تجميع مكتبة الارتباط الديناميكي (DLL) DLLملفان LIB: `. LIBيُستخدم ملف `..` (مكتبة الاستيراد) للربط مع مكتبة الارتباط الديناميكي أثناء التجميع؛ وهو غير ضروري للربط أثناء التشغيل. ما لم تكن مكتبة الارتباط الديناميكي خادمًا لنموذج كائنات المكونات (COM)، DLLيجب وضع ملف `..` في أحد الدلائل المدرجة في متغير بيئة PATH، أو في دليل النظام الافتراضي، أو في نفس دليل البرنامج الذي يستخدمه. تُسجل مكتبات الارتباط الديناميكي لخادم COM باستخدام regsvr32.exe، الذي يضع موقع مكتبة الارتباط الديناميكي ومعرّفها الفريد عالميًا ( GUID ) في سجل النظام. يمكن للبرامج بعد ذلك استخدام مكتبة الارتباط الديناميكي من خلال البحث عن معرّفها الفريد عالميًا في سجل النظام للعثور على موقعها، أو إنشاء نسخة من كائن COM بشكل غير مباشر باستخدام معرّف فئتها ومعرّف واجهتها.

أمثلة برمجية

استخدام استيراد ملفات DLL

توضح الأمثلة التالية كيفية استخدام روابط خاصة باللغة لاستيراد الرموز للربط مع مكتبة الارتباط الديناميكي (DLL) في وقت الترجمة.

دلفي

{$APPTYPE CONSOLE}مثال على البرنامج ؛// استيراد دالة جمع عددين function AddNumbers ( a , b : Double ) : Double ; StdCall ; external 'Example.dll' ;// البرنامج الرئيسي var R : Double ;begin R := AddNumbers ( 1 , 2 ) ; Writeln ( 'النتيجة كانت: ' , R ) ; end .

ج

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

#include <windows.h> #include <stdio.h>// دالة الاستيراد التي تجمع رقمين extern "C" __declspec ( dllimport ) double AddNumbers ( double a , double b );int main ( int argc , char * argv []) { double result = AddNumbers ( 1 , 2 ); printf ( "النتيجة هي: %f \n " , result ); return 0 ; }

استخدام الربط الصريح في وقت التشغيل

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

لاحظ أن جميع العينات الأربع عرضة لهجمات التحميل المسبق لملفات DLL ، حيث يمكن توجيه ملف example.dll إلى موقع غير مقصود من قِبل المُنشئ (يسبق دليل العمل الحالي مواقع مكتبات النظام)، وبالتالي إلى نسخة خبيثة من المكتبة. راجع المرجع للاطلاع على إرشادات مايكروسوفت بشأن التحميل الآمن للمكتبات: ينبغي استخدام الأمر SetDllDirectoryWin kernel32لإزالة البحث في الدليل الحالي قبل تحميل أي مكتبات. [ 9 ]

مايكروسوفت فيجوال بيسك

Option Explicit Declare Function AddNumbers Lib "Example.dll" _ ( ByVal a As Double , ByVal b As Double ) As DoubleSub Main ( ) Dim Result As Double Result = AddNumbers ( 1 , 2 ) Debug.Print "النتيجة هي: " & Result End Sub

دلفي

مثال البرنامج ؛ {$APPTYPE CONSOLE} يستخدم Windows ؛ var AddNumbers : function ( a , b : integer ) : Double ; StdCall ; LibHandle : HMODULE ; begin LibHandle := LoadLibrary ( 'example.dll' ) ; if LibHandle <> 0 then AddNumbers := GetProcAddress ( LibHandle , 'AddNumbers' ) ; if Assigned ( AddNumbers ) then Writeln ( '1 + 2 = ' , AddNumbers ( 1 , 2 ) ) ; Readln ; end .

ج

#include <windows.h> #include <stdio.h>// توقيع دالة DLL typedef double ( * importFunction )( double , double );int main ( int argc , char ** argv ) { importFunction addNumbers ; double result ; HINSTANCE hinstLib ;// تحميل ملف DLL hinstLib = LoadLibrary ( TEXT ( "Example.dll" )); if ( hinstLib == NULL ) { printf ( "خطأ: تعذر تحميل ملف DLL \n " ); return 1 ; }// الحصول على مؤشر الدالة addNumbers = ( importFunction ) GetProcAddress ( hinstLib , "AddNumbers" ); if ( addNumbers == NULL ) { printf ( "خطأ: تعذر العثور على دالة DLL \n " ); FreeLibrary ( hinstLib ); return 1 ; }// استدعاء الدالة. النتيجة = إضافة الأرقام ( 1 ، 3 )؛// إلغاء تحميل ملف DLL FreeLibrary ( hinstLib );// عرض النتيجة printf ( "النتيجة كانت: %f \n " , result );return 0 ; }

بايثون

سيستخدم ربط Python ctypes واجهة برمجة تطبيقات POSIX على أنظمة POSIX.

استيراد ctypesmy_dll = ctypes . سي دلل . مكتبة التحميل ( "Example.dll" )# يلزم تحديد نوع البيانات المُعادة من الدالة باستخدام تعريف الدالة "restype" التالي. # لكي يفهم بايثون نوع البيانات التي تُعيدها الدالة. my_dll.AddNumbers.restype = ctypes.c_doublep = my_dll.AddNumbers ( ctypes.c_double ( 1.0 ) , ctypes.c_double ( 2.0 ) )​​​​print ( "كانت النتيجة:" , p )

نموذج كائن المكون

يُعرّف نموذج كائنات المكونات (COM) معيارًا ثنائيًا لاستضافة تنفيذ الكائنات في ملفات DLL وEXE. ويوفر آليات لتحديد مواقع هذه الملفات وإصداراتها، بالإضافة إلى وصف للواجهة مستقل عن اللغة وقابل للقراءة آليًا. تُعد استضافة كائنات COM في ملف DLL أخف وزنًا، وتسمح لها بمشاركة الموارد مع عملية العميل. وهذا يُمكّن كائنات COM من تنفيذ واجهات خلفية قوية لواجهات المستخدم الرسومية البسيطة مثل Visual Basic وASP. كما يُمكن برمجتها باستخدام لغات البرمجة النصية. [ 10 ]

اختطاف ملفات DLL

بسبب ثغرة أمنية تُعرف باسم اختطاف مكتبات الارتباط الديناميكي (DLL)، أو انتحالها، أو تحميلها المسبق، أو زرع الملفات الثنائية، تقوم العديد من البرامج بتحميل وتنفيذ مكتبة ارتباط ديناميكي خبيثة موجودة في نفس مجلد ملف البيانات الذي تفتحه هذه البرامج. [ 11 ] [ 12 ] [ 13 ] [ 14 ] اكتشف جورجي غونينسكي هذه الثغرة عام 2000. [ 15 ] وفي أغسطس 2010، حظيت باهتمام عالمي واسع بعد أن أعادت شركة ACROS Security اكتشافها، حيث وُجدت مئات البرامج عرضة لهذه الثغرة. [ 16 ] البرامج التي تُشغّل من مواقع غير آمنة، مثل المجلدات التي يمكن للمستخدم الكتابة فيها، كمجلد التنزيلات أو مجلد الملفات المؤقتة ، تكون دائمًا عرضة لهذه الثغرة. [ 17 ] [ 18 ] [ 19 ] [ 20 ] [ 21 ] [ 22 ] [ 23 ]

انظر أيضاً

مراجع

  1. ↑ شركة مايكروسوفت. "إنشاء ملف DLL للموارد فقط" . مكتبة شبكة مطوري مايكروسوفت .
  2. ↑ "نهاية جحيم ملفات DLL" . شركة مايكروسوفت. مؤرشف من الأصل بتاريخ 6 مايو 2008. تم الاطلاع عليه بتاريخ 11 يوليو 2009 .
  3. ↑ "فهم جدول عناوين الاستيراد" .
  4. ↑ "بناء واستخدام مكتبات DLL" . مكتبة الاستيراد هي مكتبة عادية بامتداد .a تشبه مكتبات أنظمة UNIX، لكنها لا تحتوي إلا على جزء صغير من المعلومات اللازمة لإخبار نظام التشغيل بكيفية تفاعل البرنامج مع مكتبة DLL ("استيرادها"). يتم ربط هذه المعلومات بملف .exe.
  5. ↑ "ld و WIN32" . وثائق ld .
  6. ↑ "دعم الرابط لملفات DLL المحملة بتأخير" . شركة مايكروسوفت . تم الاسترجاع في 11 يوليو 2009 .
  7. ↑ بتروشا، رون (26 أبريل 2005). "إنشاء مكتبة ارتباط ديناميكي لنظام ويندوز باستخدام فيجوال بيسك" . دار نشر أورايلي ميديا . تم الاطلاع عليه بتاريخ 11 يوليو 2009 .
  8. ↑ MSDN ، استخدام extern لتحديد الارتباط
  9. ↑ "تحميل المكتبات بشكل آمن لمنع هجمات التحميل المسبق لملفات DLL" . دعم مايكروسوفت . تم الاطلاع عليه بتاريخ 28 أكتوبر 2019 .
  10. ↑ ساتران، مايكل. "نموذج كائن المكون (COM)" . msdn.microsoft.com .
  11. ↑ انتحال ملفات DLL في نظام التشغيل ويندوز
  12. ↑ "هجمات التحميل المسبق لملفات DLL" . msdn.com . تم الاطلاع عليه بتاريخ 25 مارس 2018 .
  13. ↑ "مزيد من المعلومات حول ثغرة التحميل المسبق لملفات DLL عن بُعد" . technet.com . تم الاطلاع عليه بتاريخ 25 مارس 2018 .
  14. ↑ "تحديث حول أسلوب الهجوم عن بُعد عبر التحميل المسبق لملفات DLL" . technet.com . تم الاطلاع عليه بتاريخ 25 مارس 2018 .
  15. ↑ "قد يؤدي النقر المزدوج على مستندات مايكروسوفت أوفيس من مستكشف ويندوز إلى تشغيل برامج عشوائية في بعض الحالات" . www.guninski.com . تاريخ الاطلاع: 25 مارس 2018 .
  16. ↑ "Binary Planting - الموقع الرسمي لثغرة أمنية منسية. ACROS Security" . www.binaryplanting.com . تاريخ الاطلاع: 25 مارس 2018 .
  17. ↑ القصف الجوي المكثف وتسميم الدليل
  18. ↑ "مطور إلى موزيلا: يرجى التخلص من عمليات تثبيت ويندوز القديمة" . theregister.co.uk . تم الاطلاع عليه بتاريخ 25 مارس 2018 .
  19. ↑ "Gpg4win - إشعار أمني Gpg4win 2015-11-25" . www.gpg4win.org . تم الاطلاع عليه بتاريخ 25 مارس 2018 .
  20. ↑ "قاعدة معارف مكافي - نشرة مكافي الأمنية: رقعة أمنية لعدد من برامج تثبيت وإزالة تثبيت مكافي (CVE-2015-8991، CVE-2015-8992، وCVE-2015-8993) (TS102462)" . service.mcafee.com . تم الاطلاع عليه بتاريخ 25 مارس 2018 .
  21. ↑ "fsc-2015-4 - مختبرات إف-سكيور" . www.f-secure.com . مؤرشف من الأصل بتاريخ 31 يوليو 2017. تم الاطلاع عليه بتاريخ 25 مارس 2018 .
  22. ↑ "ثغرة أمنية في برنامج ScanNow DLL Search Order Hijacking وإيقاف دعمه" . rapid7.com . 21 ديسمبر 2015. تم الاطلاع عليه بتاريخ 25 مارس 2018 .
  23. ↑ فريق VeraCrypt. "oss-sec: CVE-2016-1281: تسمح برامج تثبيت TrueCrypt وVeraCrypt لنظام Windows بتنفيذ تعليمات برمجية عشوائية مع رفع مستوى الامتيازات" . seclists.org . تم الاطلاع عليه بتاريخ 25 مارس 2018 .
  • هارت، جونسون. برمجة أنظمة ويندوز، الطبعة الثالثة . أديسون-ويسلي، 2005. ISBN 0-321-25619-0.
  • ريكتور، برنت وآخرون. برمجة Win32 . دار نشر أديسون-ويسلي للمطورين، 1997. ISBN 0-201-63492-9.