Каковы плюсы и минусы использования DLL? - PullRequest
6 голосов
/ 02 июня 2009

Windows по-прежнему использует DLL, а программы Mac, похоже, вообще не используют DLL. Есть ли преимущества или недостатки использования какой-либо техники?

Если установка программы включает в себя все необходимые библиотеки DLL, чтобы она работала на 100%, будет ли это так же, как статическое связывание всех библиотек?

Ответы [ 9 ]

12 голосов
/ 02 июня 2009

MacOS X, как и другие разновидности Unix, использует разделяемые библиотеки, которые являются еще одной формой DLL.

И да, оба эти преимущества выгодны, поскольку DLL или код общей библиотеки могут совместно использоваться несколькими процессами. Это происходит путем загрузки ОС или общей библиотеки DLL и сопоставления ее с виртуальным адресным пространством процессов, которые ее используют.

1 голос
/ 02 июня 2009

Программное обеспечение MacOS также использует «dll», они просто называются по-разному (общие библиотеки).
Dll имеет смысл, если у вас есть код, который вы хотите использовать в различных компонентах вашего программного обеспечения. В основном это имеет смысл в больших программных проектах.
Статическое связывание имеет смысл для небольших однокомпонентных приложений, когда нет необходимости повторного использования кода. Это упрощает распространение, поскольку ваш компонент не имеет внешних зависимостей.

1 голос
/ 02 июня 2009

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

1 голос
/ 02 июня 2009

Windows по-прежнему использует библиотеки DLL и Mac программы, похоже, вообще не используют DLL. Являются ли они преимуществами или недостатками используя любую технику?

Любой вид модульности хорош, поскольку он облегчает обновление программного обеспечения, т. Е. Вам не нужно обновлять весь двоичный файл программы, если в программе исправлена ​​ошибка. Если ошибка появляется в некоторой dll, необходимо обновить только dll.

Единственный недостаток imo - это то, что вы привносите еще одну сложность в разработку программы, например, если dll - это c или c ++ dll, другие соглашения о вызовах и т. д.

Если установка программы включает все необходимая DLL, будет ли так же, как статически связывая все библиотеки?

Более или менее да. Зависит от того, вызываете ли вы функции в DLL, с которой вы предполагаете статическую связь. DLL также может быть «автономной» динамической библиотекой, к которой вы можете получить доступ только через LoadLibrary (), GetProcAddress () и т. Д.

1 голос
/ 02 июня 2009

В Windows вы должны использовать динамически загружаемые библиотеки, поскольку библиотеки GDI и USER доступны только в виде DLL. Вы не можете связать ни одного из них или поговорить с ними, используя протокол, который не включает динамическую загрузку.

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

0 голосов
/ 03 июня 2009

С моей точки зрения, общий компонент имеет некоторые преимущества, которые иногда рассматриваются как недостатки.

  • общий компонент определяет интерфейсы в вашем процессе. Таким образом, вы должны решить, какие компоненты / интерфейсы видны снаружи, а какие скрыты. Это автоматически определяет, какой интерфейс должен быть стабильным, а какой не должен быть стабильным и может быть реорганизован без влияния на какой-либо код вне компонента.
  • Администрирование памяти в случае C ++ и Windows должно быть хорошо продумано. Поэтому обычно вы не должны обрабатывать память вне dll, которая не освобождается в той же dll. В этом случае ваш компонент может выйти из строя, если: используются разные среды выполнения или версия компилятора.

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

0 голосов
/ 02 июня 2009

Windows по-прежнему использует DLL, а программы Mac, похоже, вообще не используют DLL. Являются ли они преимуществами или недостатками использования какой-либо техники?

Оба используют разделяемые библиотеки, они просто используют другое имя.

Если установка программы включает в себя все необходимые библиотеки DLL, чтобы она работала на 100%, будет ли это так же, как статическое связывание всех библиотек?

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

