Windows все еще использует библиотеки DLL и Mac, похоже, вообще не использует DLL. Есть ли преимущества или недостатки использования любой техники?Каковы преимущества и недостатки использования DLL?
Если установка программы включает в себя всю необходимую DLL, чтобы она работала на 100% хорошо, будет ли она такой же, как статическая привязка всех библиотек?
MacOS X, как и другие разновидности Unix, использует общие библиотеки, которые представляют собой еще одну форму DLL.
И да, оба преимущества являются предпочтительными, поскольку DLL или общий библиотечный код могут совместно использоваться несколькими процессами. Это происходит при загрузке ОС библиотеки DLL или совместно используемой библиотеки и сопоставлении ее с виртуальным адресным пространством процессов, которые ее используют.
Как выглядят программы для Mac такой большой, как 27MB или даже 106MB? –
@ Jian Lin - большой по сравнению с чем? –
@ Russ много раз, Windows EXE очень мала, как 5MB или 16MB. –
В Windows вы должны использовать динамически загруженные библиотеки, поскольку библиотеки GDI и USER доступны только как DLL. Вы не можете связать ни одного из них или поговорить с ними, используя протокол, который не включает динамическую загрузку.
В других ОС вы хотите использовать динамическую загрузку в любом случае для сложных приложений, иначе ваш двоичный код будет раздуваться без уважительной причины, и это увеличивает вероятность того, что ваше приложение будет несовместимо с системой в долгосрочной перспективе (однако, в скором времени статическое связывание может несколько защитить вас от крошечных изменений в библиотеках). И вы не можете ссылаться в собственных библиотеках на операционные системы, которые полагаются на них.
Windows все еще использует библиотеки DLL и Mac , по-видимому, не использует DLL вообще. Являются ли они преимуществами или недостатками с использованием любой техники?
Любой вид модуляции хорош, поскольку он облегчает обновление программного обеспечения, то есть вам не нужно обновлять всю программу, если ошибка исправлена в программе. Если ошибка появляется в некоторой DLL, необходимо обновить только DLL.
Единственный недостаток в этом случае заключается в том, что вы вводите еще одну сложность в разработку программы, например. если длл это с или с длл ++, различные соглашения по вызову и т.д.
Если программа установки включает в себя все DLL, она требует, это будет в же, как статически, связывающие все библиотеки?
Более-менее да. Зависит от того, вы вызываете функции в dll, с которой вы принимаете статическую связь. DLL также может быть «свободной» динамической библиотекой, доступ к которой вы можете получить только через LoadLibrary() и GetProcAddress() и т. Д.
Одно из преимуществ общих библиотек (DLL в Windows или .so в Unix) заключается в том, что вы можете перестраивать библиотеку и ее потребителей по отдельности, в то время как со статическими библиотеками вы должны перестроить библиотеку, а затем повторно подключить всех потребителей, которые очень медленны в Unix-системах и не очень быстро работают в Windows.
Программное обеспечение MacOS также использует «dll», они просто называются по-разному (разделяемые библиотеки).
Dll имеет смысл, если у вас есть код, который вы хотите повторно использовать в разных компонентах вашего программного обеспечения. В основном это имеет смысл в крупных проектах программного обеспечения.
Статическое соединение имеет смысл для небольших однокомпонентных приложений, когда нет необходимости в повторном использовании кода. Это упрощает распространение, поскольку ваш компонент не имеет внешних зависимостей.
Да, смотрите этот text:
Динамическая компоновка имеет следующие преимущества :
Сохраняет память и уменьшает обменивать. Многие процессы могут использовать одну DLL одновременно, , используя единую копию DLL в памяти . В отличие от этого, Windows должна загрузить копию кода библиотеки в память для каждого приложения, которое построено со статической библиотекой ссылок.
Сохраняет дисковое пространство. Многие приложения могут делить одну копию DLL на диск . Напротив, каждое приложение , построенное со статической библиотекой ссылок, имеет код библиотеки, связанный с его исполняемым изображением в виде отдельной копии .
Обновление до DLL проще. Когда изменяются функции в DLL , приложения, которые их используют , не нуждаются в повторной компиляции или возвращаются до тех пор, пока функции аргументов и возвращаемых значений не изменяются . Напротив, связанный с объектом объектный код требует, чтобы приложение было повторно подключено при изменении функций .
Предоставляет послепродажную поддержку. Например, драйвер DLL дисплея может быть изменен до . Поддерживается дисплей, который не был , если приложение было отправлено .
Поддерживает многоязычные программы . Программы, написанные в , могут быть разными типами языков программирования , вызывающими одну и ту же функцию DLL, если программы следуют правилам вызова . Программы и функция DLL должны быть совместимы в следующих способы: порядок, в котором функции ожидает, что ее аргументы быть в стек, является ли ответственностью за очистку стеки функции или приложения, и передаются ли какие-либо аргументы в регистры.
Предоставляет механизм для расширения классов библиотеки MFC. Вы можете получить классы из существующих классов MFC и поместить их в библиотеку расширения MFC для использования приложениями MFC .
Освобождает создание международных версий. Путем размещения ресурсов в DLL, гораздо проще создать международные версии приложения . Вы можете поместить строки для каждой языковой версии вашего приложения в отдельный ресурс DLL и на другом языке версии загружают соответствующие ресурсы .
Потенциал Недостаток использования DLL заключается в том, что приложение не является самодостаточным; он зависит от наличия отдельного DLL-модуля .
Некоторые из этих причин имели смысл много лет назад, когда дисковое пространство было дорогостоящим. Мало кто делает сейчас. Я лично предпочитаю связывать свои приложения статически, когда это возможно. – 2009-06-02 11:43:48
Но в крупных корпоративных системах более эффективно иметь отдельные модули, вы должны согласиться? – lsalamon
Более эффективный с точки зрения чего? – 2009-06-02 12:28:26
Помимо использования памяти/дискового пространства, еще одно важное преимущество использования разделяемых библиотек является то, что обновления библиотеки будет автоматически подобран всеми программами в системе, использующей библиотеку.
Когда в библиотеках ZIP InfoZIP была обнаружена уязвимость системы безопасности, обновление для DLL/.so автоматически сделало все программное обеспечение безопасным, которое их использовало. Программное обеспечение, которое было связано статически, должно быть перекомпилировано.
Это обычно рассматривается как недостаток - когда-либо слышал о «DLL Hell»? – 2009-06-02 11:45:55
Да, но в основном в связи с MS Windows. Насколько я могу судить, это произошло потому, что у MS Windows (раньше) отсутствовал надлежащий центральный менеджер пакетов/программ, как и в большинстве систем Linux/BSD. Без отслеживания Dependency, предоставляемого менеджером пакетов, DLL-ад действительно является проблемой. Но я полагал, что современные версии Windows обратились к этому. – sleske
Yup - это теперь обрабатывается SxS (рядом) установка DLL. Теперь может быть несколько копий, поэтому классическая проблема с DLL (переписывание DLL старой версией) больше не должна произойти. – MSalters
Windows все еще использует библиотеки DLL и Mac, похоже, вообще не использует DLL. Являются ли они преимуществами или недостатками использования любой техники?
Оба используют общие библиотеки, они просто используют другое имя.
Если установка программы включает в себя всю требуемую DLL, чтобы она работала на 100% хорошо, будет ли она такой же, как статическая привязка всех библиотек?
В некоторой степени. Когда вы статически связываете библиотеки с программой, вы получите один очень большой файл с DLL, у вас будет много файлов.
Статически связанный файл не будет нуждаться в шаге «разрешенные общие библиотеки» (который происходит во время загрузки программы). Давным-давно, загрузка статической программы означала, что вся программа была сначала загружена в ОЗУ, а затем шаг шага «Разрешить разделяемые библиотеки». Сегодня только по заказу загружаются только те части программы, которые фактически исполняются. Таким образом, с помощью статической программы вам не нужно разрешать DLL. С DLL, вам не нужно загружать их все сразу. Так что умение работать, они должны быть на уровне.
Который оставляет «DLL Hell». Многие программы в Windows приносят все DLL-файлы, которые им нужны, и записывают их в каталог Windows. Чистый эффект заключается в том, что последние установленные программы работают, и все остальное может быть нарушено. Но есть обходное решение: установите DLL в тот же каталог, что и EXE. Сначала Windows будет искать текущий каталог, а затем различные пути Windows. Таким образом, вы потратите немного места на диске, но ваша программа будет работать, и, что более важно, вы больше ничего не сломаете.
Можно утверждать, что вы не должны устанавливать DLL-файлы, которые уже существуют (с той же версией) в каталоге Windows, но затем вы снова уязвимы для какого-либо плохого приложения, которое перезаписывает версию, которая вам нужна, с чем-то, что нарушает вашу шея. Недостатком является то, что вы должны сами распространять исправления безопасности для своего приложения; вы не можете полагаться на Windows Update или подобные вещи, чтобы защитить свой код. Это плотное место; крекеры делают много денег из проблем безопасности, и люди не будут вам нравиться, когда кто-то украдет их банковские данные, потому что вы не выпустили исправления безопасности достаточно скоро.
Если вы планируете поддерживать приложение очень плотно для многих, скажем, 20 лет, установка всех DLL в каталоге программы для вас. Если нет, напишите код, который проверяет, что установлены подходящие версии всех DLL, и сообщите об этом пользователю, поэтому они знают, почему ваше приложение внезапно начинает сбой.
С моей точки зрения, общий компонент имеет некоторые преимущества, которые иногда представляют собой недостатки.
Поэтому я считаю, что использование общих копонентов поможет программному обеспечению лучше организоваться.
Возможный дубликат [Когда использовать динамические и статические библиотеки] (http://stackoverflow.com/questions/140061/when-to-use-dynamic-vs-static-libraries) –