Shared library

A shared library is a library of executable code that is loaded in memory such that multiple executables (programs and other libraries) can use it at runtime.[1][2][3]

In contrast, a static library is copied into an executable. A static library can be re-used (a form of sharing) in multiple executables, but each executable contains a copy of the library code instead of sharing a copy in memory with other executables. Although not true today, historically, all libraries were static.[4] Although a shared library can have static linkage, such a library is not classified as a static library.

Often, a shared library is also a dynamic library loaded by a dynamic linker, which generally makes use of the library easier for the programmer than if it instead it had static linkage. A dynamic library need not be accessible to multiple executables (shared library) and a shared library need not be loaded at consumer runtime (dynamic library).

Memory sharing

Library code may be shared in memory by multiple processes and on disk. If virtual memory is used, processes would execute the same physical page of RAM mapped into the processes' different address spaces. This has advantages. For instance, on the OpenStep system, applications were often only a few hundred kilobytes in size and loaded quickly; most of their code was located in libraries already loaded for other purposes by the operating system.

Programs can accomplish RAM sharing by using position-independent code, as in Unix, which leads to a complex but flexible architecture, or by using common virtual addresses, as in Windows and OS/2. These systems ensure that code has a high probability of being shared by various means, like pre-mapping the address space and reserving slots for each shared library. A third alternative is a single-level store with a single address space, as used by the IBM System/38 and its successors. This allows position-dependent code, with programs and libraries assigned a permanent address in that address space.

في بعض الحالات، قد تتسبب الإصدارات المختلفة من المكتبات المشتركة في مشاكل، خاصةً عندما تحمل مكتبات من إصدارات مختلفة نفس اسم الملف، ويتم تثبيت تطبيقات متعددة على النظام، كل منها يتطلب إصدارًا محددًا. يُعرف هذا السيناريو باسم "جحيم DLL" ، نسبةً إلى ملفات DLL في نظامي التشغيل Windows وOS/2 . تحتوي معظم أنظمة التشغيل الحديثة بعد عام 2001 على طرق تنظيف للتخلص من هذه الحالات، أو تستخدم مكتبات "خاصة" خاصة بكل تطبيق. [ 5 ]

أمثلة

تتميز تقنيات المكتبات الشائعة الاستخدام التالية بأنها مشتركة وديناميكية بطبيعتها.

ملف DLL
يستخدم نظام التشغيل ويندوز تنسيق الملفات التنفيذية المحمولة (PE) لتقنية مكتبة الارتباط الديناميكي (DLL).
لذا
تستخدم أنظمة Solaris وأنظمة System V Release 4 الأخرى ، وأنظمة Linux ، وأنظمة BSD الحالية تنسيق Executable and Linkable Format (ELF) لتقنية الكائن المشترك (SO)، والتي تسمى أحيانًا وبشكل أدق الكائن المشترك الديناميكي (DSO).
ديليب
تستخدم أنظمة التشغيل المستندة إلى داروين ، مثل macOS و iOS ، تنسيق Mach-O لملفات .dylib .

انظر أيضاً

مراجع

  1. ليفين، جون ر. (2000). "9. المكتبات المشتركة". الروابط والمحملات . ISBN 1-55860-496-0.
  2. ↑ دليل مبرمجي نظام يونكس V / 386 الإصدار 3.2، المجلد 1 (ملف PDF) . 1989. ص 8-2 . ISBN  0-13-944877-2تمت أرشفة الملف (PDF) من النسخة الأصلية بتاريخ 2025-07-31.
  3. "المكتبات المشتركة في نظام التشغيل SunOS" (ملف PDF) . الصفحات 1، 3. مؤرشف (ملف PDF) من الأصل بتاريخ 2026-01-10. 
  4. "الفرق بين المكتبات الثابتة والمشتركة" . GeeksforGeeks . 2018-10-25 . تم الاطلاع عليه بتاريخ 2025-02-02 .
  5. أندرسون، ريك (11 يناير 2000). "نهاية جحيم ملفات DLL" . microsoft.com. مؤرشف من الأصل في 5 يونيو 2001. تم الاطلاع عليه في 15 يناير 2012. ملفات DLL الخاصة هي ملفات DLL يتم تثبيتها مع تطبيق معين وتستخدم فقط من قبل هذا التطبيق.

مصادر

  • ليفين، الابن (2000). الروابط والمحملات . سلسلة أنظمة التشغيل. إلسيفير ساينس. ISBN 978-1-55860-496-4تم الاطلاع عليه بتاريخ 2025-02-02 .