Эта статья представляет собой смесь высокоуровневого глянца и выборки мельчайших деталей. В ней мало говорится о традиционных библиотеках (я просто добавил пару предложений вверху). Частично из-за этого в ней есть некоторые неточности и потенциал для людей неправильно понимать то, что является точным. Я думаю, ее нужно переработать в структуру, похожую на эту:
- Что такое библиотеки и их цели [модульность, повторное использование кода и т. д.]
- История
- Типы библиотек сегодня
- Необходимы любые мельчайшие подробности.
Мне нравится ваша работа, поэтому я вас поощряю продолжать. Daniel.Cardenas 13:39, 17 июля 2006 (UTC) [ ответить ]
Действительно - неужели никто не может объяснить это более доступно для неспециалистов? Для большинства читателей это абракадабра.-- 173.69.135.105 ( talk ) 00:52, 26 октября 2011 (UTC) [ ответить ]
В этой статье есть пример, но нет никакого описания примера, и это сбивает с толку. — Предыдущий неподписанный комментарий, добавленный Gachen (обсуждение • вклад ) 13:44, 24 июня 2012 (UTC) [ ответить ]
=============
Я согласен с пометкой "необходимо прояснить" в первом предложении. Хотя это очень общее, я думаю, что оно будет довольно непрозрачным для большинства читателей. Я бы предложил что-то не такое общее, но гораздо более конкретное:
В информатике библиотека — это набор процедур, доступных для использования в нескольких программах.
(Хотя я гораздо более сомневаюсь, что редакторы захотят включить текст вроде следующего) это также может быть полезно:
Термин возник по аналогии с традиционной библиотекой, которая выдает книги многим посетителям. В традиционной библиотеке Когда один посетитель заканчивает пользоваться книгой, он возвращает ее, и ею может воспользоваться другой посетитель. (Конечно, для библиотека компьютерных процедур, обычно нет необходимости программам ждать своей очереди. Любое количество программы могли бы одновременно извлечь копию процедуры для своего использования, и им не нужно "проверить рутину обратно", когда они закончили с ней. Редактирование и изменение рутины - это другое (Мало. Для этой деятельности обычно требуется контроль доступа.)
[1] относится к «карточной библиотеке», которая была на самом деле в первые дни она использовалась во многом так, как использовалась бы традиционная библиотека.
MarkGoldfain ( обсуждение ) 23:32, 12 июля 2013 (UTC) [ ответ ]
Ссылки
- ^ Дж. Донован, в Системном программировании (C) 1972, McGraw-Hill, стр. 8
=============
Я перенес это из статьи, так как это действительно сюда относится:
- Интерфейс прикладного программирования
- отношения между компоновщиками , загрузчиками , динамически подключаемой библиотекой , статически подключаемой библиотекой , двоичным интерфейсом приложения
- Распространенные стили организации библиотек ( наборы инструментов GUI , фреймворки структур/коллекций данных , библиотеки ввода-вывода, комбинаторы функционального программирования , протоколы метапрограммирования и т. д.)
- Может быть, раздел о предварительной привязке?
- Необходимо упомянуть библиотеки шаблонов или обобщенное программирование , где большая часть (если не весь) библиотечного кода находится в заголовочных файлах. Это отличается от статических библиотек, поскольку библиотечный код напрямую включен (и, следовательно, переплетен) с пользовательским кодом.
— Frecklefoot 18:36, 18 сентября 2003 (UTC)
Gtfjbl ( обсуждение ) 02:00, 15 апреля 2009 (UTC) [ ответить ]
Я объединил много статей, связанных с библиотекой, здесь. Статья выглядит слишком длинной, но в ней много совпадений. Статью можно сделать компактной. -- Taku 00:36, 22 сентября 2003 (UTC)
Хм, проверяя "что здесь ссылается" из метапрограммирования, я наткнулся на этот доклад. Кто-нибудь хотел бы добавить информацию о том, что такое протокол метапрограммирования? -- Anon
- Протокол в этом контексте означает метод или рабочий процесс . Один протокол метапрограммирования — это прямое метапрограммирование, где программист пишет программу для написания программ. Вторым протоколом может быть генетическое программирование, где программист пишет некоторую форму спецификации, а компьютер пытается создать программу для ее выполнения. Третьим протоколом может быть косвенное метапрограммирование через инструмент метапрограммирования, такой как Bison, где программист пишет спецификацию, которую инструмент использует для генерации программы. Этот третий протокол, вероятно, и есть то, что имелось в виду выше. — Дерек Росс
Являются ли статическое и динамическое связывание подтемами связывания библиотек? Если так, то иерархия полностью перекошена. -- BozMo |talk 15:17, 16 августа 2004 (UTC)
Я думаю, что тема .Net Assemblies также может быть упомянута здесь. Может я ошибаюсь, но разве это не замена коллекциям ActiveX Dll? Пожалуйста, обсудите это здесь. tobias
«Динамические системы компоновки размещают большую часть кода компоновщика в базовой операционной системе, в этом случае он называется загрузчиком».
К чему относится «it» в предложении выше?
- Это должно выглядеть примерно так:
- При динамическом связывании операционная система и ее библиотеки содержат компоновщик времени выполнения, который разрешает динамические ссылки в исполняемых файлах и динамических библиотеках при загрузке приложения. Разрешение динамических ссылок может происходить до начала выполнения приложения или во время выполнения, когда каждая ссылка выполняется впервые. При динамическом связывании термин загрузчик часто является синонимом термина компоновщик.
- Jsmethers 21:52, 6 декабря 2005 (UTC) [ ответить ]
В разделе о динамическом связывании вы говорите:
Системы на базе Unix используют переменную PATH для «мест поиска», которая, как правило, надежна, поскольку PATH редко меняется.
Похоже, вы ссылаетесь на переменную PATH оболочки. Насколько мне известно, ни один из распространенных вариантов UNIX не использует переменную среды PATH для поиска общих объектов (т. е. динамических библиотек). Вместо этого есть: 1. Предопределенные системные пути, настроенные в файлах (например, /etc/ld.so.conf в Linux. Подробнее см. в ldconfig(8)) 2. Возможно, другие переменные среды для переопределения/добавления в каталоги в (1) (например, LD_LIBRARY_PATH, LD_PRELOAD и другие в Linux).
Единственное сходство с PATH в приведенном выше примере заключается в том, что переменные среды, если они определены, обычно имеют формат стандартной переменной PATH, используемой оболочкой Bourne для поиска программ (т. е. имена каталогов, разделенные запятыми).
Помню, что где-то видел список вариаций на эту тему (эквивалентов LD_LIBRARY_PATH в «экзотических» системах, таких как HPUX и AIX), но сейчас не могу его найти. Возможно, хорошим местом для начала поиска будет GNU libtool).
Я добавляю это сюда, потому что не уверен, как редактировать саму статью.
Спасибо. Пенедо 02:35, 28 апреля 2005 г. (UTC)
- Кстати, это было изменено в статье (это не относится к PATH в Unix). Часть этого обсуждения, вероятно, было бы интересно включить. Nils 17:38, 25 октября 2005 (UTC).
- (3) насколько мне известно, также возможны жестко заданные пути к библиотекам в двоичном файле (параметр --rpath или через libtool) 88.159.74.100 09:10, 9 июля 2007 (UTC) [ ответить ]
- Вы имеете в виду "--rpath или его эквивалент, или через libtool" - не все Un*x на планете используют GNU ld; некоторые используют компоновщики, где флаг - "-R", например. Гай Харрис 17:05, 9 июля 2007 (UTC) [ ответить ]
- Динамическая загрузка библиотек появилась в UNIX довольно поздно. Кто-нибудь должен отследить историю этого. Насколько я помню, изначально путь к библиотекам использовался только во время компиляции для указания статических библиотек. DonPMitchell ( talk ) 05:33, 13 января 2008 (UTC) [ reply ]
В Linux переменная окружения LD_LIBRARY_PATH
, а не PATH
, влияет на поиск динамических библиотек [1]. В Mac OS X переменные окружения DYLD_LIBRARY_PATH
и DYLD_FALLBACK_LIBRARY_PATH
влияют на то, как динамический загрузчик ищет библиотеки. Изменение DYLD_LIBRARY_PATH
может сломать систему, так как это может позволить библиотекам в новом пути поиска затмить системные библиотеки; изменение DYLD_FALLBACK_LIBRARY_PATH
, с другой стороны, позволяет динамическому загрузчику находить библиотеки без негативного влияния на систему [2]. ← Майкл Сафян ( обсуждение ) 09:33, 13 января 2008 (UTC) [ ответ ]
LD_LIBRARY_PATH
Первоначально он пришел из динамического механизма связывания SunOS 4.0; этот механизм, вместе с LD_LIBRARY_PATH
, был передан System V Release 4 и, таким образом, Solaris . Linux, FreeBSD и NetBSD также унаследовали его из этих источников, когда они повторно реализовали механизмы разделяемых библиотек SunOS 4.0 и/или SVR4, и он перешел в OpenBSD и DragonFly BSD из BSD, от которых они ответвились. Гай Харрис ( обсуждение ) 19:20, 13 января 2008 (UTC) [ ответ ]
Эта статья хороша. Я хочу поместить ее в иерархию проекта наверх. Нам нужно больше участников, поэтому я продолжу спамить страницы обсуждений статей, подобных этой, пока мы не наберем обороты. Пожалуйста, ПРИСОЕДИНЯЙТЕСЬ сегодня!:
- Computer_Science_Club | CS-WikiProject | CS-Clubhouse | Опубликовано Quinobi 17:05, 12 июля 2005 (UTC) [ ответить ]
Эту статью, вероятно, следует сократить до истории библиотек в информатике в целом и введения в конкретные типы компьютерных библиотек. Информацию о конкретных типах компьютерных библиотек и реализациях библиотек на конкретных платформах, вероятно, следует выделить на других страницах. Например, информацию о статических библиотеках , разделяемых библиотеках и динамических библиотеках следует объединить в соответствующие статьи. Информацию о динамических библиотеках Microsoft следует объединить в соответствующую статью. Jsmethers 02:40, 6 декабря 2005 (UTC) [ ответить ]
День будущей библиотеки еще не наступил и будет феноменальным, во всем мире захочется прочитать Книгу там. Мир выйдет за рамки навигационной прозы предшествующей космологической партикулярности Скорпионов, которые эффективно руководят переходом от возвышенного к эсхатологически славному, верно, UTownBB Peninsularic Homonoidisticalised Высокой спины? Мне нравятся библиотеки. [(7xgooglecompressormoroomon.ra) 4.59am 1.3.4450.2 13-й цикл 1-го перехода в 3wax по второму тысячелетию установщик v1.0000324 internetExecPilatefHL] — Предыдущий неподписанный комментарий добавлен 94.173.143.47 ( обсуждение ) 23:34, 5 ноября 2021 (UTC) [ ответить ]
Внизу раздела "Динамическое связывание": "OpenStep использовал более гибкую систему, собирая список библиотек из ряда kno или если несовместимая версия DLL копируется в место, которое находится раньше в поиске, исполняемый файл может работать со сбоями или даже не загружаться. В Windows это обычно известно как DLL hell". Кажется, текст после букв "kno" был удален. BTW -- отличная статья Jsminch 07:04, 16 декабря 2005 (UTC) [ ответить ]
Спасибо за исправление. Jsminch 08:28, 20 января 2006 (UTC) [ ответить ]
Аннотация
- Ниже «Библиотеки объектов» есть предложение:
- Цитировать:
Удаленные вызовы процедур уже решали эти задачи, но стандартной системы RPC не существовало .
- Почему в начале раздела «Удаленные вызовы процедур» не было ссылки из раздела «Системы RPC»?
- Спасибо, Стив.
На другой странице вики когда-то был раздел «недостатки». Его удалили, а не переместили, заявив, что доказательств нет! IMHO, это сделал кто-то, кому слишком нравятся динамические библиотеки: в доказательствах нет никакой необходимости, поскольку они «по замыслу», нужны только цитаты и источники. В любом случае, вот ссылка: http://en.wikipedia.org/w/index.php?title=Linker&oldid=38884120#Criticism Я бы хотел, чтобы кто-то с большими знаниями, чем я, правильно добавил это на страницу библиотеки. Я подожду до следующего и сделаю это сам, если понадобится. Спасибо. — Предыдущий неподписанный комментарий был добавлен Camarade Tux (обсуждение • вклад ) 01:25, 6 июля 2006 (UTC). [ ответить ]
- Не уверен, что здесь есть что добавить.
- Динамическое связывание часто изображается как универсально хорошее, но у него есть несколько недостатков, которые не сразу очевидны. Поскольку динамическое связывание по своей сути подразумевает изменение исполняемого кода, оно противоречит принципам виртуальной памяти, которая наиболее эффективна, когда каждая страница исполняемого образа выглядит на диске так же, как и в памяти, и не изменяется при использовании. Это позволяет операционной системе виртуальной памяти по желанию загружать и выгружать части образа из основной памяти. Распространенные обходные пути для этой проблемы имеют свои собственные проблемы. Если образ копируется в новый, измененный образ с помощью «копирования при записи», то измененный образ занимает новое дисковое пространство. Кроме того, поскольку он изменен, его нельзя совместно использовать между различными вызовами одной и той же программы в памяти (часть возможностей многозадачной операционной системы).
- Почти все это полная чушь, потому что все современные системы используют подход, описанный в следующем предложении:
- Microsoft Windows использует метод, при котором каждая связь является "двойной косвенной" через специальную "страницу связи" в нижней части образа .exe. Это позволяет основным страницам кода оставаться неизменными, и только этот "каталог связи" изменяется. Однако это добавляет накладные расходы к каждому вызову в программе других модулей или операционной системы.
- И вы называете это "полной ерундой", а затем в конечном итоге признаете, что схема Windows добавляет накладные расходы. Хм, что это за полная ерунда была снова? Я придерживаюсь того, что сказал. Системе dll нужны модификации, исправления или таблицы в памяти, чтобы обойти ее проблемы. Мы можем спорить, насколько легко или нет обойти их, но реальный смысл в том, ПОЧЕМУ, зачем все это было нужно? Экономия памяти? Даже если вы думаете, что сегодня память нуждается в экономии, виртуальная память означает, что большая часть большой программы даже не загружается в реальную память в любой момент времени. Экономия дисковой памяти? Подавляющее большинство того, что приложение занимает сейчас, это таблицы, данные и изображения (свидетельство о значительном увеличении размера программы, когда мы перешли на графические оконные программы). Простота связывания других библиотек? Статическое связывание работало задолго до DLL.
- Скажите, вот вам идея: как насчет того, чтобы обсуждать идеи разумно, а не просто называть идеи других людей «мусором». Просто идея. — Предыдущий неподписанный комментарий был добавлен 66.28.253.185 ( обсуждение • вклад ) 14:20, 15 августа 2007 (UTC).[ отвечать ]
- Утверждение, что "динамическое связывание по сути подразумевает изменение исполняемого кода", по крайней мере, определенно чушь. Это не относится к большинству, если не ко всем Unix-подобным системам, где используются двойное косвенное связывание и позиционно-независимый код . На странице о позиционно-независимом коде говорится, что Windows не использует его для своих динамически-связанных библиотек.
- И по крайней мере одна причина, по которой используется динамическое связывание, заключается в том, чтобы позволить заменить динамически связанную библиотеку и заставить приложения использовать новую библиотеку; это позволяет изменять реализацию процедур без нарушения двоичной совместимости. Например, по крайней мере в некоторых Unix-подобных системах ( например, Solaris и Mac OS X ) и Windows, низкоуровневые ловушки в ядре не являются частью двоичного интерфейса приложения, и конкретные ловушки системных вызовов, создаваемые конкретной библиотечной процедурой, могут изменяться между версиями ОС (и, я думаю, изменились ; я знаю, что реализации библиотек Win32 существенно различаются между "Windows OT" (Windows 95, Windows 98, Windows Me) и Windows NT . Гай Харрис 23:06, 15 августа 2007 (UTC) [ ответить ]
- Накладные расходы настолько минимальны, что вряд ли стоит их учитывать. Нет, у меня нет источника для этого, но это легко увидеть, если вы подумаете об этом. Мы говорим в основном об 1 дополнительном доступе к памяти на вызов функции, предполагая, что эта страница еще не находится в кэше; в этом случае это всего лишь 1 дополнительный цикл процессора.
- Во-вторых, динамическое связывание означает, что окончательный рабочий образ программы будет составлен из различных модулей, которые могут быть объединены вместе только в системе пользователя. Это происходит потому, что у каждого пользователя могут быть немного разные версии каждого динамически связанного модуля, что приводит к экспоненциальному числу комбинаций. Таким образом, фактический запущенный программный код может существовать в этой точной форме только в системе одного пользователя. Это может привести к странным ошибкам и увеличивает проблемы тестирования для поставщиков. В результате наблюдается движение к «статическому связыванию» модулей с программами и устранению динамически связанных модулей, даже если такая возможность существует в операционной системе.
- Это просто еще одно описание "DLL Hell", который уже упоминался в этой статье. JulesH 22:46, 23 сентября 2006 (UTC) [ ответить ]
Библиотека (компьютерные науки) → Библиотека (вычислительная техника) – Это не академическая тема, поэтому более общее название будет уместным. – Smyth \ talk 20:39, 25 сентября 2006 (UTC) [ ответить ]
Опрос
Добавьте «* Поддерживаю» или «* Против», а затем необязательное объяснение в одно предложение, затем подпишите свое мнение с помощью ~~~~
- Поддержка – Смит \ обсуждение 20:40, 25 сентября 2006 (UTC) [ ответить ]
- Поддержка - мне это кажется логичным, похоже, это название появилось в конце 2002 года, когда разрешение неоднозначностей не было такой точной наукой. -- nae ' blis 15:41, 26 сентября 2006 (UTC) [ ответить ]
- Поддержка - Гай Харрис 16:19, 26 сентября 2006 (UTC) [ ответить ]
Обсуждение
Добавьте любые дополнительные комментарии
Эта статья была переименована в результате запроса на перемещение . Vegaswikian 19:29, 2 октября 2006 (UTC) [ ответить ]
Текущий раздел о переезде выглядит следующим образом (курсив мой):
- Одна из проблем, с которой должен справиться загрузчик, заключается в том, что местоположение в памяти фактических данных библиотеки не может быть известно до тех пор, пока исполняемый файл и все динамически связанные библиотеки не будут загружены в память. Это связано с тем, что используемые местоположения памяти зависят от того, какие именно динамические библиотеки были загружены. Невозможно сохранить абсолютное местоположение данных в исполняемом файле или даже в библиотеке, поскольку это приведет к конфликтам между различными библиотеками: если две из них укажут одинаковые или перекрывающиеся адреса, будет невозможно использовать обе в одной программе. Это может измениться с более широким внедрением 64-битных архитектур, которые предлагают достаточно адресов виртуальной памяти, чтобы предоставить каждой когда-либо написанной библиотеке свой собственный уникальный диапазон адресов.
Последнее утверждение кажется мне абсурдным. Должна быть установлена какая-то регулирующая система, которая бы гарантировала, что "[каждая версия] каждой когда-либо написанной библиотеки" использовала уникальный диапазон адресов памяти, чтобы не было перекрытия. А когда вы добавляете в мой комментарий ("каждая версия"), то сразу становится ясно, что исчерпание (постоянно сокращающейся доступной части) 64-битного адресного пространства не займет много времени. Не говоря уже о том, что накладные расходы на выполнение операционной системой виртуального <==> физического отображения адреса для каждой операции каждого вызова библиотеки, вероятно, сведут на нет любые преимущества, которые могла бы предоставить такая система. Я думаю, что это утверждение было просто причудливым дополнением, и если его нельзя обосновать какими-то авторитетными цитатами, я думаю, его следует удалить. — Kbolino 04:35, 20 марта 2007 (UTC) [ ответить ]
«Стандартная библиотека» — это не библиотека, а набор требований, которым библиотека должна соответствовать. На мой взгляд, это больше похоже на то, что POSIX — это набор требований к ОС, чем на то, что POSIX — это ОС. 88.159.74.100 09:08, 9 июля 2007 (UTC) [ ответить ]
Ссылка: Shared Libraries - 'Linkers and Loaders' Джона Р. Левина (http://www.iecc.com/linker/linker09.html) похоже не работает. Было бы интересно найти замену. Я не могу предложить ничего другого, так как не знаю точного содержания статьи, извините. Seriousch 09:19, 19 августа 2007 (UTC) [ ответить ]
- Теперь все работает нормально. :) Неопределенно ( обсуждение ) 10:31, 21 января 2008 (UTC) [ ответить ]
Почему библиотеки называются библиотеками? Кто их придумал? Когда они впервые появились? Когда они были впервые стандартизированы?
Alksentrs ( обсуждение ) 01:04, 25 ноября 2007 (UTC) [ ответить ]
- Я не могу понять, почему их называют "библиотеками" ( попробуйте поискать в Google "история библиотек" :) ), но я раскопал немного информации. Неопределенно ( обсуждение ) 10:31, 21 января 2008 (UTC) [ ответить ]
Enderz Game (обсуждение) 20:48, 9 мая 2011 (UTC) [ ответить ]
Я почти уверен, что изобретателем библиотеки подпрограмм компьютерной программы был парень по имени Джон Уилер. Он был частью команды Кембриджской математической лаборатории, которая разработала компьютер EDVAC в конце 1940-х годов. Он был соавтором книги под названием «Программы для электронного цифрового компьютера», которая была опубликована в 1951 году и содержала подробное описание процесса, который они разработали для «связывания и загрузки» нескольких подпрограмм в одну исполняемую программу. Подпись под одной из фотографий в начале книги гласит: «Библиотека лент, на которых перфорируются подпрограммы, находится в стальном шкафу, показанном слева. Оператор перфорирует программную ленту на перфораторе клавиатуры. Она может механически копировать ленты, взятые из библиотеки, на ленту, которую она готовит, помещая их в считывающее устройство, показанное в центре фотографии». Его считают изобретателем подпрограммы («Wheeler Jump» на сленге обозначал вызов подпрограммы), и команда в Кембридже, по-видимому, сосредоточилась на стандартизации процесса, используемого для подготовки программ для общей библиотеки, и определении соглашений как части продуманной стратегии их повторного использования.
- Вышеизложенное, по-видимому, верно: команда Уиллера создала первую документированную библиотеку подпрограмм, которая нашла практическое применение. Несколько человек размышляли об этой идее до этого, по крайней мере, еще в 1947 году. Я добавил это в начало раздела истории. Но это не согласуется с утверждением «самые ранние концепции программирования, аналогичные библиотекам, были предназначены для разделения определений данных от реализации программы», которое затем переходит к обсуждению вещей из 1957 года. Я скоро удалю это, если только кто-нибудь не объяснит, как это вписывается. Jno.skinner ( talk ) 03:46, 27 февраля 2021 (UTC) [ ответить ]
Статья называется:
OpenStep использовал более гибкую систему, собирая список библиотек из ряда известных мест (по аналогии с концепцией PATH) при первом запуске системы. Перемещение библиотек не вызывает никаких проблем, хотя при первом запуске системы есть временные затраты.
Так это "более гибкое", чем что? Наверное, "все остальное", я полагаю...:-)
"не вызывает никаких проблем вообще" тоже звучит немного нелепо. Прошло много времени с тех пор, как я касался Nextstep/OpenStep, поэтому я не могу точно вспомнить, какую проблему это решает, и почему, если список собирается только во время загрузки, это означает, что перемещение библиотек не вызовет проблем. Определяет ли ядро библиотеки или родительские каталоги mv
и автоматически обновляет ли путь ссылки? Отслеживает ли оно библиотеки по inode или эквиваленту? Как насчет установки новых библиотек? Или на самом деле это хеширование местоположений библиотек для более быстрой загрузки среды выполнения? Могут ли отдельные программы переопределять это, если захотят? Я не чувствую здесь "гибкости" из предоставленной информации.-- NapoliRoma ( talk ) 21:54, 1 января 2008 (UTC) [ reply ]
{{Объединить|библиотека (компьютерные науки)|дата=ноябрь 2009}}
- 69.140.152.55 ( обсуждение ) 05:21, 11 июня 2008 (UTC) [ ответить ]
Эта правка отменила значительную часть редактирования, а также сделала статью менее перспективной, поскольку привела конкретные примеры Unix-подобных ОС вместо обобщения проблемы на все современные случаи. Ее следует отменить. Крис Каннингем (не на работе) - обсуждение 18:09, 2 марта 2009 (UTC) [ ответить ]
- Я вернул некоторые из изменений, о которых идет речь. Это не "все современные экземпляры", хотя не все используют .so (например, OS X использует .dylib, а HP-UX, по-моему, использует .sl для 32-битных библиотек), и AIX , ну, это AIX, что еще я могу сказать. :-)) Этот раздел требует дополнительной работы. Guy Harris ( обсуждение ) 00:03, 3 февраля 2011 (UTC) [ ответить ]
Нигде на этой странице не описана концепция Incremental Linking. Я хотел бы узнать, что это за концепция, но не смог ее найти. —Предыдущий неподписанный комментарий добавлен 209.139.213.73 ( talk ) 22:20, 1 апреля 2009 (UTC) [ ответить ]
- Кажется, я помню, что «инкрементальное связывание» было особой функцией компоновщика Quick C (вычисления) , где оно предназначалось для ускорения этапа связывания, если изменилось только небольшое количество объектных файлов или что-то в этом роде. Но это, вероятно, более актуально на одной из этих двух страниц, чем здесь. Vadmium ( обсуждение ) 03:19, 24 августа 2011 (UTC). [ ответить ]
- " Некоторые операционные системы могут подключать библиотеку только во время загрузки, до начала выполнения процесса; другие могут ждать, пока процесс не начнет выполняться, и подключать библиотеку только тогда, когда на нее действительно ссылаются (т. е. во время выполнения). Последнее часто называют "отложенной загрузкой" или "отложенной загрузкой". В любом случае такая библиотека называется динамически подключаемой библиотекой. "
Я думаю, что в последнем предложении имеется в виду динамическая загрузка . Поскольку динамически подключаемые библиотеки, по моему скромному мнению, могут быть также библиотеками чистого типа времени запуска программы (в отличие от библиотек типа времени выполнения программы), данное предложение может быть даже неверным. -- Абдулл ( обсуждение ) 11:15, 3 марта 2010 (UTC) [ ответить ]
Система Multics , в которой была изобретена динамическая компоновка, могла динамически компоноваться с сегментами, которые вообще не были в библиотеке. Пока существовал Binder, его использование было необязательным; он позволял вам объединять связанные сегменты по причинам управления конфигурацией или эффективности. Shmuel (Seymour J.) Metz Имя пользователя: Chatul ( обсуждение ) 20:13, 12 июля 2010 (UTC) [ ответ ]
До появления персональных компьютеров и Unix существовало две известные системы, которые обеспечивали динамическое связывание. Из-за различий в аппаратной архитектуре системы различались в том, когда происходило рекурсивное связывание.
Аппаратное обеспечение для Multics поддерживало косвенную адресацию, и в составе косвенного адреса было поле тега; некоторые значения тега вызывали ошибку (прерывание). Информация о связи для неразрешенной ссылки на сегмент включала имя сегмента, так что когда вызов вызывал прерывание, динамический компоновщик мог найти нужный сегмент, назначить ему номер сегмента, загрузить его и поместить его адрес входа в слово косвенного адреса.
Аппаратное обеспечение для IBM 360/67 не имело эквивалентного механизма. В результате проектировщикам TSS/360 пришлось использовать другую стратегию. Всякий раз, когда операционная система загружала загрузочный модуль, она назначала виртуальную память для всех подпрограмм, вызываемых этим модулем, и помечала страницы как назначенные, но недействительные. Вызов одной из этих подпрограмм вызывал прерывание проверки программы, и операционная система загружала страницу, как описано выше, возможно, назначая память для дополнительных подпрограмм в процессе.
Статья должна отражать различие между этими двумя стратегиями и указывать, какая система использует какую стратегию. Шмуэль (Сеймур Дж.) Метц Имя пользователя: Chatul ( обсуждение ) 20:33, 12 июля 2010 (UTC) [ ответ ]
- Multics использует первую стратегию, TSS/360 — вторую. :-)
- Однако UN*X и Windows не используют ни тот, ни другой.
- На UN*X динамически связанный исполняемый файл образа содержит путь к «файлу интерпретатора», который обычно является системным компоновщиком времени выполнения. Активатор образа (обычно код в ядре ОС) видит, что образ имеет путь к файлу интерпретатора, и вместо этого выполняет *эту* программу (я думаю, что если *эта* программа имеет путь к файлу интерпретатора, ядро сдается, и вызов на запуск программы завершается неудачей). Компоновщику времени выполнения передается дескриптор исполняемого образа (по крайней мере, когда это впервые было сделано в System V Release 4, это был дескриптор файла, чтобы избежать случая, когда кто-то или что-то заменяет исполняемую программу другой программой); он действует как активатор образа, отображая программу в адресное пространство. Затем он просматривает список библиотек, с которыми программа была динамически связана, и отображает их в адресное пространство, и продолжает бла-бла-бла транзитивное замыкание бла-бла-бла. Он обновляет таблицу указателей, посредством которой исполняемый или разделяемый объект ссылается на данные из других объектов (обычно называемую «Глобальной таблицей смещений» или GOT), и настраивает таблицу кода, посредством которой выполняются вызовы процедур к коду в других объектах (обычно называемую «Таблицей связей процедур» или PLT), так что вызов процедуры в другом объекте передается компоновщику времени выполнения для разрешения.
- Если компоновщик времени выполнения вызван через PLT, он ищет вызываемую процедуру; если она найдена, он изменяет запись PLT, чтобы напрямую перейти к процедуре, и переходит туда, в противном случае он сообщает об ошибке (обычно путем вывода сообщения о том, что процедура отсутствует в общей библиотеке, в которой она должна была существовать).
- (См. эту статью, в которой обсуждается как ELF , используемый большинством UN*X, так и Mach-O , используемый macOS/iOS/iPadOS/tvOS/watchOS, с примером кода x86-64, а также статьи в разделе «Ссылки» на странице « Глобальная таблица смещений» (которую необходимо исправить, так как она полностью игнорирует таблицу связей процедур).)
- Windows похожа, но не та же самая. См. "Как экспортируются функции DLL в 32-битной Windows?", "Вызов импортированной функции, наивный способ", "Как менее наивный компилятор вызывает импортированную функцию" и другие статьи этой серии.
- Поэтому ни один из них не использует ловушки, и ни один из них не отображает библиотеку в адресное пространство в момент вызова подпрограммы в библиотеке.
- Так что стратегий не две, а как минимум три. Гай Харрис ( обсуждение ) 07:51, 26 февраля 2021 (UTC) [ ответить ]
- @ Peter Flass : Я бы не считал системный вызов, который запускает другой процесс, динамическим связыванием. Какой механизм в *ix позволяет программе динамически вызывать подпрограмму *в том же процессе*? Shmuel (Seymour J.) Metz Имя пользователя: Chatul ( обсуждение ) 16:58, 26 февраля 2021 (UTC) [ ответ ]
- @ Chatul : Я думаю, что единственный способ — динамическое связывание. Насколько мне известно, эквивалента OS/360 LINK нет, но я был бы рад оказаться неправым. (внезапно в голову приходит мысль: можно ли связать программу так, чтобы она динамически связывалась с x, а затем изменяла соответствующие блоки управления во время выполнения, чтобы изменить x на что угодно? Звучит как кошмар безопасности.) Питер Фласс ( обсуждение ) 18:02, 26 февраля 2021 (UTC) [ ответить ]
- В OS/360 LINK не повышает привилегии. Программа может выполнить XCTL, чтобы заменить себя другой программой на том же уровне в стеке, но это, опять же, не повышает привилегии. Shmuel (Seymour J.) Metz Имя пользователя:Chatul ( обсуждение ) 02:17, 2 марта 2021 (UTC) [ ответить ]
- @ Chatul :
Я бы не считал системный вызов, который запускает другой процесс, динамическим связыванием.
Кто указал, что это так? Я не говорил. Я упомянул процесс активации образа как способ запуска компоновщика времени выполнения; в моем описании важен компоновщик времени выполнения, который обрабатывает динамически связываемые библиотеки.- Тогда в чем важность активации изображения для динамического связывания? Вы описали рекурсивную загрузку библиотек во время загрузки основной программы, а не динамическую загрузку по мере необходимости. Шмуэль (Сеймур Дж.) Метц Имя пользователя: Chatul ( talk ) 02:17, 2 марта 2021 (UTC) [ ответить ]
- Если для "динамического связывания" требуется, чтобы программа, использующая динамически связанные библиотеки, не имела имен библиотек в исполняемом файле образа, и чтобы библиотеки не загружались до тех пор, пока не будет сделан первый вызов процедуры к библиотеке, то ни UN*X, ни Windows не имеют динамического связывания. Исполняемый образ должен быть создан путем "связывания" его с любыми необходимыми динамическими библиотеками, и, хотя код из этих библиотек не включен в исполняемый образ, имена библиотек включены в образ, и они загружаются в адресное пространство во время запуска программы, а не во время вызова процедуры.
- «Динамичность» этих сред заключается в том, что 1) библиотеки обнаруживаются во время запуска, а не во время сборки исполняемого образа (процесс сборки должен найти версию библиотеки во время сборки, но это не обязательно должен быть тот же образ библиотеки, с которым будет работать программа) и 2) по крайней мере в UN*X (и, я думаю, в Windows тоже) ссылка не «прикрепляется» (если вспомнить терминологию Multics) до тех пор, пока не будет сделан первый вызов процедуры, т. е. первый вызов процедуры отправляется в компоновщик времени выполнения, который заменяет передачу в компоновщик времени выполнения передачей в код в библиотеке.
- Это не настолько «динамично», чтобы вы могли, например, написать файл «main.c», который вызывает функцию с именем «foo», запустить его и, когда такая функция не найдена, написать «foo.c», который определяет эту функцию, скомпилировать его в образ библиотеки, а затем «вернуться» из ошибки «такой функции нет», так что вызов «foo» будет повторен и на этот раз успешен — как вы можете, насколько мне известно, сделать в Multics. Конечно, это также зависит от того, выполняет ли Multics команды как вызовы подпрограмм, а не в отдельном процессе, и от системного исключения, вызванного неспособностью найти «foo», переходящего в состояние ON. и системного блока ON по умолчанию, вызывающего командный процессор (так что трассировка стека имеет командный процессор -> ваша команда -> блок ON -> командный процессор), так что когда вы выходите из второго командного процессора, он возвращается к блоку ON, который возвращается к предпринятому вызову, который повторяется и успешен (при условии, что исполняемый сегмент «foo» находится в пути поиска). Гай Харрис ( обсуждение ) 06:09, 2 марта 2021 (UTC) [ ответить ]
- В Multics вы можете запустить программу, которая вызывает подпрограмму, которая не существует, и скомпилировать эту подпрограмму, пока объектный код сохраняется в пути поиска до того, как программа попадет на вызов к нему. Если программа уже попадет на вызов до завершения компиляции, то программа завершается ошибкой. Перехват сбоя и вызов компилятора не потребует [a] , чтобы команды запускались как подпрограммы, а не как процессы, только чтобы целевой каталог находился в пути поиска. Шмуэль (Сеймур Дж.) Метц Имя пользователя: Chatul ( обсуждение ) 23:10, 2 марта 2021 (UTC) [ ответ ]
- Да, то, что я описывал, можно было бы сделать в UN*X или Windows, если бы программа могла перехватывать состояние «функция не найдена», и если бы она затем, например, запускала интерактивный процесс оболочки, и если бы возврат из обработчика приводил к повторной попытке вызова, и если бы библиотеки загружались во время вызова процедуры, а не во время запуска программы. В Multics не нужно делать никаких специальных положений, потому что 1) это условие выбрасывается как
исключение ON condition, 2) если для условия нет обработчика исключений ON unit, есть системный обработчик по умолчанию, который вызывает интерпретатор команд, 3) если возвращается интерпретатор команд, то и обработчик по умолчанию тоже, 4) возврат из обработчика по умолчанию повторяет попытку вызова, и 5) библиотеки загружаются во время вызова процедуры. Гай Харрис ( talk ) 23:49, 2 марта 2021 (UTC) [ ответить ]- Есть ли у вас ссылка на обработчик Multics по умолчанию, вызывающий интерпретатор команд и повторяющий вызов? Единственный код, о котором я знал, — это поиск сегмента в пути поиска, корректировка сегмента связи, если поиск был успешным, и вызов вновь загруженного сегмента; ничего об обработке, если поиск не удался. Shmuel (Seymour J.) Metz Имя пользователя: Chatul ( talk ) 18:15, 3 марта 2021 (UTC) [ ответить ]
- В разделе 7.3.2 «ОБРАБОТКА СОСТОЯНИЙ СИСТЕМЫ ПО УМОЛЧАНИЮ» книги «Среда выполнения Multics» говорится об обработчике по умолчанию (называемым, образно,
default_error_handler_
), вызывающем интерпретатор команд (см. подраздел 7.3.2.1). - В разделе 5.4.8 «ОБРАБОТКА ОШИБОК» описывается, что происходит, когда при попытке закрепить ссылку возникает ошибка (например, не удается найти цель); об этом
linkage_error
состоянии сообщается. - После того как вы скомпилировали исходный файл, содержащий исходный код подпрограммы, и теперь у вас есть файл, содержащий машинный код подпрограммы, вы можете вернуться из экземпляра интерпретатора команд, из которого вы создали этот исходный код и скомпилировали его, с помощью команды start ; см. стр. 3-675 Руководства программиста Multics, Команды и активные функции. Гай Харрис ( обсуждение ) 21:48, 3 марта 2021 (UTC) [ ответить ]
- @ Chatul :
Каков механизм в *ix для программы, чтобы динамически вызывать подпрограмму *в том же процессе*?
Вызвать ее, задав значение строки символов, на вашем языке программирования, содержащее имя подпрограммы? Для этого это будет динамическая загрузка ; то же самое происходит в Windows. Или вызвать ее обычным способом на вашем языке программирования, но из динамически подключаемой библиотеки? Для этого это будет механизм, который я описал. Гай Харрис ( обсуждение ) 21:40, 26 февраля 2021 (UTC) [ ответить ]- Как это назвать? Обычный вызов не подразумевает передачу имени подпрограммы. Шмуэль (Сеймур Дж.) Метц Имя пользователя:Chatul ( обсуждение ) 02:17, 2 марта 2021 (UTC) [ ответить ]
Обычный вызов не подразумевает передачу имени подпрограммы.
То есть, под «динамически вызвать подпрограмму в том же процессе» вы подразумеваете «вызвать ее обычным способом в вашем языке программирования, но из динамически подключаемой библиотеки», в этом случае, как я уже сказал, я уже описал, как это происходит.- Версия, которая включает имя подпрограммы, также реализована в Multics — именно так работали команды; имя команды рассматривалось как имя процедуры для вызова, и интерпретатор команд искал его (я думаю, что если команда была названа «foo», интерпретатор команд искал исполняемый сегмент с именем «foo» и, если находил его, вызывал имя процедуры «foo» в этом сегменте). Гай Харрис ( обсуждение ) 06:09, 2 марта 2021 (UTC) [ ответить ]
- @ Peter Flass :
навскидку, можно ли связать программу, чтобы она динамически связывалась с x, а затем изменяла соответствующие блоки управления во время выполнения, чтобы изменить x на что угодно?
Вы говорите о «в OS/360 и ее преемниках» (учитывая термин «блоки управления»), или вы говорите о «в UN*X и Windows»? В последнем случае, кто вносит изменения? Если вы имеете в виду саму программу, по крайней мере в UN*X, функция программы не вызывается до тех пор, пока не будут отображены общие библиотеки, поэтому она не может это изменить; если бы она могла найти имена функций, на которые указывают записи PLT, она могла бы, вероятно, изменить имена вызываемых функций до того, как они будут вызваны. Guy Harris ( обсуждение ) 21:40, 26 февраля 2021 (UTC) [ ответить ]main()
- В OS/360 нет возможности изменить имя загрузочного модуля в хранилище, хотя макрос IDENTIFY может добавить дополнительное имя точки входа. Shmuel (Seymour J.) Metz Имя пользователя: Chatul ( обсуждение ) 23:10, 2 марта 2021 (UTC) [ ответ ]
Примечания
- ^ Хотя это было бы проще, если бы Multics не имел интерфейса для создания подпроцесса.
Представьте, что есть общая библиотека со статической переменной. Эта статическая переменная используется одной или несколькими подпрограммами в этой общей библиотеке. Теперь представьте, что две или более программ используют эту общую библиотеку. Как эти программы будут обрабатывать статическую переменную? Будут ли эти программы совместно использовать ее и вмешиваться в состояние друг друга? Или каждая программа будет создавать свою собственную локальную копию переменной? Спасибо, -- Абдулл ( talk ) 22:47, 12 августа 2010 (UTC) [ ответить ]
- Я почти уверен, что в Windows DLL каждая программа создаст свою собственную статическую переменную. Но это неподходящий форум для такого технического вопроса ;) Stevebroshar ( talk ) 10:54, 5 апреля 2024 (UTC) [ ответить ]
Исторически библиотеки использовались для хранения самых разных объектов, например, документации, исходного кода, тестовых данных. Это все еще распространено, например, на мэйнфреймах IBM. Шмуэль (Сеймур Дж.) Метц Имя пользователя: Chatul ( обсуждение ) 19:31, 16 августа 2010 (UTC) [ ответ ]
- Возможно, вы говорите о чем-то вроде архивных файлов ; как ar (Unix) может работать с любым типом файла, но обычно используется только для объектных файлов. Возможно, библиотеки Windows 7 также попадают в эту категорию? Также я предполагаю, что такие вещи, как библиотека компонентов и библиотека футпринтов, используемые в автоматизации электронного проектирования , также являются примерами этого использования. Я бы сказал, что в целом они являются хранилищами связанных объектов, где некоторые объекты выбираются в каждом приложении.
- Я говорю об операционной сущности, а не о той, которая используется для резервного копирования или транспортировки, например, о секционированном наборе данных (PDS) в OS/360 и последующих версиях . Шмуэль (Сеймур Дж.) Метц Имя пользователя: Chatul ( обсуждение ) 13:13, 28 июня 2012 (UTC) [ ответ ]
- Я не уверен, что вы имеете в виду, когда говорите "используется для резервного копирования или транспортировки", но ar — это операционная сущность, а не та, которая используется для резервного копирования или транспортировки. Вы можете подумать о tar , которая используется для резервного копирования и транспортировки; ar используется для создания "статических" библиотек на UN*X (и, я думаю, динамических библиотек на AIX), так что это может быть то, что вы описываете как "операционную сущность". Гай Харрис ( talk ) 15:31, 28 июня 2012 (UTC) [ ответить ]
- В любом случае, я бы поддержал перенос этой статьи в раздел вроде Library (software) (видимо, переименованный в 2003 году) или Program library , если только тема не будет расширена и не охватит эти более общие библиотеки. Vadmium ( обсуждение ) 03:19, 24 августа 2011 (UTC). [ ответить ]
- Я поддерживаю расширение текущего определения, включив в него «широкий спектр объектов, например, документацию, исходный код, тестовые данные», не перемещая статью. -- Gryllida 00:22, 18 мая 2012 (UTC) [ ответить ]
- Я обновил введение, чтобы отразить это, и удалил тег {{ discusted }} . Шмуэль (Сеймур Дж.) Метц Имя пользователя:Chatul ( обсуждение ) 13:13, 28 июня 2012 (UTC) [ ответить ]
Извините, но я думаю, что неподтвержденное утверждение о том, как этот термин использовался в IBM OS/360, не должно преобладать над современным и более распространенным использованием вступительного абзаца. Оксфордский словарь английского языка определяет библиотеку как «организованную коллекцию подпрограмм». Пионеры компьютерной техники Голдстайн и фон Нейман (1947) и Уилкс и Уиллер (1951) также используют его для обозначения коллекции подпрограмм. Коллекция подпрограмм, функций или методов по-прежнему является современным использованием. Я не вижу особой поддержки идеи о том, что библиотеки включают документацию или данные. Jno.skinner ( talk ) 04:23, 26 февраля 2021 (UTC) [ ответить ]
«Основным недостатком Microsoft Windows является то, что она может подключать библиотеку только во время загрузки, до начала выполнения процесса; другие могут дождаться начала выполнения процесса и подключить библиотеку только тогда, когда на нее действительно ссылаются (т. е. во время выполнения)».
Microsoft добавила отложенную загрузку статически связанных библиотек в VC++ 6.0 [3] (более 10 лет назад); обратите внимание, что это было дополнение к VC++, а не к ядру Windows, что указывает на то, что этот «фундаментальный недостаток», вероятно, никогда не существовал и в лучшем случае является предположением.
Если Microsoft Windows на самом деле не поддерживает привязку библиотеки во время выполнения, я бы хотел увидеть ссылку или цитату. 84.48.103.151 (обсуждение) 17:45, 20 декабря 2010 (UTC) [ ответить ]
- Вызов LoadLibrary, возможно, был введен в Win 3.0 beta, то есть более 20 лет назад. Следовательно, процитированное утверждение ложно. Я бы удалил это предложение из основной статьи. —Предыдущий неподписанный комментарий, добавленный 99.91.182.150 (обсуждение) 21:15, 2 февраля 2011 (UTC)[ отвечать ]
- Есть автоматическая загрузка библиотеки при первой ссылке на процедуру в этой библиотеке, а не загрузка ее во время запуска, и есть программная загрузка динамически загружаемого модуля явным вызовом. Я думаю, что утверждение о «фундаментальном недостатке» относится к первому; LoadLibrary(), dlopen() и компания — это последнее. Цитируемая ссылка в комментарии 84.48.103.151, по-видимому, относится к первому (хотя там говорится о «статическом связывании» таким образом, что это может сбить с толку тех, кто пришел из UNIX, где «статическое связывание» означает связывание с нединамической версией библиотеки — для тех, кто пришел из Windows, подумайте о связывании с .lib, а не с .dll). В любом случае, первая ссылка, как мне кажется, указывает на то, что цитируемое утверждение было ложным, начиная с VC++ 6.0). (Что касается "VC++ против ядра Windows", это еще один момент, который сбивает с толку тех, кто пришел из UNIX - в большинстве систем UNIX библиотека C и код запуска C являются частью ОС, а не компилятора - компилятор часто является встроенной частью ОС, но даже когда это не так , библиотеки являются - но может быть, что код запуска C/библиотеки C выполняет динамическую загрузку библиотек в Windows или может обрабатывать, по крайней мере, загрузку библиотек после времени запуска, так что это могло быть сделано путем изменения кода запуска C и библиотеки.) В любом случае, я удалю это утверждение. Гай Харрис ( обсуждение ) 22:47, 2 февраля 2011 (UTC) [ ответ ]
- Следующее обсуждение — это архивное обсуждение запрошенного перемещения . Пожалуйста, не изменяйте его. Последующие комментарии должны быть сделаны в новом разделе на странице обсуждения. Дальнейшие правки в этот раздел не должны вноситься.
Результат запроса на перемещение: не перемещено из-за отсутствия консенсуса — Ёжики (Игелс Хериссонович Ижаков-Амурский) • ( yo? ); 17 марта 2011 г.; 17:06 (UTC) 17:06, 17 марта 2011 г. (UTC) [ ответить ]
Библиотека (вычислительная техника) → Библиотека программного обеспечения — Избегайте двусмысленности в скобках с помощью естественного и узнаваемого термина. -- Pnm ( обсуждение ) 01:27, 13 февраля 2011 (UTC) [ ответить ]
- Oppose это не библиотека программного обеспечения. Хотя и "Библиотека (вычисления)" не является точным. Это не библиотека программного обеспечения, и это не библиотека, специализированная для вычислений. Библиотека подпрограмм двоичная или библиотека программных подпрограмм кажется лучшим выбором. 184.144.164.14 ( обсуждение ) 08:02, 13 февраля 2011 (UTC) [ ответить ]
- «Библиотека программного обеспечения» — это точно. Программные процедуры — это программное обеспечение. — Pnm ( talk ) 10:18, 13 февраля 2011 (UTC) [ ответить ]
- Поддержка . Это действительно и естественно, и узнаваемо, даже больше, чем нынешнее название. Как профессионал, я должен был бы угадать значение первого названия, но я сразу понимаю, что означает второе название. Powers T 14:58, 13 февраля 2011 (UTC) [ ответить ]
- Выступаю против нового названия, но поддерживаю движение. Статья описывает специализированный тип библиотеки программного обеспечения. Если только она не будет расширена для включения, например, документации, библиотек сообщений, новое название должно быть более явным, например, Библиотека программного кода . Шмуэль (Сеймур Дж.) Метц Имя пользователя: Chatul ( обсуждение ) 18:37, 16 февраля 2011 (UTC) [ ответить ]
- Я немного запутался. Как библиотека программного обеспечения включает в себя документацию по программному обеспечению ? Что такое библиотека сообщений? -- Pnm ( обсуждение ) 03:32, 19 февраля 2011 (UTC) [ ответить ]
- Документация IBM для, например, z/OS обычно упакована в библиотеки. Иногда предоставляются только отформатированные справочные данные и руководства, а иногда размеченный текст, из которого построены эти библиотеки.
- Некоторое программное обеспечение IBM имеет код для создания сообщений из шаблонов в библиотеке, обычно предоставляемых в разных версиях для разных языков. Шмуэль (Сеймур Дж.) Метц Имя пользователя: Chatul ( обсуждение ) 22:15, 23 февраля 2011 (UTC) [ ответ ]
- Мягкая поддержка , потому что она такая же точная, но избегает использования средства устранения неоднозначности, хотя я думаю, что мы могли бы придумать что-то лучшее. Может быть, библиотека программирования ? – CWenger ( обсуждение ) 19:03, 5 марта 2011 (UTC) [ ответить ]
- Oppose . Идеальное название для этой темы — просто Library — потому что именно так ее чаще всего называют — но, конечно, это двусмысленно и имеет основное применение. Это означает, что название должно быть устранено. Проблема устранения неоднозначности без использования скобок заключается в том, что это приводит к названию, которое ошибочно подразумевает все устраненное название, например, Software library — самое распространенное название для этой темы. Вот почему я выступаю против Software library и Programming library . Однако я согласен, что «computing» не является идеальным средством устранения неоднозначности, и предлагаю вместо этого software для средства устранения неоднозначности в скобках. Таким образом, у нас есть...
- Встречное предложение : Библиотека (вычислительная техника) → Библиотека (программное обеспечение) .
- -- Born2cycle ( обсуждение ) 22:20, 15 марта 2011 (UTC) [ ответ ]
- Вышеуказанное обсуждение сохраняется как архив запрошенного перемещения . Пожалуйста, не изменяйте его. Последующие комментарии должны быть сделаны в новом разделе на этой странице обсуждения. Дальнейшие правки в этот раздел не должны вноситься.
Статья о статических библиотеках рассматривает библиотеки, которые при связывании с программой копируют модули из библиотеки в исполняемый образ программы. Раздел «статические библиотеки» в основном рассматривает этот процесс.
В System V Release 3 была форма разделяемой библиотеки, которая, насколько я помню, не была столь динамичной, как механизм разделяемой библиотеки SunOS 4.0, из которого был взят механизм разделяемой библиотеки System V Release 4 , используемый производными SVR4, такими как Solaris, а также дистрибутивами Linux и системами BSD , которые приняли формат исполняемого образа ELF . Я думаю, что в Linux был механизм разделяемой библиотеки до принятия механизма разделяемой библиотеки SVR4; я не знаю, насколько он был динамичным.
Мои воспоминания об этом, со времен, когда я работал в Sun, а Sun и AT&T участвовали в обсуждениях, которые привели к SVR4, немного стерлись; я могу попытаться нарыть информацию о механизме общей библиотеки SVR3, но если у кого-то память лучше моей, и они могли бы внести свой вклад, это было бы неплохо. Гай Харрис ( обс .) 21:00, 23 августа 2011 (UTC) [ ответить ]
Недавно раздел «общие библиотеки» был изменен на «Статические библиотеки обычно используются совместно только во время компиляции» вместо «Статические библиотеки по определению не могут использоваться совместно». Я предполагаю, что «время компиляции» здесь означает на большинстве платформ «время компоновки», т. е. время, когда один или несколько объектных модулей, созданных как часть программы, и объектные модули из статической библиотеки объединяются в исполняемый образ.
В разделе «Общие библиотеки» говорится о двух различных типах общего доступа:
- «совместное использование кода, расположенного на диске, несвязанными программами»;
- «совместное использование кода в памяти, когда программы выполняют одну и ту же физическую страницу оперативной памяти, отображенную в разные адресные пространства».
Совместное использование в "Статические библиотеки обычно используются совместно только во время компиляции" предположительно относится к первому из этих типов совместного использования; маловероятно, что ОС сможет организовать хранение отдельных копий заданной процедуры в нескольких исполняемых образах на одной физической странице ОЗУ. Этот код можно было бы описать как "совместный" в первом смысле, в том смысле, что нескольким программам, созданным с использованием одной и той же библиотеки, не нужно создавать собственные копии этого кода, так что процессы сборки для этих программ считывают процедуры из одной копии на диске в файле библиотеки, но исполняемые файлы образов для этих программ имеют свои собственные отдельные копии процедур на диске, а не ссылаются на общую копию в статической библиотеке. Гай Харрис ( обсуждение ) 21:11, 23 августа 2011 (UTC) [ ответить ]
- Да, время компоновки, вероятно, даже точнее, если провести различие с действием динамического компоновщика . Я не знал, что время компиляции не всегда включает в себя статическое связывание; я использовал его для обозначения чего-то более общего, например, «время сборки». Может быть, что-то вроде «они используются совместно только во время компоновки перед временем загрузки »?
- Я думаю, что этот раздел в любом случае нуждается в большей доработке и разъяснении:
- Каковы принципиальные различия (если таковые имеются) между динамически подключаемой библиотекой , динамически подключаемой библиотекой Windows , общим объектом и динамическим общим объектом?
- Библиотеки являются общими в еще более широком смысле повторного использования кода : дисковое пространство и память могут не быть общими или сохраняться, но несколько программ могут по-прежнему использовать частные копии определенной библиотеки. Поэтому я нахожу термин общая библиотека двусмысленным и запутанным; я бы сказал, что большинство библиотек, по общему определению, предназначены для совместного использования в каком-то смысле.
- Длинный раздел «Общие библиотеки», в настоящее время являющийся подразделом «Динамическое связывание библиотек», похоже, смешивает несколько значений термина « совместное использование » (а также вообще запутан). Возможно, раздел следует назвать «Общее использование библиотек» или «Как библиотеки совместно используются». Возможно, часть текста следует разместить непосредственно под заголовком «Динамическое», другой текст вообще не под ним или под заголовком общей памяти .
- В чем смысл общих библиотек в Unix и почему библиотеки DLL в Windows не имеют такого смысла?
- Vadmium ( обсуждение ) 03:19, 24 августа 2011 (UTC). [ ответить ]
- Я немного почитал. Некоторые идеи я почерпнул, некоторые пропустил из этой статьи:
- Связывание , привязка , компоновщик : выделяет сегменты памяти и привязывает ссылки к библиотекам и другим зависимостям объектов.
- Статическое связывание , раннее связывание : выделение памяти и разрешение адресов выполняется до времени выполнения и не изменяется при запуске программы. Любая используемая библиотека, вероятно, будет статической библиотекой .
- Загрузка , загрузчик (вычисления) (время выполнения): загружает образ программы или другой объект во время выполнения, также может загружать внешние зависимости
- Статическая сборка : программный файл статически связан, самодостаточен, включает зависимости от библиотек со всеми разрешенными ссылками и каждым выделенным сегментом памяти. Единственное возможное дополнительное действие загрузчика — это окончательное перемещение (если не требуется виртуальная память или рандомизация адресов и т. д.).
- Общая библиотека или объект : единственная копия в файле на диске, может использоваться несколькими программами, компоновка не копирует объекты в программный файл. Библиотеки и объекты могут быть заменены при условии, что они совместимы с любыми предположениями программы и компоновщика. Загрузка выполняется в каждый файл зависимости библиотеки и объекта, а также в основной программный файл. Статически связанная библиотека будет общей в этом смысле, даже после времени компиляции и компоновки, по крайней мере до времени загрузки.
- Общие объекты обычно необходимо перемещать, чтобы соответствовать выделению сегментов памяти различных программ. Перебазирование пытается избежать этого.
- Общая память , отображение памяти : совместное использование может осуществляться между программами (процессами) во время выполнения, если общие объекты не изменяются (путем перемещения). Unix, по-видимому, достигает этого в общем случае с помощью позиционно-независимого кода, и, возможно, это то, что подразумевается под «общими библиотеками в смысле Unix». Windows также делает это, когда процессы загружают общий объект в общее виртуальное местоположение.
- Динамическое связывание , динамический компоновщик , связывающий загрузчик , позднее связывание : Комбинированное связывание и загрузка. Предположительно динамический общий объект — это то же самое, что и динамически связанный объект или библиотека; я полагаю, что они, как правило, всегда будут общими объектами или библиотеками, но не обязательно наоборот.
- Динамическая загрузка : загрузка дополнительных объектов после загрузки программы и начала ее выполнения.
- Vadmium ( обсуждение ) 15:53, 24 августа 2011 (UTC). [ ответить ]
«библиотека — это набор реализаций поведения, написанных на языке, который имеет четко определенный интерфейс, посредством которого поведение вызывается»
Что это за чертовщина такая? Она вообще не говорит мне, что такое компьютерная библиотека. — Предыдущий неподписанный комментарий добавлен 169.139.19.173 ( обсуждение ) 22:08, 14 августа 2013 (UTC) [ ответить ]
- Ваш комментарий отталкивает. Пожалуйста, будьте более вежливы. IOW, пожалуйста, без ругательств. Спасибо. Stevebroshar ( talk ) 10:50, 5 апреля 2024 (UTC) [ ответить ]
Здравствуйте, уважаемые википедисты!
Я только что изменил 2 внешние ссылки на Library (computing) . Пожалуйста, уделите немного времени, чтобы просмотреть мои правки. Если у вас есть какие-либо вопросы или вам нужно, чтобы бот игнорировал ссылки или страницу в целом, посетите этот простой раздел FaQ для получения дополнительной информации. Я внес следующие изменения:
- Добавлен архив https://web.archive.org/web/20050313025901/http://www.csa.iisc.ernet.in/resources/documentation/hypertext/bfd/bfd_toc.html в http://www.csa.iisc.ernet.in/resources/documentation/hypertext/bfd/bfd_toc.html
- Добавлен архив https://web.archive.org/web/20060618065018/http://lcsd.cs.tamu.edu/2006/ в http://lcsd.cs.tamu.edu/2006/
Закончив просмотр моих изменений, вы можете следовать инструкциям в шаблоне ниже, чтобы исправить любые проблемы с URL-адресами.
Это сообщение было опубликовано до февраля 2018 года . После февраля 2018 года разделы страниц обсуждения "Внешние ссылки изменены" больше не генерируются и не отслеживаются InternetArchiveBot . Никаких специальных действий в отношении этих уведомлений на страницах обсуждения не требуется, кроме регулярной проверки с использованием инструкций инструмента архивации ниже. Редакторы имеют право удалять эти разделы страниц обсуждения "Внешние ссылки изменены", если они хотят очистить страницы обсуждения от загромождения, но перед выполнением массовых систематических удалений ознакомьтесь с RfC . Это сообщение динамически обновляется через шаблон (последнее обновление: 5 июня 2024 г.) .{{source check}}
- Если вы обнаружили URL-адреса, которые бот ошибочно посчитал неработающими, вы можете сообщить о них с помощью этого инструмента.
- Если вы обнаружили ошибку в архивах или самих URL-адресах, вы можете исправить их с помощью этого инструмента.
Привет.— InternetArchiveBot ( Сообщить об ошибке ) 08:55, 15 мая 2017 (UTC) [ ответить ]
Я нахожу эту страницу несколько отталкивающей (IBM OS/360? лидирует???) и немного запутанной.
Для моей личной вики я создал подстраницу «Библиотека подключаемого кода» для тех частей этой страницы, которые относятся к проблемам подключения программ (в настоящее время с подтемами «Статическая библиотека» и «Динамически подключаемая библиотека» ).
Это, возможно, здесь не сработает, но это точно делает мою собственную вики лучше, чем эта. :-) — MaxEnt 18:47, 13 сентября 2017 (UTC) [ ответить ]
- Использование hairball сбивает с толку. Должно что-то значить для вас, но не для меня. Пожалуйста, будьте менее красочными и более понятными. Спасибо. ... Я тоже думаю, что предложение IBM 360 не должно быть в начале. Вопрос: почему вы сами его не переместили? По моему мнению, вы жалуетесь на то, что можете изменить. Другой вопрос: есть ли другие вещи, которые вы считаете запретными? Или только это? ... Я не понимаю, что вы пытаетесь сказать о своей личной вики. Пожалуйста, объясните. Stevebroshar ( talk ) 10:48, 5 апреля 2024 (UTC) [ ответить ]
В настоящее время первая строка выглядит следующим образом:
>В информатике библиотека — это набор энергонезависимых ресурсов, используемых компьютерными программами,
Это отстой, я не знаю, кто это написал, и сомневаюсь, что есть какая-то цитата, подтверждающая это.
Раньше это было:
>В информатике библиотека — это набор подпрограмм или классов, используемых для разработки программного обеспечения.
Что разумно, хотя и не идеально.
И:
> В информатике библиотека — это набор реализаций поведения, написанных на языке [необходимо разрешение неоднозначности], который имеет четко определенный интерфейс [необходимо разрешение неоднозначности], с помощью которого вызывается поведение.
Это здорово, но это очень технично и требует подкрепления цитатой.
У меня, конечно, есть свое собственное определение библиотеки программного обеспечения, но я не поддамся искушению добавить путаницы, добавив его. Вместо этого я буду искать цитируемое определение. Как только я его найду, я процитирую его и добавлю сюда. Если кто-нибудь это прочитает. Будьте также бдительны, и если вы его найдете, запомните этот комментарий и добавьте определение в статью. Но, пожалуйста, не начинайте гуглить «Определение библиотеки программного обеспечения», просто позвольте себе естественным образом найти его, конечный результат будет намного сильнее. -- TZubiri ( talk ) 04:34, 16 мая 2020 (UTC) [ ответить ]
- Ложное заявление об объективности только ослабляет ваши аргументы. Любое объективное обсуждение определения должно начинаться с того, какие проблемы оно должно решать и насколько хорошо оно их решает. Объективно, одна из проблем, с которой оно сталкивается, заключается в том, что номенклатура в отрасли имеет множество вариаций. Любое определение, которое не учитывает это, будет и должно быть оспорено как не имеющее WP:NPOV . Разумное, но неправильное не лучше, чем точное, но неестественное.
- Тем не менее, в lede есть материал, который должен быть в основном разделе, а раздел истории должен быть расширен ссылками на номенклатуру в различных системах. Шмуэль (Сеймур Дж.) Метц Имя пользователя: Chatul ( обсуждение ) 00:54, 17 мая 2020 (UTC) [ ответ ]
- Вы потеряли меня на "отстой". Я тоже иногда использую разговорный язык, но стараюсь этого не делать. Он нажимает кнопки и отключает читателя (меня). ... что касается этих двух определений: библиотека - это набор энергонезависимых ресурсов. Это не _просто_ подпрограммы и классы. Я не думаю, что обе формулировки хороши или легко понятны неспециалисту. ... что касается вашего сопротивления поделиться своим определением: почему бы не разместить его хотя бы здесь? Кажется странно загадочным. Вы производите впечатление воинственного, а не командного игрока. Давайте работать вместе. Stevebroshar ( talk ) 10:42, 5 апреля 2024 (UTC) [ ответить ]
В статье это не проясняется. Azbookmobile ( обсуждение ) 21:16, 27 декабря 2022 (UTC) [ ответить ]
- «Библиотека» — это термин, который в вычислительной технике используется для различных целей. Две цели, упомянутые в библиотеке, это
В информатике библиотека — это набор энергонезависимых ресурсов, используемых компьютерными программами , часто для разработки программного обеспечения . Они могут включать данные конфигурации, документацию, справочные данные, шаблоны сообщений, предварительно написанный код и подпрограммы , классы , значения или спецификации типов . В OS /360 IBM и ее преемниках они называются секционированными наборами данных .
- и
Библиотека также является набором реализаций поведения, написанных на языке, который имеет четко определенный интерфейс , с помощью которого поведение вызывается. Например, люди, которые хотят написать программу более высокого уровня, могут использовать библиотеку для выполнения системных вызовов вместо того, чтобы реализовывать эти системные вызовы снова и снова. Кроме того, поведение предоставляется для повторного использования несколькими независимыми программами. Программа вызывает поведение, предоставляемое библиотекой, через механизм языка. Например, в простом императивном языке , таком как C , поведение в библиотеке вызывается с помощью обычного вызова функции C. Отличие вызова как вызова библиотечной функции от вызова другой функции в той же программе заключается в способе организации кода в системе.
- Да, они не написаны в терминах, доступных неспециалисту, но не все статьи Википедии можно легко сделать доступными для такого читателя. Это может быть не невозможно, но это может быть сложной задачей.
- Второе определение, возможно, является специализированной версией первого, поскольку «реализации поведения...» можно рассматривать как «неизменные ресурсы, используемые компьютерными программами» — это подпрограммы или классы.
- Если вы ищете аналогию с « библиотекой » в обычном смысле этого термина, «библиотека» в вычислительной технике, как уже отмечалось, представляет собой набор материалов для использования либо программистами, либо программами. Некоторые материалы, такие как документация и справочные данные, а также «заранее написанный код», если это означает «исходный код, который вы можете включить в свою программу», предназначены для использования программистами. Другие, такие как заранее написанные подпрограммы и классы, напрямую используются программами и косвенно используются программистами, которые, используя свои программы подпрограммы или классы, не должны писать свой собственный код, чтобы делать то, что делает подпрограмма или класс. (В некоторых языках программирования эти две формы «заранее написанного кода» могут быть одинаковыми.)
- Возможно, введение можно улучшить, сделав его немного понятнее для новичков, но тому, кто хочет понять концепцию вызовов подпрограмм или вызовов методов класса, вероятно, понадобится некоторое понимание того, как работает компьютерная программа, даже если это очень общий и концептуальный уровень (им не нужно знать, как работает машинный код или код на каком-то конкретном языке программирования).
- Как намекнул кто-то, кто прокомментировал вашу страницу обсуждения, объяснять техническую информацию в доступной для неспециалистов манере нелегко. Навыки, необходимые для того, чтобы быть хорошим писателем по науке и технологиям для неспециалистов, могут включать навыки письма на языке, на котором написаны статьи, и понимание науки или технологии, о которой написана статья, но этого недостаточно — писателю также необходимо умение объяснять идеи людям без их уровня понимания. Гай Харрис ( обсуждение ) 02:32, 28 декабря 2022 (UTC) [ ответить ]
- Я участвовал в проектах, где технический писатель, делая документацию более понятной, лишал ее описания программного обеспечения, которое мы писали. Это дало мне возможность оценить тех, кто умеет делать текст более удобным для чтения, не разрушая его смысла. Хороший технический писатель — это радость навсегда.
- К сожалению, большинство редакторов вики не только не являются ни экспертами по предметной области, ни техническими писателями, но и если бы Википедия ограничила редакторов этими двумя категориями, пул редакторов был бы радикально урезан. Только форумы с оплачиваемыми редакторами могут позволить себе быть такими придирчивыми. Как и многие здесь, я стараюсь быть ясным и точным, но надеюсь, что другие смогут прояснить все, что слишком сложно для непрофессионального читателя.
- Может быть, в качестве политики вики могла бы обратиться к сообществу технических писателей и призвать добровольцев? -- Шмуэль (Сеймур Дж.) Метц Имя пользователя: Chatul ( обсуждение ) 13:40, 28 декабря 2022 (UTC) [ ответить ]
Библиотека (вычислительная техника) § Создание и выполнение общей библиотеки в Linux/Unix — это подробный пример того, как построить общую библиотеку в некоторых операционных системах, ориентированных на системы на основе ELF и, в частности, на системы Linux. Он не применим к UNIX-системам, не основанным на ELF ( macOS и AIX ), он предполагает использование gcc и предполагает необходимость запуска ldconfig для обновления кэша общей библиотеки, что, как я думаю, могло быть необязательно в некоторых, если не во всех версиях Solaris .
Вдобавок ко всему, похоже, что это читается как «статья в стиле «как сделать»», если использовать описание того, чему не место в Википедии из WP:NOTHOWTO .
Итак, хотя это может быть полезным руководством, я не считаю его достойным включения в Википедию (которая не предназначена для того, чтобы быть собранием всей полезной информации всех типов (в соответствии с существованием Википедии: Чем Википедия не является ). Гай Харрис ( обсуждение ) 21:12, 22 июля 2023 (UTC) [ ответ ]
- Спасибо. Я удаляю внесенные мной изменения. Wikieditor 2027 ( обсуждение ) 21:25, 22 июля 2023 (UTC) [ ответить ]
Когда я вижу различия, кто-то удалил довольно большой объем контента из этой статьи. Это намеренно? Wikieditor 2027 ( обсуждение ) 07:08, 29 июля 2023 (UTC) [ ответить ]
- Если вы удалите "re" из "removed", оставшееся слово скажет вам, что случилось с этим контентом. Обратите внимание, что первое редактирование последовательности правок, которые вы видели, имеет сводку правок "Material WP:SPLIT to Shared library ". Прочитав это, вы, возможно, захотите взглянуть на Shared library . Guy Harris ( talk ) 07:48, 29 июля 2023 (UTC) [ ответить ]
Некоторые недавние изменения в этом разделе истории о глагольных временах заставили меня внимательно прочитать раздел. В нем была смесь глагольных времен. Но даже с последними изменениями она все еще есть. Я вижу проблему с исторической информацией. Есть ли у Simula классы или были ли у нее классы? IDK, но я действительно думаю, что последовательный лучше; легче читать.
но... абзац о Simula, похоже, по большей части не по теме. Похоже, это учебник по Simula. Какое отношение имеет фраза «его классы почти идентичны современной концепции, используемой в Java, C++ и C#» к библиотекам? Я думаю, этот абзац нужно полностью переписать. Я думаю, что интересная и соответствующая теме идея заключается в том, что классы можно включать в библиотеку, как только концепция класса будет реализована в языке. Stevebroshar ( talk ) 12:50, 7 апреля 2024 (UTC) [ ответить ]