Превращаются ли dll в машинный код?

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

Так я знаю, что .lib-файлы превращаются в машинный код. но как насчет dll ?? Превращаются ли они в машинный код после выполнения приложения ??

Это, вероятно, может привести к легкому взлому, если нет право пользования.

5 ответов


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


библиотеки do содержит скомпилированный машинный код. Разница в том, что связь между приложением EXE и DLL выполняется в время работы, вместо (традиционного) времени связи между файлами OBJ и LIB.


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

на самом деле это часто приводит к проблемам, таким как приложение, включая код, который зависит об ошибке в старой DLL. Когда / если вы создаете версию, которая исправляет ошибку, она нарушает приложение. Google для "DLL Hell" для многих других примеров.


проще говоря: DLL могут быть заменены после компиляции, потому что они физически отделены от вашего exe. Lib и OBJ файлы, с другой стороны, скомпилирован в ваш exe, так что обновление их требуется перекомпиляция приложения.

DLL фактически являются exes, которые не определяют main ().


когда DLL связана с основной программой, только интерфейс, т. е. классы, функции и т. д. экспорт ИТ связан их подписью. Фактический машинный код внутри DLL загружается только во время выполнения, а не во время компиляции; поэтому вы можете создать свое приложение только с lib DLL и поместить фактическую DLL, где вы бы предпочли ее (например, некоторую общую папку DLL или что-то еще).

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

(возможно) запутанная часть здесь заключается в том, что существует фактически два вида .lib-файлы:

a) libs для статического связывания. Они помещают весь свой скомпилированный код непосредственно в основное приложение и являются фиксированной частью результата .файл EXE.

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

Btw: вам не нужно указывать, какой из библиотек вы ссылаетесь на какой тип, он делает это автоматически.

также: некоторые приложения построены как DLL, предназначенные для запуска внутри некоторой внешней среды. Веб-сервисы, например, реализуются как Dll с определенным интерфейсом, который выполняются сервером Apache/IISAPI/whatever. Это работает аналогично вышеупомянутой плагин-системе, но здесь каждая DLL эффективно is приложение.