В чем проблема с DLL и реестром?

Я смотрел основной доклад WWDC 2009, и мне стало любопытно, что кто-то сказал о Windows 7/Vista.

Докладчик заявил, что 7 по-прежнему остается плохой операционной системой, поскольку в ней используются те же технологии, такие как библиотеки DLL и реестр. Насколько точны его утверждения и насколько отличается OS X? Даже в OS X есть динамически загружаемые библиотеки, верно? Я думаю, что дело с реестром может иметь некоторый вес.

Может ли кто-нибудь объяснить мне различия в стратегии каждой ОС?

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

Спасибо,

креб


macos operating-system windows dll registry
person krebstar    schedule 10.06.2009    source источник
comment
Итак, в любом случае, я думаю, вопрос остается в силе. Если dll и реестры хуже, что делает их таковыми? Что использует os x, что превосходит DLL и реестры, если то, что сказал представитель, верно?   -  person krebstar    schedule 10.06.2009

Ответы (3)


arrow_upward
5
arrow_downward

DLL

Основное различие между OS X и Windows заключается в том, что Windows исторически пыталась сэкономить место/память, заставляя всех совместно использовать код (т. е. вы устанавливаете одну DLL, каждый может ее использовать). Apple статически компилирует (ну, не совсем так, но вполне может быть) все несистемные библиотеки в каждое приложение. Пустая трата места на диске/памяти, но делает развертывание приложения намного проще и устраняет проблемы с версиями.

Реестр

В OS X действительно есть реестр, это просто плоские файлы, называемые plists, а не волшебный компонент, который в основном похож на файловую систему, за исключением тех случаев, когда это не так. Подход Apple упрощает перенос настроек с одного компьютера на другой, в то время как подход Windows работает быстрее в памяти и позволяет приложениям легко «отслеживать» ключ без больших потерь производительности (т. е. одно приложение меняет ключ, а другое). сразу узнает об этом).

В заключение

Докладчик полон этого, 10.6 в основном тот же код, что и 10.5, который был в основном тем же кодом, что и 10.4 и другие, точно так же, как Win7 — это в основном Vista, а это в основном Server '03 и т. д. далеко слишком много проверенного кода в операционной системе, чтобы выбрасывать его в каждом выпуске, особенно если вы действительно хотите, чтобы приложения ваших клиентов работали.

person Ana Betts    schedule 11.06.2009
comment
Спасибо, это было очень ясно .. :) Принимаю это как лучший ответ, хотя ответ Барри Уорка тоже хорош .. - person krebstar; 11.06.2009
comment
Неверно утверждать, что все несистемные библиотеки статически связаны с пакетами приложений в OS X. Хотя пакеты приложений могут содержать фреймворки (динамически связанные библиотеки), а некоторые действительно объединяют несистемные фреймворки, также можно установить фреймворки в общесистемную или общепользовательскую папку Library/Frameworks, где они могут использоваться многими приложениями. Приложения OS X, которые нельзя установить методом перетаскивания (т. е. им требуется полная программа установки), обычно используют программу установки для установки этих платформ. - person Barry Wark; 11.06.2009
comment
Для всех практических намерений и целей единственными людьми, которые могут создавать фреймворки, является Apple, иначе каждое приложение становится файлом .pkg. - person Ana Betts; 11.06.2009
comment
Неправильно. Любой разработчик может создавать фреймворки. Эти фреймворки могут быть установлены для всей системы в /Library/Frameworks или для всего пользователя в ~/Library/Frameworks. Их можно установить с помощью установочного пакета (.pkg) или путем перетаскивания. Apple резервирует папку /System/Library/Frameworks для себя, но это единственное ограничение. - person Barry Wark; 12.06.2009
comment
Вы меня неправильно понимаете. Вы по-прежнему на 100 % правы в том, что вы можете создавать фреймворки. Итак, вы создаете SuperAwesome.Framework. Теперь, как я, как обычный разработчик приложений, могу использовать общую версию в своем продукте (т. е. не делать копию в своем приложении .App)? - person Ana Betts; 12.06.2009
comment
Фреймворки имеют свойство пути установки (установленное во время сборки или с помощью otool), которое сообщает динамическому компоновщику, какой путь вставить в двоичный файл компоновки, чтобы сообщить динамическому компоновщику, где найти фреймворк во время выполнения. Таким образом, если SuperAwesome.framework имеет путь установки @executable_path/../Frameworks, что указывает на то, что он должен быть установлен в пакете приложений, то связывающее приложение скопирует фреймворк в свой пакет. Если бы у фреймворка был путь установки /Library/Frameworks, то приложение использовало бы фреймворк оттуда (т. е. совместно). - person Barry Wark; 12.06.2009
comment
...очевидно, SuperAwesome.framework должен быть установлен в /Library/Frameworks, иначе связывающее приложение вылетит при запуске. - person Barry Wark; 12.06.2009
comment
И как вы гарантируете, что установлен SuperAwesome.framework, чтобы приложения ваших клиентов не зависали? - person Ana Betts; 12.06.2009
comment
Как бы вы поступили в Windows, не попадая в ад DLL? Я не думаю, что это действительно вопрос платформы, поскольку обе платформы могут использовать оба подхода к распространению своих общих библиотек. - person nschmidt; 17.06.2009

