Библиотека (вычисления)

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

Иллюстрация приложения, которое использует libvorbisfile для воспроизведения файла Ogg Vorbis

В информатике библиотека представляет собой набор энергонезависимых ресурсов, используемых компьютерные программы, часто для разработки программного обеспечения. Сюда могут входить данные конфигурации, документация, справочные данные, шаблоны сообщений, предварительно написанный код и подпрограммы, классы, значения или тип. В IBM OS / 360 и ее преемниках они упоминаются как многораздельные наборы данных.

A библиотека также представляет собой набор реализаций поведения, написанных в терминах языка, который имеет четко определенный интерфейс , с помощью которого вызывается поведение. Например, люди, которые хотят написать программу более высокого уровня, могут использовать библиотеку для выполнения системных вызовов вместо того, чтобы выполнять эти системные вызовы снова и снова. Кроме того, поведение предусмотрено для повторного использования несколькими независимыми программами. Программа вызывает поведение, предоставляемое библиотекой, через механизм языка. Например, в простом императивном языке, таком как C, поведение в библиотеке вызывается с помощью обычного вызова функции C. Что отличает вызов от функции библиотеки от вызова другой функции в той же программе, так это способ организации кода в системе.

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

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

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

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

Содержание
  • 1 История
  • 2 Связывание
  • 3 Перемещение
  • 4 Статические библиотеки
  • 5 Общие библиотеки
    • 5.1 Совместное использование памяти
    • 5.2 Динамическое связывание
    • 5.3 Оптимизация
    • 5.4 Поиск библиотек во время выполнения
      • 5.4.1 Microsoft Windows
      • 5.4.2 OpenStep
      • 5.4.3 Unix-подобные системы
    • 5.5 Динамическая загрузка
  • 6 Библиотеки объектов и классов
  • 7 Удаленный библиотеки
  • 8 Библиотеки генерации кода
  • 9 Именование файлов
    • 9.1 Большинство современных Unix-подобных систем
    • 9.2 macOS
    • 9.3 Microsoft Windows
  • 10 См. также
  • 11 Примечания
  • 12 Ссылки
  • 13 Дополнительная литература
История

Самые ранние концепции программирования, аналогичные библиотекам, предназначались для отделения определений данных от программ реализации. JOVIAL привлек внимание общественности к концепции COMPOOL (коммуникационный пул) в 1959 году, хотя он перенял идею из программного обеспечения для больших систем SAGE. Следуя принципам информатики разделения задач и сокрытия информации, «Целью Comm Pool было разрешить совместное использование системных данных между многими программами путем предоставления централизованного описания данных» <329.>COBOL также включал «примитивные возможности для библиотечной системы» в 1959 году, но Жан Саммет ретроспективно охарактеризовал их как «неадекватные библиотечные возможности»

. Концепция библиотеки возникла в форме подпрограммы нововведения FORTRAN. Подпрограммы FORTRAN могут компилироваться независимо друг от друга, но в компиляторе отсутствовал линкер . Поэтому до введения модулей в Fortran-90 проверка типов между подпрограммами FORTRAN была невозможна.

Наконец, историки концепции должны помнить о влиятельном Simula 67. Simula была первым языком объектно-ориентированного программирования, и его классы были почти идентичны современной концепции, используемой в Java, C ++ и C #. Концепция классов Simula была также прародителем пакета в Ada и модуля Modula-2. Даже при первоначальной разработке в 1965 году классы Simula могли быть включены в файлы библиотек и добавлены во время компиляции.

Связывание

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

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

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

Перемещение

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

Статические библиотеки

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

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

Общие библиотеки

A общая библиотека или общий объект - это файл, который предназначен для совместного использования исполняемыми файлами и другими файлами общих объектов. Модули, используемые программой, загружаются из отдельных общих объектов в память во время загрузки или времени выполнения, а не копируются компоновщиком, когда он создает для программы один монолитный исполняемый файл.

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

Большинство современных операционных систем могут иметь файлы разделяемых библиотек того же формата, что и исполняемые файлы. Это дает два основных преимущества: во-первых, требуется сделать только один загрузчик для обоих, а не два (считается, что наличие одного загрузчика стоит его дополнительной сложности). Во-вторых, это позволяет также использовать исполняемые файлы в качестве разделяемых библиотек, если они имеют таблицу символов. Типичными объединенными форматами исполняемых файлов и разделяемых библиотек являются ELF и Mach-O (оба в Unix) и PE (Windows).

В некоторых старых средах, таких как 16-битная Windows или MPE для HP 3000, разрешались только данные на основе стека (локальные) в коде совместно используемых библиотек, либо были наложены другие существенные ограничения на код совместно используемых библиотек.

