Библиотека с динамической компоновкой

Библиотека динамической компоновки

Расширение имени файла	.dll
Тип интернет-СМИ	приложение / vnd.microsoft.portable-исполняемый
Единый идентификатор типа (UTI)	com.microsoft.windows-динамическая-библиотека-компоновка
Магическое число	MZ
Разработан	Microsoft
Контейнер для	Общая библиотека

Динамически подключаемая библиотека ( DLL ) является Microsoft реализация «s из общей библиотеки концепции в Microsoft Windows и OS / 2 операционные системы . Эти библиотеки обычно имеют расширение файла DLL , OCX(для библиотек , содержащих ActiveX элементов управления), или DRV(для устаревших системных драйверов ). Форматы файлов для DLL такие же, как и для файлов Windows EXE, то есть Portable Executable (PE) для 32-битной и 64-битной Windows и New Executable (NE) для 16-битной.Windows. Как и в случае с EXE, библиотеки DLL могут содержать код , данные и ресурсы в любой комбинации.

Файлы данных с тем же форматом файла, что и DLL, но с разными расширениями и, возможно, содержащими только разделы ресурсов, могут называться библиотеками ресурсов . Примеры таких DLL включают библиотеки значков , иногда имеющие расширение ICL, и файлы шрифтов , имеющие расширения FONи FOT. ^[1]

Фон [ править ]

Первые версии Microsoft Windows запускали программы вместе в одном адресном пространстве . Каждая программа должна была взаимодействовать, передавая центральный процессор другим программам, чтобы графический интерфейс пользователя (GUI) мог работать в многозадачном режиме и быть максимально отзывчивым. Все операции на уровне операционной системы обеспечивались базовой операционной системой: MS-DOS . Все услуги более высокого уровня были предоставлены библиотеками Windows «Библиотека динамической компоновки». Drawing API , графических устройств интерфейса (GDI), был реализован в DLL называется GDI.EXE, пользовательский интерфейс вUSER.EXE. Эти дополнительные уровни поверх DOS должны были быть общими для всех запущенных программ Windows, не только для того, чтобы Windows могла работать на машине с объемом оперативной памяти менее мегабайта, но и для того, чтобы программы могли взаимодействовать друг с другом. Код в GDI должен был переводить команды рисования в операции на определенных устройствах. На дисплее ему приходилось манипулировать пикселями в буфере кадра. При рисовании на принтере вызовы API должны были быть преобразованы в запросы к принтеру. Хотя можно было бы обеспечить жестко запрограммированную поддержку ограниченного набора устройств (например, дисплея адаптера цветной графики , командного языка принтера HP LaserJet ), Microsoft выбрала другой подход. GDI будет работать, загружая различные фрагменты кода, называемые " драйверами устройств".", чтобы работать с разными устройствами вывода.

Та же архитектурная концепция, которая позволяла GDI загружать разные драйверы устройств, позволяла оболочке Windows загружать различные программы Windows, а также для этих программ вызывать вызовы API из общих библиотек USER и GDI. Это понятие было «динамическое связывание».

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

Для тех ранних версий Windows (от 1.0 до 3.11) библиотеки DLL были основой всего графического интерфейса. Таким образом, драйверы дисплея представляли собой просто библиотеки DLL с расширением .DRV, которые предоставляли пользовательские реализации одного и того же API рисования через унифицированный интерфейс драйвера устройства (DDI), а API рисования (GDI) и GUI (USER) были просто экспортированными вызовами функций GDI и USER, системные библиотеки DLL с расширением .EXE.

Идея создания операционной системы из набора динамически загружаемых библиотек является основной концепцией Windows, которая сохраняется с 2015 года ^{[Обновить]}. Библиотеки DLL предоставляют стандартные преимущества общих библиотек , такие как модульность . Модульность позволяет вносить изменения в код и данные в одной автономной DLL, совместно используемой несколькими приложениями, без каких-либо изменений в самих приложениях.

Еще одно преимущество модульности - использование универсальных интерфейсов для подключаемых модулей. Может быть разработан единый интерфейс, который позволяет как старые, так и новые модули легко интегрировать во время выполнения в уже существующие приложения без каких-либо изменений в самом приложении. Эта концепция динамической расширяемости доведена до крайности в объектной модели компонентов , лежащей в основе ActiveX .

