DLL библиотеки

Зміст

 

Вступ

Різні програми багатовіконного середовища часто виконують однакові дії, наприклад, хрестик в правому верхньому куті вікна, який закриває його, малюється більшістю програм однаково. Марнотратно було б, щоб кожна із цих програм мала відповідну функцію — це роздувало б їхні розміри. Тому, розумно, щоб такі функції поступали в спільне користування. Для цього служать бібліотеки з динамічним зв'язуванням. Відповідні функції завантажуються в пам'ять комп'ютера не з файлу програми, а із спеціального файлу, вже при виконанні. Насправді, операційна система не завантажує їх повторно. Якщо програма при запуску вимагає завантаження динамічної бібліотеки, то операційна система перевіряє, чи така бібліотека вже є в пам'яті. Якщо вона є, то операційна система збільшує лічильник клієнтів для динамічної бібліотеки на одиницю. При завершенні роботи, програма повідомляє операційну систему про необхідність вивантажити динамічну бібліотеку. При цьому операційна система зменшує лічильник клієнтів на одиницю. Якщо після такого зменшення кількість клієнтів стає рівною нулю, то тоді динамічна бібліотека справді вивантажується із пам'яті комп'ютера.

У Windows, динамічні бібліотеки зберігаються в файлах із розширенням *.DLL. Крім підпрограм там можуть також зберігатися інші ресурси, наприклад, іконки чи BMP файли. В коді програми, що використовує функції з динамічної бібліотеки, завантаження та вивантаження бібліотеки повинні бути прописані безпосередньо. Компілятору не потрібен код функцій, що містяться в динамічних бібліотеках. При запуску програми, вона, все одно, шукатиме відповідну DLL. Якщо така DLL не знайдена на комп'ютері, то програма здебільшого виконуватися не буде, а видасть повідомлення про відсутність динамічної бібліотеки.

Взагалі кажучи, DLL – це набори функцій, зібрані в бібліотеки. 
Однак, на відміну від своїх статичних родичів файлів Lib, бібліотеки 
DLL не приєднані безпосередньо до виконуваних файлів за допомогою редактора зв'язків. У виконуваний файл занесена тільки інформація про їхнє місцезнаходження. У момент виконання програми завантажується вся бібліотека цілком. Завдяки цьому різні процеси можуть користуватися спільно одними і тими ж бібліотеками, знаходяться в пам'яті. Такий підхід дозволяє скоротити обсяг пам'яті, необхідний для декількох додатків, що використовують багато спільних бібліотек, а також контролювати розміри ЕХЕ-файлів.

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

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

Мета дипломної роботи розробити самостійно декілька власних DLL бібліотек у середовищі Delphi7, та показати приклади роботи з ними.

 

1.Огляд відомих рішень

Бібліотека динамічного  компонування (DLL) є виконуваним файлом, який виконує функції загальної  бібліотеки. Динамічне компонування представляє спосіб виклику функції, що не є частиною виконуваного коду. Виконуваний код функції розташований в бібліотеці DLL, яка містить кілька компільованих, пов'язаних і окремо збережених функцій у використовуваних процесах. Бібліотеки DLL часто спрощують процес загального доступу до даних і джерел. Численні програми можуть мати одночасний доступ до декількох змістів однієї копії DLL в пам'яті.

Динамічна компоновка відрізняється  від статичного компонування тим, що дозволяє виконуваним модулям (таким як файл. Dll або. Exe) включати тільки необхідну інформацію в середовище виконання і розміщувати виконуваний код у функції DLL. У статичному компонуванні компонувальник отримує всі зазначені функції з бібліотеки і розміщує код в виконуваному середовищі. [1]

Динамічна компоновка має  деякі переваги над статичною. Бібліотеки DLL зберігаються в пам'яті, зменшують  кількість обмінів, займають невеликий об'єм місця на диску, спрощують процес оновлення, надають вторинну підтримку, а також забезпечують механізмом для розширення класів бібліотеки MFC, підтримують багатомовні програми і спрощують створення міжнародних версій.

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

• В системі може виконуватися кілька екземплярів програми одночасно, в той час як бібліотека DLL може виконуватися тільки в одному екземплярі.
• У програмі може бути стек, глобальна пам'ять, дескриптори файлів і черга повідомлень - всього цього не може бути в бібліотеці DLL.

Динамічна компоновка має такі переваги:

