Программеры всех стран уже более 30 лет борются с проблемой многоразового использования однажды написанного кода. Так уж повелось, что в 30-50% кода в простых офисных приложениях схожи между собой или решают одни и те же задачи. Ни один программер не захочет каждый раз снова кодить одно и то же. Как хорошо, когда можно использовать один раз написанный код многократно ....

Я сам не люблю в каждой новой проге писать одно и то же. Как хорошо, когда написал какой-то универсальный код, а потом только используешь его.

Самым первым решением этой проблемы стал модульный кодинг. Ты пишешь какой-то кусок кода, оформляешь его в виде модуля, а потом просто используешь его в своих прогах. Все прекрасно и удобно, а главное, что все довольны. Теперь не надо каждый раз выдумывать велосипед, просто добавил к своей проге определенный модуль и без проблем используй код когда-то написанный тобой или кем-то другим.

Казалось, что это было самое простое и самое эффективное решение. Но все было прекрасно, пока не появилась многозадачность. Вот тут программеры заметили, что еще не все так эффективно и полно места, куда можно приложить свои ручонки.

Давай представим ситуацию, когда один добрый чел написал прекрасный модуль размером 1 метр. Другой добрый чел решил воспользоваться его возможностями и подключил к своей проге. Модуль и прога слились в одно целое. Вроде все нормально, но я же сказал, что прога и модуль слились в одно целое. Это значит, что размер проги увеличился на размер модуля, т.е. на 1 мег. Не фига себе пельмень :). А теперь представь, что другой чел написал другую утилу с использованием этого модуля.... Его прога тоже увеличилась на 1 мег. Получается, что на винте пользователя хранится две проги, в которых по 1 мегу кода одинаковых. И кому это нужно?

Ну конечно же на счет модуля в 1 мег я загнул. В те времена даже 100 кило модуль тяжело было найти. Но надо учитывать, что и винты тогда были не бесконечные. Тогда крутым винтом считался диск в 20 метров. Это тебе не нынешние десятки гига на одной пластине. Возможно, ты тогда еще под стол ходил. Я сам застал такие машины только на первом курсе института, а это было лет 8 назад.

Пока существовали только однозадачные ОСи, проблема с излишней растратой дискового пространства была единственной. Но как только задумались о многозадачности и в мыслях Гейтса появились идеи создать Windows (будь проклят тот день:)), так сразу возникла другая проблема.... Представь себе ситуацию, когда ты запускаешь обе этих проги одновременно. При старте любая прога грузится в оперативку и только потом выполняется. Так что получается, что обе проги загрузят в оперативку один и тот же код. Вот это уже абсолютно никому не нужно.

Это этим летом память подешевела в несколько раз, и теперь лишние сто кило погоды не сделают. А раньше она стоила достаточно дорого, и люди боролись за каждый байтик потом и кровью. Но если ты думаешь, что если поставить в свою тачку 500 мегов мозгов и проблема ушла сама собой, то ты крупно ошибаешься.

Хотя память и дешевая, проги от этого меньше не станут. Если посмотреть на запросы той же Windows 2000, то сразу хочется взять зонтик, вставить его Билу в задний проход и раскрыть :). Это че он там такое натворил, что Windows 2000 Server просит для нормальной работы минимум 256 мегов? А если учесть, что современные чипсеты не поддерживают памяти более 512 мегов, то о нормальной одновременной работе Windows 2000 Server + 3D Studio Max + MPEG4 можно забыть. Они всю память сожрут как термиты за пять сек.

И вот тут было найдено вполне солидное решение: не стыковать модули с основной прогой, а сохранять их в отдельный файл и пусть любая прога загружает его по мере надобности. Ляпнул, отвечай за базар. Так появились библиотеки DLL, что означает Dynamic Link Library. Это библиотеки, которые подключаются к программе динамически. В них можно хранить исполняемый код в виде процедур или функций, ресурсы проги, графику или даже видеоролики.

Вот так. Теперь прога не увеличивалась на размер модуля при компиляции, а просто загружала код из DLL файла в память и использовала его. Если одна прога уже загрузила DLL, то следующая прога не будет уже делать этого. Она воспользуется уже загруженной версией. Таким образом, экономится не только диск, но и оперативка, которой, как и денег, много не бывает.