Совместное использование памяти

Код библиотеки может совместно использоваться в памяти несколькими процессами , а также на диске. Если используется виртуальная память, процессы будут выполнять одну и ту же физическую страницу ОЗУ, которая отображается в разные адресные пространства процессов. В этом есть свои преимущества. Например, в системе OpenStep приложения часто имели размер всего несколько сотен килобайт и загружались быстро; большая часть их кода находилась в библиотеках, которые уже были загружены операционной системой для других целей.

Программы могут выполнять совместное использование ОЗУ с помощью позиционно-независимого кода, как в Unix, что приводит к сложной, но гибкой архитектуре, или за счет использования общих виртуальных адресов, как в Windows и OS / 2. Эти системы с помощью различных уловок, таких как предварительное отображение адресного пространства и резервирование слотов для каждой разделяемой библиотеки, гарантируют, что этот код имеет большую вероятность совместного использования. Третья альтернатива - одноуровневое хранилище, используемое в IBM System / 38 и его преемниках. Это допускает позиционно-зависимый код, но не накладывает существенных ограничений на то, где код может быть размещен или как он может быть разделен.

В некоторых случаях разные версии разделяемых библиотек могут вызывать проблемы, особенно когда библиотеки разных версий имеют одно и то же имя файла, а для разных приложений, установленных в системе, требуется определенная версия. Такой сценарий известен как DLL hell в честь Windows и OS / 2 DLL-файла. Большинство современных операционных систем после 2001 г. имеют методы очистки для устранения таких ситуаций или используют "частные" библиотеки для конкретных приложений.

Динамическое связывание

Динамическое связывание или позднее связывание связывание выполняется во время загрузки программы (время загрузки ) или выполнения (время выполнения ), а не при создании исполняемого файла. Динамически подключаемая библиотека (библиотека с динамической компоновкой или DLL в Windows и OS / 2 ; динамический общий объект или DSO в Unix -like systems) - библиотека, предназначенная для динамической компоновки. Компоновщик выполняет лишь минимальный объем работы при создании исполняемого файла; он только записывает, какие библиотечные процедуры нужны программе, а также имена индексов или номера подпрограмм в библиотеке. Большая часть работы по связыванию выполняется во время загрузки приложения (время загрузки) или во время выполнения (время выполнения). Обычно необходимая программа компоновки, называемая «динамическим компоновщиком» или «загрузчиком компоновки», фактически является частью базовой операционной системы. (Однако возможно, и не очень сложно, написать программу, которая использует динамическое связывание и включает свой собственный динамический компоновщик, даже для операционной системы, которая сама по себе не поддерживает динамическое связывание.)

Первоначально программисты разработали динамическое связывание в операционной системе Multics, начиная с 1964 года, и MTS (Michigan Terminal System ), созданной в конце 1960-х.

Оптимизация

Поскольку разделяемые библиотеки в большинстве систем меняются нечасто, системы могут вычислить вероятный адрес загрузки для каждой разделяемой библиотеки в системе до того, как она понадобится, и сохранить эту информацию в библиотеках и исполняемых файлах. Если каждая загруженная совместно используемая библиотека прошла этот процесс, каждая из них будет загружаться по своему заранее определенному адресу, что ускоряет процесс динамического связывания. Эта оптимизация известна как предварительное связывание в macOS и предварительное связывание в Linux. К недостаткам этого метода относятся время, необходимое для предварительного вычисления этих адресов каждый раз при изменении разделяемых библиотек, невозможность использования рандомизации макета адресного пространства и требование достаточного виртуального адресного пространства для использования (проблема, которая будет облегчается принятием 64-битных архитектур, по крайней мере, на данный момент).

Поиск библиотек во время выполнения

Загрузчики для общих библиотек сильно различаются по функциональности. Некоторые зависят от исполняемого файла, хранящего явные пути к библиотекам. Любое изменение наименования библиотеки или макета файловой системы приведет к сбою этих систем. Чаще всего в исполняемом файле хранится только имя библиотеки (а не путь), а операционная система предоставляет метод поиска библиотеки на диске на основе некоторого алгоритма.

Если общая библиотека, от которой зависит исполняемый файл, будет удалена, перемещена или переименована, или если несовместимая версия библиотеки скопирована в место, которое было ранее в поиске, исполняемый файл не загрузится. Это называется адом зависимостей и существует на многих платформах. (Печально известный) вариант Windows широко известен как DLL hell. Эта проблема не может возникнуть, если каждая версия каждой библиотеки имеет уникальный идентификатор и каждая программа ссылается на библиотеки только по их полным уникальным идентификаторам. Проблемы с «адом DLL» в более ранних версиях Windows возникали из-за использования только имен библиотек, уникальность которых не гарантировалась, для разрешения динамических ссылок в программах. (Чтобы избежать «ада с DLL», более поздние версии Windows в значительной степени полагаются на возможности программ для установки частных DLL - по сути, частичный отказ от использования общих библиотек - наряду с механизмами предотвращения замены общих системных библиотек DLL более ранними версиями.)

