Автор работы: Пользователь скрыл имя, 24 Мая 2013 в 21:12, дипломная работа
Найчастіше проект підключається до DLL статично, або неявно, на етапі компонування. Завантаженням DLL при виконанні програми управляє операційна система. Однак, DLL можна завантажити і явно, або динамічно, в ході роботи додатку.
Мета дипломної роботи розробити самостійно декілька власних DLL бібліотек у середовищі Delphi7, та показати приклади роботи з ними.
Вступ 4
1.Огляд відомих рішень 6
2. Вибір метода рішення 11
2.1 Постановка задачі 11
2.2 Обраний метод 11
3. Реалізація 21
4.Охорона праці 26
4.1 Характеристика приміщення 26
4.2 Дослідження природного освітлення 29
4.3 Дослідження штучного освітлення 33
4.4 Дослідження достатності вентиляції 35
4.5 Дослідження пожежобезпеки 38
Список Літератури 40
Зміст
Різні програми багатовіконного середовища часто виконують однакові дії, наприклад, хрестик в правому верхньому куті вікна, який закриває його, малюється більшістю програм однаково. Марнотратно було б, щоб кожна із цих програм мала відповідну функцію — це роздувало б їхні розміри. Тому, розумно, щоб такі функції поступали в спільне користування. Для цього служать бібліотеки з динамічним зв'язуванням. Відповідні функції завантажуються в пам'ять комп'ютера не з файлу програми, а із спеціального файлу, вже при виконанні. Насправді, операційна система не завантажує їх повторно. Якщо програма при запуску вимагає завантаження динамічної бібліотеки, то операційна система перевіряє, чи така бібліотека вже є в пам'яті. Якщо вона є, то операційна система збільшує лічильник клієнтів для динамічної бібліотеки на одиницю. При завершенні роботи, програма повідомляє операційну систему про необхідність вивантажити динамічну бібліотеку. При цьому операційна система зменшує лічильник клієнтів на одиницю. Якщо після такого зменшення кількість клієнтів стає рівною нулю, то тоді динамічна бібліотека справді вивантажується із пам'яті комп'ютера.
У Windows, динамічні бібліотеки зберігаються в файлах із розширенням *.DLL. Крім підпрограм там можуть також зберігатися інші ресурси, наприклад, іконки чи BMP файли. В коді програми, що використовує функції з динамічної бібліотеки, завантаження та вивантаження бібліотеки повинні бути прописані безпосередньо. Компілятору не потрібен код функцій, що містяться в динамічних бібліотеках. При запуску програми, вона, все одно, шукатиме відповідну DLL. Якщо така DLL не знайдена на комп'ютері, то програма здебільшого виконуватися не буде, а видасть повідомлення про відсутність динамічної бібліотеки.
Взагалі кажучи, DLL – це набори функцій, зібрані в бібліотеки.
Однак, на відміну від своїх статичних
родичів файлів Lib, бібліотеки
DLL не приєднані безпосередньо до виконуваних
файлів за допомогою редактора зв'язків.
У виконуваний файл занесена тільки інформація
про їхнє місцезнаходження. У момент виконання
програми завантажується вся бібліотека
цілком. Завдяки цьому різні процеси можуть
користуватися спільно одними і тими ж
бібліотеками, знаходяться в пам'яті. Такий
підхід дозволяє скоротити обсяг пам'яті,
необхідний для декількох додатків, що
використовують багато спільних бібліотек,
а також контролювати розміри ЕХЕ-файлів.
Однак, якщо бібліотека використовується тільки одним додатком, краще зробити її звичайною, статичною. Звичайно, якщо входять до її складу функції, що будуть використовуватися тільки в одній програмі, то можна вставити в неї відповідний файл з вихідним текстом.
Найчастіше проект підключається до DLL статично, або неявно, на етапі компонування. Завантаженням DLL при виконанні програми управляє операційна система. Однак, DLL можна завантажити і явно, або динамічно, в ході роботи додатку.
Мета дипломної роботи розробити самостійно декілька власних DLL бібліотек у середовищі Delphi7, та показати приклади роботи з ними.
Бібліотека динамічного компонування (DLL) є виконуваним файлом, який виконує функції загальної бібліотеки. Динамічне компонування представляє спосіб виклику функції, що не є частиною виконуваного коду. Виконуваний код функції розташований в бібліотеці DLL, яка містить кілька компільованих, пов'язаних і окремо збережених функцій у використовуваних процесах. Бібліотеки DLL часто спрощують процес загального доступу до даних і джерел. Численні програми можуть мати одночасний доступ до декількох змістів однієї копії DLL в пам'яті.
Динамічна компоновка відрізняється від статичного компонування тим, що дозволяє виконуваним модулям (таким як файл. Dll або. Exe) включати тільки необхідну інформацію в середовище виконання і розміщувати виконуваний код у функції DLL. У статичному компонуванні компонувальник отримує всі зазначені функції з бібліотеки і розміщує код в виконуваному середовищі. [1]
Динамічна компоновка має деякі переваги над статичною. Бібліотеки DLL зберігаються в пам'яті, зменшують кількість обмінів, займають невеликий об'єм місця на диску, спрощують процес оновлення, надають вторинну підтримку, а також забезпечують механізмом для розширення класів бібліотеки MFC, підтримують багатомовні програми і спрощують створення міжнародних версій.
Незважаючи на те, що бібліотеки DLL і програми є виконуваними програмними модулями, між ними існує ряд відмінностей. Для кінцевого користувача найбільш очевидною відмінністю є те, що бібліотеки DLL не є програмами і не можуть виконуватися безпосередньо. З точки зору системи існує два фундаментальних відмінності між програмами та бібліотеками DLL:
Динамічна компоновка має такі переваги:
Потенційний недолік використання бібліотек DLL полягає в тому, що програма не є самодостатньою: її виконання визначається наявністю того чи іншого бібліотечного модуля DLL.
Відмінна від MFC бібліотека DLL - це бібліотека DLL, яка внутрішньо не використовує MFC, а експортовані функції в бібліотеці DLL можуть бути викликані виконуваними файлами як MFC, так і не MFC.
Звичайна бібліотека DLL, статично компонована з MFC, - це бібліотека DLL, усередині якої використовується MFC, а експортовані функції цієї бібліотеки можуть викликатися виконуваними модулями, які можуть використовувати або не використовувати MFC. Як випливає з назви, цей тип бібліотек DLL будується за допомогою статично компонованої версії бібліотеки MFC.
Звичайна бібліотека DLL, статично компонована з MFC, має такі можливості:
Вся виділена бібліотекою
DLL пам'ять повинна
Якщо необхідно зробити що-небудь з перерахованого вище або передавати об'єкти класів, похідних від класів MFC, між викликаючим виконуваним модулем і бібліотекою DLL, то слід побудувати бібліотеку розширення.
Передавати вказівники пам'яті, виділеної бібліотеками часу виконання мови Delphi, між додатком і бібліотекою DLL безпечно тільки в тому випадку, якщо виконується копіювання даних. Не можна видаляти або змінювати розміри цих вказівників, або ж використовувати їх без копіювання пам'яті.
Бібліотеку DLL, статично скомпоновану з MFC, не можна динамічно пов'язувати з загальними бібліотеками DLL MFC. Статично пов'язана з MFC бібліотека є, як і будь-які інші DLL, динамічно пов'язаної з додатком; додаток зв'язується з нею так само, як і з будь-якої іншої DLL.
Звичайна бібліотека DLL, динамічно зв’язуюча з MFC - це бібліотека DLL, внутрішньо використовуюча MFC. Експортовані функції цієї бібліотеки можуть викликатися виконуваними програми MFC та іншими додатками. Як зрозуміло з назви, цей вид бібліотек DLL побудований з використанням версії бібліотеки динамічної компоновки MFC (також званої загальної версією MFC).
Звичайна бібліотека DLL, динамічно зв'язуюча з MFC, володіє наступними можливостями:
Побудова бібліотек DLL розширення виконується за допомогою бібліотеки динамічної компоновки версії. Тільки виконувані файли MFC, які створюються із загальною версією MFC, можуть використовувати бібліотеку DLL розширення. За допомогою бібліотеки DLL розширення можна створити нові користувальницькі класи на основі MFC і потім застосовувати цю розширену версію MFC в додатках, які викликають бібліотеку DLL.
Бібліотеки DLL розширення можуть також використовуватися для передачі об'єктів, похідних від MFC, між додатком і бібліотекою DLL. Функції-члени, асоційовані з переданим об'єктом, знаходяться в модулі, в якому об'єкт був створений. Оскільки ці функції відповідним чином експортуються при використанні загальнодоступної версії бібліотеки DLL MFC, можлива вільна передача вказівників на об'єкти MFC або вказівників на об'єкти, похідні від MFC, між додатком і бібліотеками програм, які його завантажують.
Отже, за допомогою динамічно завантажуваних бібліотек можна оптимізувати ресурси, необхідні для виконання додатків; використовувати в проектах модулі, написані на різних мовах програмування; створювати проекти, які можуть мати необов'язкові функції і пункти меню. Виклик методів з DLL не представляє труднощів, за винятком того, що слід звертати особливу увагу на виняткові ситуації: не допускати попадання примірника - нащадка Exception в головний модуль, обов'язково викликати команду FreeLibrary при наявності виключень.
Розробити власні DLL бібліотеки в середовищі Delphi7 для покращення якості коду та відповідно збільшення продуктивності програмного продукту
Для розробки були обрані наступні напрями:
Створення простої 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 + +, який також спробує очистити стек, - така дія призведе до краху стека.