В Windows 1.x, 2.x и 3.x все приложения Windows совместно использовали одно и то же адресное пространство, а также одну и ту же память. DLL загружалась в это адресное пространство только один раз; с этого момента к нему обращались все программы, использующие библиотеку. Данные библиотеки были общими для всех программ. Это может быть использовано как косвенная форма межпроцессного взаимодействия или может случайно повредить различные программы. С появлением 32-битных библиотек в Windows 95 каждый процесс запускался в собственном адресном пространстве. Хотя код DLL может быть общим, данные являются частными, за исключением случаев, когда общие данные явно запрашиваются библиотекой. Тем не менее, большая часть Windows 95 , Windows 98 и Windows Meбыли построены из 16-битных библиотек, что ограничивало производительность микропроцессора Pentium Pro при запуске и в конечном итоге ограничивало стабильность и масштабируемость версий Windows для DOS.

Хотя библиотеки DLL являются ядром архитектуры Windows, у них есть несколько недостатков, которые в совокупности называются « адом DLL ». ^[2] С 2015 года ^{[Обновить]}Microsoft продвигает .NET Framework как одно из решений проблем адского DLL, хотя теперь они продвигают решения на основе виртуализации, такие как Microsoft Virtual PC и Microsoft Application Virtualization , поскольку они обеспечивают превосходную изоляцию между приложениями. Альтернативным решением для смягчения последствий ада DLL была реализация параллельной сборки .

Особенности [ править ]

Так как библиотеки DLL по сути такие же, как и EXE-файлы, выбор из них для создания в процессе компоновки сделан для ясности, поскольку из них можно экспортировать функции и данные.

Невозможно напрямую выполнить DLL, так как для загрузки операционной системы через точку входа требуется EXE-файл , отсюда и существование таких утилит, как RUNDLL.EXE или RUNDLL32.EXE, которые обеспечивают точку входа и минимальную структуру для DLL. которые содержат достаточно функций для работы без особой поддержки.

Библиотеки DLL предоставляют механизм для общего кода и данных, позволяя разработчику общего кода / данных обновлять функциональность без необходимости повторного связывания или повторной компиляции приложений. С точки зрения разработки приложений Windows и OS / 2 можно рассматривать как набор обновляемых DLL, позволяющих приложениям для одной версии ОС работать в более поздней версии, при условии, что поставщик ОС гарантирует, что интерфейсы и функциональность совместимы.

Библиотеки DLL выполняются в пространстве памяти вызывающего процесса и с теми же правами доступа, что означает небольшие накладные расходы при их использовании, но также отсутствие защиты для вызывающего EXE, если в DLL есть какая-либо ошибка.

Управление памятью [ править ]

В Windows API файлы DLL организованы в разделы . Каждый раздел имеет свой собственный набор атрибутов, таких как доступный для записи или только для чтения, исполняемый (для кода) или неисполняемый (для данных) и т. Д.

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

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

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

Импортировать библиотеки [ править ]

Как и статические библиотеки, библиотеки импорта для DLL помечаются расширением файла .lib. Например, kernel32.dll , основная динамическая библиотека для основных функций Windows, таких как создание файлов и управление памятью, связана через kernel32.lib. Обычный способ отличить библиотеку импорта от правильной статической библиотеки - по размеру: библиотека импорта намного меньше, так как она содержит только символы, относящиеся к реальной DLL, которые должны обрабатываться во время компоновки. Тем не менее, оба являются файлами формата ar Unix .

Связывание с динамическими библиотеками обычно осуществляется путем связывания с библиотекой импорта при создании или связывании для создания исполняемого файла. Созданный исполняемый файл затем содержит таблицу адресов импорта (IAT), с помощью которой ссылаются на все вызовы функций DLL (каждая упомянутая функция DLL содержит свою собственную запись в IAT). Во время выполнения IAT заполняется соответствующими адресами, которые указывают непосредственно на функцию в отдельно загруженной DLL. ^[3]

В Cygwin / MSYS и MinGW библиотекам импорта обычно дается суффикс .dll.a, сочетающий в себе суффикс Windows DLL и суффикс ar Unix. Формат файла похож, но символы, используемые для обозначения импорта, отличаются (_head_foo_dll vs __IMPORT_DESCRIPTOR_foo). ^[4] Хотя его инструментальная цепочка GNU Binutils может генерировать библиотеки импорта и связываться с ними, связываться с DLL напрямую быстрее. ^[5] Экспериментальный инструмент в MinGW под названием genlib может использоваться для создания библиотек импорта с символами в стиле MSVC.

Разрешение символа и привязка [ править ]

Каждая функция, экспортируемая библиотекой DLL, идентифицируется числовым порядковым номером и, возможно, именем. Точно так же функции могут быть импортированы из DLL по порядковому номеру или по имени. Порядковый номер представляет собой позицию указателя адреса функции в таблице адресов экспорта DLL. Обычно внутренние функции экспортируются только по порядковому номеру. Для большинства функций Windows API в разных выпусках Windows сохраняются только имена; порядковые номера могут быть изменены. Таким образом, нельзя надежно импортировать функции Windows API по порядковому номеру.