arrow_upward
8
arrow_downward

Конечно, обе операционные системы имеют средства для использования библиотек DLL (они называются dylibs или Frameworks в OS X в зависимости от того, как они упакованы). несколько их версий, плавающих вокруг. Фреймворки, с другой стороны, на самом деле представляют собой структуру каталогов. Они содержат динамически связанные библиотеки (возможно, несколько их версий), ресурсы, заголовки, документацию и т. д. Динамический компоновщик в OS X автоматически обрабатывает выбор правильной версии библиотеки из фреймворка для каждого исполняемого файла. Похоже, что система работает лучше, чем управление DLL в Windows, которое, ну, все еще довольно беспорядочно (конечно, система Windows связана с устаревшими проблемами, которые Apple отбросила при переходе на OS X). Справедливости ради следует отметить, что в Unix уже давно есть решение этой проблемы, а также использование символических ссылок для привязки dylib к их правильной версионной реализации, что позволяет устанавливать несколько версий.

В OS X нет эквивалента реестра Windows. Это и хорошо и плохо. Хорошая сторона заключается в том, что гораздо сложнее повредить всю систему OS X с ошибкой реестра. Вместо этого OS X хранит конфигурацию во многих отдельных файлах, обычно по одному или несколько для каждого приложения, пользователя и т. д. Эти файлы обычно представляют собой файл в формате plist (схема XML, представляющая словари, массивы и примитивные типы). Плохая сторона заключается в том, что, сохраняя это наследие Unix-y, OS X не имеет тех же инструментов über-admin, которые могут рыться в реестре и делать всевозможные сумасшедшие вещи.

person Barry Wark    schedule 10.06.2009

arrow_upward
-4
arrow_downward

DLL - это плохие варианты библиотек, поскольку они не могут работать сами по себе, для их использования вызывается дополнительный исполняемый файл-оболочка (автоматически), что добавляет ненужные накладные расходы и значительно затрудняет определение того, какие библиотеки на самом деле используются. Еще одним менее важным недостатком является неспособность систем по-настоящему совместно использовать библиотеку. * системы nix избегают этого, поскольку библиотеки существуют на верхнем уровне, работающие сами по себе или в более крупной оболочке (например, kde-init ), библиотеки могут совместно использоваться любыми приложениями, что означает, что требуется только одна копия каждой библиотеки, и вы можете в любое время с легкостью убить одну библиотеку по мере необходимости.

Реестр - отличная идея, за исключением того факта, что он используется так часто, что почти все, что вы устанавливаете, будет использовать реестр, а поврежденный реестр сделает вашу операционную систему почти полностью бесполезной, пока она не будет исправлена. Этого можно избежать в системах *nix за счет наличия нескольких разных файлов для разного контента, обращения к драйверам через конфигурационный файл Xorg, установленные приложения будут записываться в свою собственную базу данных, а ключи или идентификаторы часто записываются в каталог, а не в единый универсальный файл. Это снижает вероятность серьезного сбоя и означает, что в любое время вы, вероятно, все еще можете отремонтировать систему. Если Xorg поврежден, вы просто переконфигурируете его, если повреждена база данных установленных приложений, вы можете восстановить или перестроить ее, а если каталог отдельных настроек приложений поврежден, вам нужно переустановить только одно приложение (и большинство хороших коммерческих приложений должны иметь способ восстановления это в любом случае)

person scragar    schedule 10.06.2009
comment
Извините, я думал, что можно поделиться DLL? Хм.. =/ В любом случае спасибо за ответ :) - person krebstar; 10.06.2009
comment
На самом деле, использование библиотек DLL не требует никаких исполняемых файлов-оболочек, они используются непосредственно приложениями. Кроме того, приложения, безусловно, могут совместно использовать библиотеки DLL. Примером совместного использования являются системные библиотеки DLL Windows или сборки .NET GAC. - person Bojan Resnik; 10.06.2009
comment
Комментарии здесь о DLL очень неверны. DLL могут (и часто) полностью распределяться между процессами. - person Foredecker; 13.06.2009