Microsoft Windows

Microsoft Windows проверяет реестр, чтобы определить правильное место для загрузки DLL, которые реализуют COM-объекты, но для других DLL это проверит каталоги в определенном порядке. Сначала Windows проверяет каталог, в который загружена программа (частная DLL); любые каталоги, установленные вызовом функции SetDllDirectory (); каталоги System32, System и Windows; затем текущий рабочий каталог; и, наконец, каталоги, указанные в переменной среды PATH . Приложения, написанные для платформы .NET Framework (с 2002 г.), также проверяют Global Assembly Cache как основное хранилище общих файлов dll, чтобы устранить проблему DLL hell.

OpenStep

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

Unix-подобные системы

Большинство Unix-подобных систем имеют "путь поиска", определяющий каталоги файловой системы, в которых следует искать динамические библиотеки. Некоторые системы указывают путь по умолчанию в файле конфигурации , другие жестко записывают его в динамический загрузчик. Некоторые форматы исполняемых файлов могут указывать дополнительные каталоги, в которых следует искать библиотеки для конкретной программы. Обычно это можно переопределить с помощью переменной среды , хотя она отключена для программ setuid и setgid, так что пользователь не может заставить такую ​​программу запускать произвольный код с правами root.. Разработчикам библиотек рекомендуется размещать свои динамические библиотеки в местах пути поиска по умолчанию. С другой стороны, это может сделать установку новых библиотек проблематичной, и эти «известные» местоположения быстро становятся домом для растущего числа файлов библиотеки, что усложняет управление.

Динамическая загрузка

Динамическая загрузка, подмножество динамического связывания, включает в себя загрузку и выгрузку динамически связанной библиотеки в среде выполнения по запросу. Такой запрос может быть сделан явно или неявно. Неявные запросы выполняются, когда компилятор или статический компоновщик добавляет ссылки на библиотеки, которые включают пути к файлам или просто имена файлов. Явные запросы выполняются, когда приложения делают прямые вызовы API операционной системы.

Большинство операционных систем, поддерживающих динамически подключаемые библиотеки, также поддерживают динамическую загрузку таких библиотек через время выполнения компоновщик API. Например, Microsoft Windows использует функции API LoadLibrary, LoadLibraryEx, FreeLibraryи GetProcAddressс Библиотеки Microsoft Dynamic Link ; Системы на основе POSIX, включая большинство UNIX и UNIX-подобных систем, используют dlopen, dlcloseи dlsym. Некоторые системы разработки автоматизируют этот процесс.

Библиотеки объектов и классов

Несмотря на то, что изначально динамическое связывание было впервые применено в 1960-х годах, в операционных системах, используемых потребителями, до конца 1980-х гг. К началу 1990-х годов он был доступен в той или иной форме в большинстве операционных систем. В тот же период объектно-ориентированное программирование (ООП) стало важной частью среды программирования. ООП с привязкой во время выполнения требует дополнительной информации, которую традиционные библиотеки не предоставляют. Помимо имен и точек входа кода, расположенных внутри, им также требуется список объектов, от которых они зависят. Это побочный эффект одного из основных преимуществ ООП - наследования, что означает, что части полного определения любого метода могут находиться в разных местах. Это больше, чем просто перечисление того, что одна библиотека требует услуг другой: в настоящей системе ООП сами библиотеки могут быть неизвестны во время компиляции и варьироваться от системы к системе.

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

Вскоре большинство производителей мини-компьютеров и мэйнфреймов инициировали проекты по их объединению, создавая формат библиотеки ООП, который можно было использовать где угодно. Такие системы были известны как библиотеки объектов или распределенные объекты, если они поддерживали удаленный доступ (не все поддерживали). Microsoft COM является примером такой системы для локального использования. DCOM, модифицированная версия COM, поддерживает удаленный доступ.

Некоторое время объектные библиотеки имели статус «следующей большой вещи» в мире программирования. Был предпринят ряд попыток создать системы, которые могли бы работать на разных платформах, и компании соревновались, пытаясь запереть разработчиков в их собственных системах. Примеры включают IBM Системную объектную модель (SOM / DSOM), Sun Microsystems 'Распределенные объекты везде (DOE), Портативные распределенные объекты (PDO) от NeXT, Цифровые, Компонентная объектная модель от Microsoft (COM / DCOM) и любое количество Системы на основе CORBA.