Импорт функций по порядковому номеру обеспечивает лишь немного лучшую производительность, чем импорт их по имени: таблицы экспорта библиотек DLL упорядочены по имени, поэтому для поиска функции можно использовать двоичный поиск . Индекс найденного имени затем используется для поиска порядкового номера в таблице порядковых номеров экспорта. В 16-битной Windows таблица имен не сортировалась, поэтому затраты на поиск имени были гораздо более заметными.

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

Связанные исполняемые файлы загружаются несколько быстрее, если они запускаются в той же среде, для которой они были скомпилированы, и точно в то же время, если они запускаются в другой среде, поэтому нет никаких недостатков для привязки импорта. Например, все стандартные приложения Windows привязаны к системным библиотекам DLL соответствующего выпуска Windows. Хорошая возможность привязать импорт приложения к его целевой среде - во время установки приложения. Это удерживает библиотеки «связанными» до следующего обновления ОС. Однако он изменяет контрольную сумму исполняемого файла, поэтому это нельзя сделать с помощью подписанных программ или программ, управляемых инструментом управления конфигурацией, который использует контрольные суммы (например, MD5контрольные суммы) для управления версиями файлов. Поскольку в более поздних версиях Windows отказались от фиксированных адресов для каждой загруженной библиотеки (по соображениям безопасности), возможность и ценность привязки исполняемого файла уменьшаются.

Явное связывание во время выполнения [ править ]

Файлы DLL могут быть явно загружены во время выполнения, процесс, называемый Microsoft просто динамической компоновкой во время выполнения, с помощью функции LoadLibrary(или LoadLibraryEx) API. Функция GetProcAddressAPI используется для поиска экспортированных символов по имени и FreeLibrary- для выгрузки DLL. Эти функции аналогичны dlopen, dlsymи dlcloseв POSIX стандарта API.

Процедура явного связывания во время выполнения одинакова для любого языка, поддерживающего указатели на функции , поскольку она зависит от Windows API, а не от языковых конструкций.

Отложенная загрузка [ править ]

Обычно приложение, связанное с библиотекой импорта DLL, не запускается, если DLL не может быть найдена, потому что Windows не запустит приложение, пока не найдет все библиотеки DLL, которые могут понадобиться приложению. Однако приложение может быть связано с библиотекой импорта, чтобы разрешить отложенную загрузку динамической библиотеки. ^[6] В этом случае операционная система не будет пытаться найти или загрузить DLL при запуске приложения; вместо этого компоновщик включает в приложение заглушку, которая пытается найти и загрузить DLL через LoadLibrary и GetProcAddress при вызове одной из его функций. Если DLL не может быть найдена или загружена или вызываемая функция не существует, приложение сгенерирует исключение., которые могут быть пойманы и обработаны соответствующим образом. Если приложение не обрабатывает исключение, оно будет перехвачено операционной системой, которая завершит программу с сообщением об ошибке.

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

Рекомендации по компилятору и языку [ править ]

Delphi [ править ]

В исходном файле ключевое слово libraryиспользуется вместо program. В конце файла экспортируемые функции перечислены в exportsразделе.

Delphi не нужны LIBфайлы для импорта функций из DLL; для связи с DLL externalключевое слово используется в объявлении функции для обозначения имени DLL, за которым nameследует имя символа (если он отличается) или indexдля идентификации индекса.

Microsoft Visual Basic [ править ]

В Visual Basic (VB) поддерживается только связывание во время выполнения; но в дополнение к функциям using LoadLibraryи GetProcAddressAPI разрешены объявления импортированных функций.

При импорте функций DLL через объявления VB выдаст ошибку времени выполнения, если DLLфайл не может быть найден. Разработчик может обнаружить ошибку и обработать ее соответствующим образом.

При создании библиотек DLL в VB среда IDE разрешает создание только библиотек ActiveX DLL, однако были созданы методы ^[7], позволяющие пользователю явно указать компоновщику включить файл .DEF, который определяет порядковый номер и имя каждой экспортируемой функции. . Это позволяет пользователю создавать стандартную DLL Windows с помощью Visual Basic (версии 6 или ниже), на которую можно ссылаться с помощью оператора «Declare».

C и C ++ [ править ]