• Економія пам'яті і зменшення обсягу вивантаження. Багато процесів використовують одночасно одну бібліотеку DLL - при цьому в пам'яті зберігається тільки один її примірник для всіх процесів. Для кожної програми, побудованого за допомогою статично компонованої бібліотеки, Windows, навпаки, повинна завантажити копію коду бібліотеки в пам'ять.
• Економія місця на диску. Багато додатків спільно використовують одну копію бібліотеки DLL на диску. У кожній програмі, побудованому на основі статично компонованої бібліотеки, код бібліотеки, навпаки, компонується у виконуваний образ у вигляді окремої копії.
• Оновлення бібліотек DLL простіше і зручніше. При зміні функцій в бібліотеці DLL не потрібно перекомпіляція або перекомпонування додатків, що використовують ці бібліотеки, якщо аргументи функцій і повертаються значення залишилися колишніми. Навпаки, при використанні статичної компоновки об'єктного коду потрібно перекомпонування додатка у разі зміни функцій.
• Забезпечується після продажна підтримка. Наприклад, в бібліотеку DLL для драйвера монітора можна внести зміни для підтримки монітора іншого типу, якого ще не існувало на момент поставки програми.
• Підтримка багатомовних програм. Програми, написані на різних мовах програмування, можуть викликати ту ж саму функцію бібліотеки DLL, якщо в цих програмах дотримуються єдині угоди за викликами функцій. Між програмою і функцією бібліотеки DLL повинна бути забезпечена сумісність за наступними напрямками: визначити послідовність передачі аргументів функції в стек, а також визначити, яка частина відповідає за очищення стека - функція або додаток, а також які аргументи передаються в регістри.
• Механізм розширення класів бібліотеки MFC. На основі існуючих класів MFC можна створювати похідні класи і розміщати їх в бібліотеку DLL розширення MFC для використання в додатках MFC.
• Полегшення створення міжнародних версій додатків. Створення міжнародних версій додатків набагато спрощується, якщо рядкові ресурси помістити в бібліотеку DLL. Можна розмістити рядкові ресурси кожної мовної версії вашого застосування в окрему бібліотеку ресурсів, щоб різні мовні версії завантажували відповідні ресурси.

Потенційний недолік  використання бібліотек DLL полягає  в тому, що програма не є самодостатньою: її виконання визначається наявністю того чи іншого бібліотечного модуля DLL.

Відмінна від MFC бібліотека DLL - це бібліотека DLL, яка внутрішньо не використовує MFC, а експортовані функції в бібліотеці DLL можуть бути викликані виконуваними файлами  як MFC, так і не MFC.

Звичайна бібліотека DLL, статично компонована з MFC, - це бібліотека DLL, усередині якої використовується MFC, а експортовані функції цієї бібліотеки можуть викликатися виконуваними модулями, які можуть використовувати або не використовувати MFC. Як випливає з назви, цей тип бібліотек DLL будується за допомогою статично компонованої версії бібліотеки MFC.

Звичайна бібліотека DLL, статично компонована з MFC, має  такі можливості:

• Клієнтський виконуваний модуль може бути створений будь-якою мовою, що підтримує використання бібліотек DLL (C, C + +, Pascal, Delphi і т. д.), і він не зобов'язаний бути додатком MFC.
• Бібліотека DLL може компонуватися з тими ж статичними бібліотеками MFC, що і додатки. Більше не існує окремої версії статично компонованих бібліотек, призначених спеціально для бібліотек DLL.

Вся виділена бібліотекою DLL пам'ять повинна використовуватися  тільки усередині цієї DLL. Бібліотека DLL не повинна передавати або отримувати з викликуваного виконуваного модуля наступні об'єкти:

• вказівники на об'єкти MFC;
• вказівники на пам'ять, виділену MFC.

Якщо необхідно зробити  що-небудь з перерахованого вище або  передавати об'єкти класів, похідних від класів MFC, між викликаючим виконуваним модулем і бібліотекою DLL, то слід побудувати бібліотеку розширення.

Передавати вказівники пам'яті, виділеної бібліотеками часу виконання мови Delphi, між додатком і бібліотекою DLL безпечно тільки в тому випадку, якщо виконується копіювання даних. Не можна видаляти або змінювати розміри цих вказівників, або ж використовувати їх без копіювання пам'яті.

Бібліотеку DLL, статично скомпоновану з MFC, не можна динамічно  пов'язувати з загальними бібліотеками DLL MFC. Статично пов'язана з MFC бібліотека є, як і будь-які інші DLL, динамічно  пов'язаної з додатком; додаток зв'язується з нею так само, як і з будь-якої іншої DLL.

Звичайна бібліотека DLL, динамічно зв’язуюча з MFC - це бібліотека DLL, внутрішньо використовуюча MFC. Експортовані функції цієї бібліотеки можуть викликатися виконуваними програми MFC та іншими додатками. Як зрозуміло з назви, цей вид бібліотек DLL побудований з використанням версії бібліотеки динамічної компоновки MFC (також званої загальної версією MFC).

Звичайна бібліотека DLL, динамічно зв'язуюча з MFC, володіє  наступними можливостями:

