Итак, DLL похожа на папку, но она позволяет нескольким программам / исполняемым файлам получать к ней доступ одновременно, тем самым сохраняя память (я думаю).
Что является эквивалентом DLL для Mac? Я просматривал папки Google Chrome в ~/Library/Application Support , и вместо обычного Windows Default.dll была просто папка "Default" в виде обычного файла, содержание которого, я полагаю, будет регулярно находиться внутри DLL.
Эквивалент Mac обеспечивает ту же функцию?
Эквивалентами Windows DLL на OS X являются Frameworks (Какао) или dylibs (BSD). Поставляемые системой находятся в /usr/lib и /System/Library/Frameworks соответственно.
Папка, которую вы упоминаете, Library/Application Support похожа на Application Data (или AppRoaming сейчас?) папки в Windows, содержащие личные настройки ваших приложений.
Хотя я не знаю, что эквивалентно Chrome default.dll в OS X, пакет приложений содержит следующее:
Судя по размеру, похоже, что Google Chrome Framework может быть важен (папка Frameworks чуть выше не представляет особого интереса)
Там нет реальных DLL в OS X, Linux или любой POSIX в этом отношении. Они не делают различия.
Зачем?
С одной стороны, многие вещи Mac самодостаточны (в конце концов .app - это просто папки).
Двоичные файлы в Mac OS X (и Linux и других * Nixes) используют ELF (что означает «Исполняемый файл» и «Формат библиотеки») как для библиотек, так и для исполняемых файлов.
Файл по умолчанию, который вы там нашли, был, вероятно, двоичным файлом ELF.
Обновление: dmckee указывает, что .dylibs имеют формат Mach-O , эксклюзивный для Mac. Однако их трудно различить по виду, потому что ни один из них на самом деле не требует расширения.
Ближайшие эквиваленты Linux и Mac называются "общими объектными файлами" (обычно с расширением .so) и динамическими библиотеками (обычно с расширением .dylib) соответственно.
Общие объекты широко используются в типичных системах Linux. Динамические библиотеки не так распространены повсеместно, поскольку формат .app обеспечивает очень безопасный механизм распространения для поддержки нескольких архитектур за счет более крупных "файлов", которые можно было бы извлечь.