После того, как маркетинговая шумиха остыла, объектные библиотеки продолжали использоваться как в объектно-ориентированном программировании, так и в распределенных информационных системах. Библиотеки классов являются приблизительным эквивалентом ООП старых типов библиотек кода. Они содержат классы, которые описывают характеристики и определяют действия (методы ), связанные с объектами. Библиотеки классов используются для создания экземпляров или объектов с их характеристиками, установленными на определенные значения. В некоторых языках ООП, таких как Java, различие очевидно: классы часто содержатся в файлах библиотеки (например, Java формат файла JAR ), а созданные объекты находятся только в памяти (хотя потенциально можно сделать постоянным в отдельных файлах). В других случаях, таких как Smalltalk, библиотеки классов являются просто отправной точкой для образа системы, который включает в себя все состояние среды, классов и всех созданных объектов.

Удаленные библиотеки

Другое решение проблемы с библиотекой заключается в использовании полностью отдельных исполняемых файлов (часто в некоторой облегченной форме) и их вызове с помощью удаленного вызова процедуры (RPC) по сети на другой компьютер. Такой подход максимизирует повторное использование операционной системы: код, необходимый для поддержки библиотеки, - это тот же код, который используется для обеспечения поддержки приложений и безопасности для всех остальных программ. Кроме того, такие системы не требуют наличия библиотеки на том же компьютере, но могут пересылать запросы по сети.

Однако такой подход означает, что каждый вызов библиотеки требует значительных накладных расходов. Вызовы RPC намного дороже, чем вызов разделяемой библиотеки, которая уже была загружена на тот же компьютер. Этот подход обычно используется в распределенной архитектуре, которая интенсивно использует такие удаленные вызовы, особенно в системах клиент-сервер и серверах приложений, таких как Enterprise JavaBeans.

Генерация кода. библиотеки

Библиотеки генерации кода - это высокоуровневые API, которые могут генерировать или преобразовывать байтовый код для Java. Они используются аспектно-ориентированным программированием, некоторыми структурами доступа к данным и для тестирования для создания динамических прокси-объектов. Они также используются для перехвата доступа к полям.

Именование файлов

Большинство современных Unix-подобных систем

В системе хранится libfoo.a Файлыи libfoo.soв таких каталогах, как / lib, / usr / libили / usr / local / lib. Имена файлов всегда начинаются с libи заканчиваются суффиксом .a(архив, статическая библиотека) или .so(общий объект, динамически подключаемая библиотека). Некоторые системы могут иметь несколько имен для динамически подключаемой библиотеки, при этом большинство имен являются именами для символических ссылок на оставшееся имя; эти имена могут включать основную версию библиотеки или полный номер версии; например, в некоторых системах libfoo.so.2будет именем файла для второй основной версии интерфейса динамически подключаемой библиотеки libfoo. Файлы .la, которые иногда встречаются в каталогах библиотек, представляют собой архивы libtool, которые не могут использоваться системой как таковые.

macOS

Система наследует соглашения о статической библиотеке от BSD, при этом библиотека хранится в файле .a, и может использовать .soдинамически подключаемых библиотек (с суффиксом .dylibвместо этого). Однако большинство библиотек в macOS состоят из «фреймворков», помещенных в специальные каталоги, называемые «bundles », в которых хранятся необходимые файлы и метаданные библиотеки. Например, фреймворк MyFrameworkбудет реализован в пакете с именем MyFramework.framework, где MyFramework.framework / MyFrameworkбудет либо динамически связанным файлом библиотеки, либо символическая ссылка на файл динамически подключаемой библиотеки в MyFramework.framework / Versions / Current / MyFramework.

Microsoft Windows

Библиотеки с динамической компоновкой обычно имеют суффикс *.DLL, хотя другие расширения имен файлов могут определять динамически подключаемые библиотеки специального назначения, например *.OCXдля OLE библиотек. Версии интерфейса либо закодированы в именах файлов, либо абстрагируются с помощью интерфейсов COM-объекта. В зависимости от того, как они компилируются, файлы *.LIBмогут быть либо статическими библиотеками, либо представлениями динамически связываемых библиотек, необходимых только во время компиляции, известных как «библиотеки импорта ». В отличие от мира UNIX, который использует разные расширения файлов, при компоновке с файлом .LIBв Windows нужно сначала узнать, является ли это обычной статической библиотекой или библиотека импорта. В последнем случае во время выполнения должен присутствовать файл .DLL.

См. Также
Примечания
Ссылки
Дополнительная литература

Последняя правка сделана 2021-05-27 08:25:44
Содержание доступно по лицензии CC BY-SA 3.0 (если не указано иное).
Обратная связь: support@alphapedia.ru
Соглашение
О проекте