Microsoft Visual C ++ (MSVC) предоставляет несколько расширений для стандартного C ++, которые позволяют указывать функции как импортированные или экспортируемые непосредственно в коде C ++; они были приняты другими компиляторами Windows C и C ++, включая версии GCC для Windows . Эти расширения используют атрибут __declspecперед объявлением функции. Обратите внимание, что когда доступ к функциям C осуществляется из C ++, они также должны быть объявлены, как extern "C"в коде C ++, чтобы сообщить компилятору, что следует использовать связь C. ^[8]

Помимо указания импортируемых или экспортируемых функций с помощью __declspecатрибутов, они могут быть перечислены в разделе IMPORT или EXPORTS DEFфайла, используемого проектом. DEFФайл обрабатывается с помощью линкера, а не компилятор, и таким образом это не является специфической для C ++.

Компиляция DLL создаст как файлы, так DLLи LIB. LIBФайл (библиотеки импорта) используется для связи против DLL во время компиляции; это не требуется для связывания во время выполнения. Если DLL не является сервером модели компонентных объектов (COM), DLLфайл должен быть помещен в один из каталогов, перечисленных в переменной среды PATH, в системном каталоге по умолчанию или в том же каталоге, что и программа, использующая его. DLL-библиотеки COM-сервера регистрируются с помощью regsvr32.exe, который помещает расположение DLL и ее глобальный уникальный идентификатор ( GUID ) в реестр. Затем программы могут использовать DLL, найдя ее GUID в реестре. чтобы найти его местоположение или создать экземпляр COM-объекта косвенно, используя его идентификатор класса и идентификатор интерфейса.

Примеры программирования [ править ]

Использование импорта DLL [ править ]

В следующих примерах показано, как использовать привязки для конкретного языка для импорта символов для связывания с DLL во время компиляции.

Delphi

{$ КОНСОЛЬ APPTYPE} пример программы ;// импортируем функцию, которая складывает два числа function  AddNumbers ( a ,  b  :  Double ) :  Double ;  StdCall ;  внешний  'Example.dll' ;// основная программа var  R :  Double ;начало  R  : =  AddNumbers ( 1 ,  2 ) ;  Writeln ( 'Результат был:' ,  R ) ; конец .

C

Файл Example.lib должен быть включен (при условии, что Example.dll сгенерирован) в проект (опция «Добавить существующий элемент» для проекта!) Перед статической связью. Файл Example.lib автоматически создается компилятором при компиляции DLL. Невыполнение вышеуказанного оператора приведет к ошибке связывания, поскольку компоновщик не будет знать, где найти определение AddNumbers. DLL-файл Example.dll, возможно, также придется скопировать в место, где будет создан EXE-файл, с помощью следующего кода.

#include  <windows.h>#include  <stdio.h>// Функция импорта, которая складывает два числа extern  «C»  __declspec ( dllimport )  double  AddNumbers ( double  a ,  double  b );int  main ( int  argc ,  char  * argv []) {  двойной  результат  =  AddNumbers ( 1 ,  2 );  printf ( "Результат был:% f \ n " ,  результат );  возврат  0 ; }

Использование явного связывания во время выполнения [ править ]

В следующих примерах показано, как использовать средства загрузки и связывания во время выполнения с помощью привязок Windows API для конкретных языков.

Обратите внимание, что все четыре образца уязвимы для атак с предварительной загрузкой DLL , поскольку example.dll может быть разрешен в место, непредусмотренное автором (текущий рабочий каталог находится перед местоположениями системных библиотек), и, следовательно, для вредоносной версии библиотеки. См. Ссылку на руководство Microsoft по безопасной загрузке библиотек: нужно использовать SetDllDirectoryWin kernel32для удаления поиска в текущем каталоге перед загрузкой любых библиотек. ^[9]

Microsoft Visual Basic [ править ]

Опция  Явная Declare  Function  AddNumbers  Lib  "Example.dll" _ ( ByVal  в  As  Double ,  ByVal  б  As  Double )  Как  DoubleSub  Main () Dim  Result  As  Double Result  =  AddNumbers ( 1 ,  2 ) Debug . Напечатайте  «Результат был:»  &  Результат Конец  Подп.

Delphi [ править ]

 пример программы ;  {$ APPTYPE CONSOLE}  использует  Windows ;  var  AddNumbers : function  ( a ,  b :  integer ) :  Double ;  StdCall ;  LibHandle : HMODULE ; begin  LibHandle  : =  LoadLibrary ( 'example.dll' ) ;  если  LibHandle  <>  0,  то  AddNumbers  : =  GetProcAddress ( LibHandle ,  'AddNumbers' );  если  присвоено ( AddNumbers ),  то  Writeln (  '1 + 2 =' ,  AddNumbers (  1 ,  2  )  ) ;  Readln ; конец .

C [ править ]

