что за и против использования является DLL?

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

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

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

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

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

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

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

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

Программное обеспечение MacOS также использует «dll», просто они называются по-другому (разделяемые библиотеки).
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 на диск. Напротив, каждое приложение построенный со статической библиотекой ссылок имеет код библиотеки, связанный с его исполняемый образ как отдельный копия.
Обновления библиотеки DLL Полегче. Когда функции в DLL изменить, приложения, которые их используют не нужно перекомпилировать или повторно связать, пока функция аргументы и возвращаемые значения не изменение. Напротив, статически связанный объектный код требует, чтобы приложение будет повторно связано, когда функции меняются.
Обеспечивает послепродажная поддержка. Например, DLL драйвера дисплея можно изменить на поддерживать дисплей, который не был доступно, когда приложение было отправлено.
Поддерживает мультиязычность программы. Программы, написанные на разные языки программирования могут вызывать ту же функцию DLL, пока программы следуют функциям соглашение о вызовах. Программы и функция DLL должна быть совместима в следующие способы: порядок, в котором функция ожидает, что ее аргументы будут помещается в стек, независимо от того, функция или приложение отвечает за очистку стека, и переданы ли какие-либо аргументы в регистрах.
Предоставляет механизм для расширения классов библиотеки MFC. Вы может выводить классы из существующих Классы MFC и поместить их в MFC DLL расширения для использования MFC приложения.
Облегчает создание международных версий. Поместив ресурсы в DLL, это намного проще создать международные версии применение. Вы можете разместить струны для каждой языковой версии вашего приложение в отдельной ресурсной DLL и иметь другой язык версии загружают соответствующие ресурсы.
Потенциал Недостатком использования DLL является то, что приложение не является самодостаточным; Это зависит от наличия отдельного Модуль DLL.

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

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

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

Вы пробовали что-то подобное?

foo = GetYouTubeVideoEntry(video_id=youtube_video_id_to_output)
foo.author

Документы для YouTubeVideoEntry не очень хорош, но метод __ init __ , похоже, принимает автора.