Сейчас уже DLL - это не просто динамически подгружаемая библиотека. Ты наверно уже не раз слышал про компоненты ActiveX. Они так же могут быть выполнены в виде ocx или dll файлов. Да оно и понятно, ActiveX используются сейчас достаточно много и весят они в несколько раз больше чем самая большая DLL библиотека. Так что единственный и нормальный выход экономить место винта и памяти это засунуть ActiveX в динамически подгружаемую библиотеку. Хотя это уже не та DLL, но всё же работает по тем же принципам.

У динамических библиотек есть единственный недостаток - на ее загрузку тратится лишнее время. Зато если библиотека уже загружена другой прогой, то она появляется намного быстрей. Не веришь? Отложи сейчас журнал и возьми в руки секундомер. Теперь запусти Word или Excel. Засеки сколько времени будет проходить загрузка. Теперь закрой прогу и запусти ее снова. Она появится на экране практически моментально. Это потому что после выхода из проги, DLL файл не выгружается из памяти. Это происходит только тогда, когда окнам не хватает памяти и ни одна из прог не использует в данный момент эту библиотеку.

А теперь представь себе, что такое Word .... Представил? Это и текстовый редактор, и проверка орфографии, и построитель диаграмм, редактор формул и куча еще всякой всячины. Представь себе, что было бы, если все это засунуть в один файл? Нет, ты это не можешь представить. Это был бы один запускной файл размером в 30-50 мегов.

А теперь вспомни, что я тебе сегодня говорил: перед запуском, прога загружается в память. Представляешь теперь, сколько бы грузился Word? А сколько памяти он сожрал бы? А тебе ведь и половина его возможностей абсолютно не нужна. И зачем же их грузить в память?

А при использовании динамических библиотек в запускном файле находится только самое основное, а дополнительные возможности подгружаются по мере надобности из DLL-файлов. Таким образом, суммарная скорость загрузки уменьшается, причем очень даже значительно.

У динамических библиотек сплошные преимущества и ни одного существенного недостатка. Поэтому они получили такое широкое распространение и программеры используют их на каждом углу, когда надо и когда не надо. Ни когда нельзя быть уверенным, что какой-то код уже больше никогда не понадобится. Всегда нужно рассчитывать на будущее.

Я надеюсь, что я тебя убедил в великих возможностях DLL. Это действительно так. Конечно же, ActiveX более продвинуты, но они требуют геморной регистрации в системе и намного сложнее в кодинге. Но если ты разберешься с этим, то сможешь поднять свой уровень кодинга на новую высоту.

Все наверно помнят такую песенку: "Из чего же, из чего же, из чего же, сделаны эти мальчишки?". Глупейшая песня, и я со слезами на глазах вспоминаю, как я в лагере (я имею ввиду пионерский, а не концлагерь :)) распевал ее вместе с остальными пионерами. Ох и веселые были времена. Жаль сейчас так не развлечешься :(. О чем это я? Ах да... Я хотел рассказать тебе, из чего состоит Windows.

Большинство думает, что Windows - это все что находится в папке c:\Windows, а ее ядро - это win.com. В какой-то степени это так, но не совсем. Ядро окошек - это простой DLL файл, а если быть конкретнее, то это Kernel32.dll. При старте Windows эта библиотека загружается в память в единственном экземпляре и любая прога может обращаться к содержащемуся в ней коду и использовать его в своих целях.

Точно так же, за вывод графики в Windows отвечает GDI32.DLL, которая так же загружается при старте в единственном экземпляре.

В Windows очень много дыр, но динамические библиотеки это достаточно гениальное решение многократно используемого кода.

Любой геймер обязан знать про существование OpenGL. Что это такое? Какой-то пакет программ? Какой-то SDK для создания графики? Ничего подобного, это всего лишь две динамические библиотеки opengl.dll (opengl32.dll) и glu.dll (glu32.dll).

Что такое DirectX? Это графическая библиотека, которая состоит из DirectDraw, DirectInput, DirectMusic, DirectPlay и так далее. Все это не что иное, как простые динамически подгружаемые библиотеки. DirectDraw это Ddraw.dll, DirectInput это Dinput.dll, DirectMusic это Dmusic.dll и так далее.

Любые игровые движки выполнены в виде динамически загружаемых библиотек.