#include  <windows.h>#include  <stdio.h>// Сигнатура функции DLL typedef  double  ( * importFunction ) ( double ,  double );int  main ( int  argc ,  char  ** argv ) { importFunction  addNumbers ; двойной  результат ; HINSTANCE  hinstLib ;// Загрузка файла DLL hinstLib  =  LoadLibrary ( TEXT ( "Example.dll" )); if  ( hinstLib  ==  NULL )  { printf ( "ОШИБКА: невозможно загрузить DLL \ n " ); возврат  1 ; }// Получить указатель на функцию addNumbers  =  ( importFunction )  GetProcAddress ( hinstLib ,  "AddNumbers" ); if  ( addNumbers  ==  NULL )  { printf ( "ОШИБКА: невозможно найти функцию DLL \ n " ); FreeLibrary ( hinstLib ); возврат  1 ; }// Вызов функции. результат  =  addNumbers ( 1 ,  3 );// Выгрузка DLL-файла FreeLibrary ( hinstLib );// Отображаем результат printf ( "Результат был:% f \ n " ,  результат );возврат  0 ; }

Python [ править ]

Привязка Python ctypes будет использовать POSIX API в системах POSIX.

import  ctypesmy_dll  =  ctypes . cdll . LoadLibrary ( "Example.dll" )# Следующая спецификация метода "рестайпа" необходима, чтобы # Python понял, какой тип возвращается функцией. my_dll . AddNumbers . restype  =  ctypes . c_doubleр  =  моя_длл . AddNumbers ( ctypes . C_double ( 1.0 ),  ctypes . C_double ( 2.0 ))print ( "Результат был:" ,  p )

Компонентная объектная модель [ править ]

Модель компонентных объектов (COM) определяет двоичный стандарт для размещения реализации объектов в файлах DLL и EXE. Он предоставляет механизмы для поиска и версии этих файлов, а также независимое от языка и машиночитаемое описание интерфейса. Размещение COM-объектов в DLL более легкое и позволяет им совместно использовать ресурсы с клиентским процессом. Это позволяет COM-объектам реализовывать мощные внутренние интерфейсы для простых интерфейсов с графическим интерфейсом пользователя, таких как Visual Basic и ASP. Их также можно запрограммировать на языках сценариев. ^[10]

Угон DLL [ править ]

Из-за уязвимости, обычно известной как захват DLL, подмена DLL, предварительная загрузка DLL или установка двоичного файла, многие программы загружают и запускают вредоносную DLL, содержащуюся в той же папке, что и файл данных, открытый этими программами. ^{[11] [12] [13] [14]} Уязвимость была обнаружена Георгием Гунински в 2000 году. ^[15] В августе 2010 года она получила всемирную известность после того, как система безопасности ACROS снова обнаружила ее и многие сотни программ были обнаружены уязвимыми. ^[16] Программы, запускаемые из небезопасных мест, т. Е. Доступных для записи папок, таких как « Загрузки» или « Временный каталог», почти всегда подвержены этой уязвимости. ^{[17][18] [19] [20] [21] [22] [23]}

См. Также [ править ]

• Dependency Walker , утилита, отображающая экспортированные и импортированные функции файлов DLL и EXE.
• Динамическая библиотека
• Библиотека (компьютерная)
• Линкер (вычисления)
• Загрузчик (вычисления)
• Moricons.dll
• Файл объекта
• Общая библиотека
• Статическая библиотека
• DLL ад

Ссылки [ править ]

• Харт, Джонсон. Третье издание системного программирования Windows . Аддисон-Уэсли, 2005. ISBN  0-321-25619-0 .
• Ректор, Брент и др. Программирование Win32 . Addison-Wesley Developers Press, 1997. ISBN 0-201-63492-9 . 

Внешние ссылки [ править ]

• dllexport, dllimport в MSDN
• Библиотеки с динамической компоновкой в MSDN
• Безопасность динамически подключаемых библиотек в MSDN
• Порядок поиска динамически подключаемых библиотек в MSDN
• Рекомендации Microsoft по безопасности: небезопасная загрузка библиотеки может позволить удаленное выполнение кода
• Что такое DLL? на сайте поддержки Microsoft
• Функции библиотеки динамической компоновки в MSDN
• Спецификация формата переносимых исполняемых файлов и общих объектных файлов Microsoft
• Спецификация Microsoft для файлов dll
• Взрыв ковра и отравление в каталоге
• MS09-014: Устранение уязвимости Safari Carpet Bomb
• Подробнее о векторе удаленной атаки DLL Preloading
• Обновление вектора удаленной атаки с предварительной загрузкой DLL
• Безопасная загрузка библиотеки