Dll когда-нибудь превращается в машинный код?

Question

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

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

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

Answer 1

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

Answer 2

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

Answer 3

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

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

Answer 4

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

Dll - фактически exe, которые не определяют main ().

Answer 5

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

Затем вы можете поменять эту DLL с любой другой DLL с тем же интерфейсом. Именно так обычно работают системы плагинов, так как каждый плагин представляет собой просто DLL, которая соответствует задокументированному предварительно определенному интерфейсу, и программа просто загружает все библиотеки DLL того интерфейса, которые она находит, в некоторый каталог «плагинов».

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

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

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

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

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