Статически связанному файлу не потребуется этап «разрешение общих библиотек» (который происходит во время загрузки программы). Давным-давно загрузка статической программы означала, что вся программа сначала загружалась в ОЗУ, а затем происходил этап «Разрешить совместное использование библиотек». Сегодня только те части программы, которые фактически выполняются, загружаются по требованию. Так что со статической программой вам не нужно разрешать библиотеки DLL. С DLL вам не нужно загружать их все сразу. Таким образом, производительность должна быть на уровне

Что оставляет "DLL ад". Многие программы в Windows приносят все необходимые им библиотеки DLL и записывают их в каталог Windows. Чистый эффект состоит в том, что последние установленные программы работают, а все остальное может быть повреждено. Но есть простой обходной путь: установите библиотеки DLL в тот же каталог, что и EXE. Windows будет сначала искать текущий каталог, а затем различные пути Windows. Таким образом, вы будете тратить немного дискового пространства, но ваша программа будет работать, и, что более важно, вы больше ничего не сломаете.

Можно утверждать, что вы не должны устанавливать библиотеки DLL, которые уже существуют (с той же версией) в каталоге Windows, но тогда вы снова становитесь уязвимыми к какому-то плохому приложению, которое перезаписывает нужную версию чем-то, что ломает вам голову , Недостатком является то, что вы должны сами распространять исправления безопасности для своего приложения; Вы не можете полагаться на Центр обновления Windows или подобные вещи для защиты своего кода. Это трудное место; взломщики зарабатывают много денег на проблемах безопасности, и людям не понравится, когда кто-то украдет их банковские данные, потому что вы не выпускали исправления безопасности достаточно скоро.

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

0 голосов
/ 02 июня 2009

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

Когда в библиотеках InfoZIP ZIP возникала уязвимость безопасности, обновление DLL / .so автоматически делало все программное обеспечение безопасным, в котором они использовались. Программное обеспечение, которое было связано статически, нужно было перекомпилировать.

0 голосов
/ 02 июня 2009

Да, смотрите этот текст :

Динамическое связывание имеет следующее Преимущества:
Экономит память и уменьшает обмен Многие процессы могут использовать одну DLL одновременно, совместное использование одной копии DLL в объем памяти. В отличие от Windows должна загрузить копия кода библиотеки в память для каждого приложения, которое построено со статической библиотекой ссылок.
Сохраняет дисковое пространство. Многие приложения могут поделиться одной копией DLL на диск. В отличие от каждого приложения построен со статической связью, библиотека имеет код библиотеки, связанный с его исполняемый образ как отдельный copy.
Обновления до DLL Полегче. Когда функции в DLL изменить, приложения, которые их используют не нужно перекомпилировать или переподключил до тех пор, пока функция аргументы и возвращаемые значения не менять. Напротив, статически связаны объектный код требует, чтобы приложение будет переподключено, когда изменение функций.
Обеспечивает послепродажная поддержка. Например, DLL драйвера дисплея может быть изменена на поддерживать дисплей, который не был доступно, когда приложение было
Поддержка мультиязычности программы. Программы написаны на разные языки программирования могут вызывать одну и ту же функцию DLL до тех пор, пока программы следуют за функцией Соглашение о вызовах. Программы и функция DLL должна быть совместимой в следующие способы: порядок, в котором функция ожидает своих аргументов положить в стек, будь то функция или приложение ответственный за очистку стека, и передаются ли какие-либо аргументы в регистрах.
Предоставляет механизм расширить классы библиотеки MFC. Вы может извлечь классы из существующего Классы MFC и поместите их в MFC DLL расширения для использования MFC приложения.
облегчает создание международных версий. Поместив ресурсы в DLL, это гораздо проще создавать международные версии приложение. Вы можете разместить строки для каждой языковой версии вашего приложение в отдельном ресурсе DLL и иметь другой язык версии загружают соответствующие ресурсы.
Потенциал Недостатком использования DLL является то, что приложение не является автономным; Это зависит от существования отдельного Модуль DLL.

...