Хакер » 03.03.2008 (Пн) 13:06
Либо читаешь, и неправильно понимаешь написанное, либо в книге бред пишут и в печке ей место (книге).
Кратко и ясно:
У каждого процесса есть своё АП, со соими данными и своим кодом. Всё это туда сваливается из образа исполняемого EXE-файла загрузчиком. Умные люди решили, что т.к. почти во всех программах будет встречаться одинаковый код, не совсем правильно помещать одно и то же в каждый образ. Т.к. в АП процесса можно в любое время писать всё что вздумается, придумали концепцию, согласно которой в АП процесса можно будет подгружать данные из файлов. Таким образом, одинаковые данные и сотни различных программ можно хранить в одном файле. Кроме того, всё это настолько хорошо соотносится с механизмом работы виртуальной памяти (своппинга, в частности), что такая фишка может не только экономить место на диске, но и место в оперативке. Файлы обозвали библиотеками, но т.к. понятие "библиотека" уже закрепилось за lib-ками, чтобы не было путаницы и для подчёркивания всех преимуществ нового подхода, файлы обозвали динамически связываемыми библиотеками (Dynamically linked libraries, DLLs). То, что образуется в памяти в результате подгрузки DLL в процесс обозвали модулями.
Так вот, в широком смысле - DLL - это любой файл (специального формата - PE-формата, - такого же формата, как и EXE-файл), который можно подгрузить в процесс. Вообще говоря, загрузка производится специальными API-функциями, но если особо хочется (или по обычному по каким-то причинам - нельзя) - можно и вручную.
В DLL файлах может быть код и данные. Вообщем, данные, потому что код - тоже данные.
Раз там может быть код, там могут быть функции, которые программы (подгружающие к себе DLL) могут вызывать. Процесс этот автоматизировали (в какой-то степени), в PE-файлах появилась таблица импорта (теперь DLL подгружаются в процесс системой, сразу же, при запуске процесса, избавляя программиста от необходимости грузить; теперь программисту не надо заботиться о поиске нужной сущности (обычно - функции) в DLL), таблица экспорта (в которой записаны соответствия "Имя сущности" - "Номер сущности" - "Адрес сущности в DLL"), таблица релоков (в которой записаны (если в DLL есть код) адреса всех мест в коде, где используется абсолютная адресация, которые надо фикс-ап'ить, если DLL вдруг загрузится не в то место памяти, куда предполагается (а предполагается всегда-куда то в конкретное место, в ImageBase-так называемый. Но если это место в памяти уже чем-то/кем-то занято, DLL может загрузится в совершенно другое место, благодаря reloс-ам); если этой таблицы нет, процесс загрузки DLL обламывается, если загрузка по ImageBase невозможна).
DLL сами могут использовать сущности из других DLL. В этом случае все DLL подгрузятся в АП процесса.
OCX - это просто расширение другое, а на деле - та же DLL. Некоторые люди, с своё время, подумали, что таблица импорта/экспорта -- не есть гуд, да и к тому же, неООП-complatible. И решили сделать надстройку над обычными механизмами, и придумали COM. (Они, в действительности, конечно, по другому думали, но в рамках данного руководства "О DLL в картинках" сойдёт и такое).
ActiveX DLL (ActiveX Control и прочее) - такие же DLL, только имеющие специальный набор функций (DllGetClassObject, и другие, менее важные), которые стали позволять работать с объектами и классами. DLL теперь могут экспортировать не только функции, но и классы (и не только классы).
ActiveX EXE - немного из другой оперы. Люди (те самые, умные) решили, сделать общую часть в одном АП. Механизмы DLL тут уже не используются, используются сообщения и маршаллинг (для коммуникации между ActveX EXE и клиентами).
Так вот, подводим итог.
ActiveX EXE, это частный случай EXE.
ActiveX DLL, ActiveX Control - частные случаи DLL.
Просто DLL экспортируют функции, ActiveX DLL экспортируют функции, из которых обязательно две - отвечают за механизм "экспорта классов".
VB6 позволял делать только (чисто) ActiveX DLL (т.е. по сути, он не позволял программисту экспортировать свои собственные функции).
Я тут, относительно недавно, подумал, что это как-то нехорошо, и решил в какой-то степени эту проблему (см. FireNativeDLL).
—We separate their smiling faces from the rest of their body, Captain.
—That's right! We decapitate them.