каковы плюсы и минусы использования DLL?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Да, увидеть это текст :

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

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

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

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