• Клієнтський виконуваний модуль може бути створений будь-якою мовою, що підтримує використання бібліотек DLL (C, C + +, Pascal, Delphi і т. д.), і він не зобов'язаний бути додатком MFC.
• На відміну від статично зв'язуваних звичайних DLL, цей вид бібліотек DLL динамічно зв'язується з DLL-бібліотекою MFC
• З цим типом бібліотеки DLL пов'язана та ж бібліотека імпорту MFC, яка використовується для DLL-бібліотек розширення або додатків, що використовують DLL-бібліотеки MFC.

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

Бібліотеки DLL розширення можуть також використовуватися  для передачі об'єктів, похідних від MFC, між додатком і бібліотекою DLL. Функції-члени, асоційовані з переданим об'єктом, знаходяться в модулі, в якому об'єкт був створений. Оскільки ці функції відповідним чином експортуються при використанні загальнодоступної версії бібліотеки DLL MFC, можлива вільна передача вказівників на об'єкти MFC або вказівників на об'єкти, похідні від MFC, між додатком і бібліотеками програм, які його завантажують.

Отже, за допомогою  динамічно завантажуваних бібліотек  можна оптимізувати ресурси, необхідні  для виконання додатків; використовувати  в проектах модулі, написані на різних мовах програмування; створювати проекти, які можуть мати необов'язкові функції і пункти меню. Виклик методів з DLL не представляє труднощів, за винятком того, що слід звертати особливу увагу на виняткові ситуації: не допускати попадання примірника - нащадка Exception в головний модуль, обов'язково викликати команду FreeLibrary при наявності виключень.

 

2. Вибір метода рішення

2.1 Постановка  задачі

Розробити власні DLL бібліотеки в середовищі Delphi7 для покращення якості коду та відповідно збільшення продуктивності програмного продукту

Для розробки були обрані наступні напрями:

• Підрахунок хеш суми MD5;
• Пошук функцій в DLL бібліотеках;
• Підтримка процесором різних технологій ;
• Числа прописом;
• Скріншот екрана;
• Шифрування й дешифрування текстів за принципом S-Coder з прихованим ключем;

2.2 Обраний метод

Створення простої DLL

library Project1;   uses   SysUtils,   Classes;   {$R *.res}   begin end.

До складу Delphi входить  експерт для створення DLL, який викликається при виборі команди File/New і піктограми DLL на сторінці New репозитарія об'єктів. При цьому виникає заготовка для реалізації DLL:

 

У наведеному вище коді відсутній  текстовий коментар, який генерується експертом. Заготовка відрізняється від заготовки для створення коду *.exe-файлу тим, що використовується службове слово Library замість Program. Крім того, відсутні звернення до методів об'єкта TApplication (хоча примірник цього об'єкта в дійсності створюється в DLL!), А також модуль реалізації головної форми. Створимо в даній заготовці метод, який буде симулювати виконання будь-яких обчислень:

function AddOne(N:integer):integer; stdcall; export;  begin    Result:=N+1;  end;

Як видно, код реалізації методу AddOne включає два оператори, які зазвичай не використовуються в реалізації методів при створенні програми, - stdcall і export. Директива stdcall пов'язана з угодами виклику методів. Розглянемо їх тут докладніше.

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

Ясно, що якщо додаток  працює нормально, то після закінчення виконання ланцюжка методів показник поточної позиції стека повинен повернутися в первісний стан, тобто створений стек повинен бути очищений. Якщо ж вказівник не повертається, то відбувається крах стека - цей термін не слід плутати з очищенням стека. У цьому випадку додаток припиняє свою роботу (ніякі пастки винятків не допомагають) і, якщо воно виконується під Windows 95 або Windows 98, найчастіше потрібне перезавантаження операційної системи. Зрозуміло, що повернення показника стека в первинний стан повинен відбуватися після закінчення роботи методу. Але при цьому існують дві можливості - повернення вказівника на місце може робити як викликуваний метод по закінченні роботи, так і викликаючий метод після завершення роботи викликуваного методу. В принципі, в різних мовах програмування реалізуються обидві зазначені можливості - очищати стек можуть і викликаний, і викликаючий методи. Оскільки модуль пишеться на одній мові програмування, то ці проблеми приховані від програміста: очищення стека проводиться по специфічному для даної мови протоколу. Але якщо використовуються різні модулі, код для яких реалізований на різних мовах програмування, то виникають проблеми. Наприклад, в C + + стек очищається в методі, який викликав другий метод, після закінчення його роботи. В Delphi стек очищається в тому ж самому методі, де він використовується, перед закінченням його роботи. Якщо *.exe-модуль, створений на мові C + +, викликає метод з DLL, створений на Delphi, то перед закінченням роботи методу в DLL стек буде очищено. Після цього управління передається модулю, реалізованому на C + +, який також спробує очистити стек, - така дія призведе до краху стека.