Файли DLL та LIB - що і чому?


214

Я знаю дуже мало про DLL та LIB, крім того, що вони містять життєвий код, необхідний для належної роботи програми - бібліотеки. Але чому компілятори взагалі генерують їх? Чи не було б простіше просто включити весь код в один виконуваний файл? І яка різниця між DLL та LIB?


Відповіді:


298

Існують статичні бібліотеки (LIB) та динамічні бібліотеки (DLL) - але зауважте, що .LIB-файли можуть бути або статичними бібліотеками (містять об’єктні файли), або імпортними бібліотеками (містять символи, що дозволяють лінкеру зв’язатися з DLL).

Бібліотеки використовуються, оскільки у вас може бути код, який ви хочете використовувати в багатьох програмах. Наприклад, якщо ви пишете функцію, яка рахує кількість символів у рядку, ця функція буде корисною для багатьох програм. Після правильної роботи цієї функції вам не потрібно буде перекопіювати код кожен раз, коли ви його використовуєте, тому ви ставите виконуваний код для цієї функції в бібліотеку, і лінкер може витягнути і вставити скомпільований код у вашу програму . З цієї причини статичні бібліотеки іноді називають "архівами".

Динамічні бібліотеки роблять це на крок далі. Дуже марно мати кілька копій функцій бібліотеки, які займають місце в кожній з програм. Чому вони не можуть спільно використовувати одну копію функції? Це те, для чого створені динамічні бібліотеки. Замість того, щоб створювати код бібліотеки у вашій програмі під час її складання, її можна запустити, зіставивши її у вашу програму під час завантаження в пам'ять. Кілька програм, що працюють одночасно, які використовують одні і ті ж функції, можуть спільно використовувати одну копію, економлячи пам'ять. Насправді, ви можете завантажувати динамічні бібліотеки лише за потреби, залежно від шляху через ваш код. Немає сенсу в тому, щоб принтер розпоряджався пам'яттю, якщо ви не робите жодної друку. З іншого боку, це означає, що ви повинні мати копію динамічної бібліотеки, встановленої на кожній машині, на якій працює ваша програма.

Наприклад, майже для кожної програми, написаної на "C", знадобляться функції з бібліотеки під назвою "Бібліотека часу виконання C", хоча для декількох програм знадобляться всі функції. Час виконання C буває як у статичній, так і в динамічній версіях, тому ви можете визначити, яку версію використовує ваша програма залежно від конкретних потреб.


81
Виявляється, що .LIBфайлами можуть бути або статичні бібліотеки (містять об’єктні файли), або імпортуючі бібліотеки (містять символи, що дозволяють лінкеру зв’язатися з DLL). Мені цікаво, чому це так.
Лумі

2
гарне пояснення! Код є спільним, а дані (за замовчуванням) не поділяються між додатками, що споживають Dll.
mox

4
@Lumi: Добре. З точки зору DLL, у нас є два типи зв'язків. Неявне посилання , коли у нас є .libфайл, наданий творцем DLL разом із відповідними заголовками; це .libлише дескриптор цільової DLL, він містить адреси, точку входу тощо, але немає коду. Це .libпотрібно передати лінкеру. Другий - це явне посилання, коли ми використовуємо DLL, вручну завантажуючи його LoadLibraryфункцією. Цей тип нам не потрібен цей .libфайл, але ми повинні докласти трохи зусиль, щоб знайти експорт DLL, їх адреси та викликати ці функції за допомогою покажчиків.
Ітачі

37

Інший аспект - безпека (затуплення). Після того, як фрагмент коду буде вилучено з основної програми та поміщений у "відокремлену" бібліотеку Dynamic-Link, простіше атакувати, аналізувати (реверсивний) код, оскільки він був ізольований. Коли той самий фрагмент коду зберігається в бібліотеці LIB, він є частиною складеної (пов'язаної) цільової програми, і, таким чином, важче відокремити (диференціювати) цей фрагмент коду від решти цільових бінарних файлів.


Аспект безпеки був для мене новим. Чи справджуються вищенаведені міркування у випадку, коли додаток C # викликає вбудований керований d + C ++?
Мартін

1
Але LIB теж ізольований, чи не так? Таким чином, Зловмисник може просто проаналізувати LIB. Або це загальний сценарій, коли LIB не є доступним для населення?
Нік Расслер

8
LIB також "ізольований", що стосується процесу компіляції, але як тільки лінкер, як складені частини, LIB є частиною EXE і його неможливо відрізнити від вашого власного коду.
mox

17

Однією з важливих причин створення DLL / LIB, а не просто компіляція коду у виконуваний файл, є повторне використання та переміщення. Середній додаток Java або .NET (наприклад), швидше за все, використовуватиме декілька сторонніх (або фреймворкових) бібліотек. Набагато простіше і швидше просто компілювати проти заздалегідь створеної бібліотеки, а не потрібно збирати весь код сторонніх програм у вашу програму. Компіляція вашого коду в бібліотеки також заохочує добрі дизайнерські практики, наприклад проектування класів для використання в різних типах програм.


7

DLL - це бібліотека функцій, які спільно використовуються серед інших виконуваних програм. Просто загляньте у свій каталог windows / system32, і ви знайдете їх десятки. Коли ваша програма створює DLL, вона також зазвичай створює файл lib, щоб програма * .exe програма могла вирішувати символи, оголошені в DLL.

.Lib - це бібліотека функцій, статично пов'язаних з програмою - їх НЕ поділяють інші програми. Кожна програма, яка посилається на файл * .lib, має весь код у цьому файлі. Якщо у вас є дві програми A.exe і B.exe, які пов'язують C.lib, то обидва A і B будуть містити код у C.lib.

Спосіб створення DLL та libs залежить від компілятора, який ви використовуєте. Кожен компілятор робить це по-різному.


4

Ще одна відмінність полягає у виконанні.

Оскільки DLL завантажується під час виконання за допомогою .exe (s), .exe (і) та DLL працюють із концепцією спільної пам'яті, а отже, продуктивність низька відносно статичного зв’язку.

З іншого боку, .lib - це код, який статично пов'язаний під час компіляції у кожен процес, який запитує. Отже, .exe (и) матимуть єдину пам'ять, тим самим збільшуючи продуктивність процесу.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.