Эрик Реймонд - Искусство программирования для Unix
- Название:Искусство программирования для Unix
- Автор:
- Жанр:
- Издательство:Издательский дом Вильямс
- Год:неизвестен
- Город:Москва
- ISBN:5-8459-0791-8
- Рейтинг:
- Избранное:Добавить в избранное
-
Отзывы:
-
Ваша оценка:
Эрик Реймонд - Искусство программирования для Unix краткое содержание
Книги, подобные этой, редко появляются на прилавках магазинов, поскольку за ними стоит многолетний опыт работы их авторов. Здесь описывается хороший стиль Unix- программирования, многообразие доступных языков программирования, их преимущества и недостатки, различные IPC-методики и инструменты разработки. Автор анализирует философию Unix, культуру и основные традиции сформированного вокруг нее сообщества. В книге объясняются наилучшие практические приемы проектирования и разработки программ в Unix. Вместе с тем описанные в книге модели и принципы будут во многом полезны и Windows-разработчикам. Особо рассматриваются стили пользовательских интерфейсов Unix-программ и инструменты для их разработки. Отдельная глава посвящена описанию принципов и инструментов для создания хорошей документации.
Книга будет полезной для широкой категории пользователей ПК и программистов.
Искусство программирования для Unix - читать онлайн бесплатно полную версию (весь текст целиком)
Интервал:
Закладка:
К сожалению, в отличие от технического дизайна, окружавшая BeOS бизнес- стратегия была не столь мудрой. Программное обеспечение BeOS первоначально было привязано к специализированному аппаратному обеспечению и продавалось только с неопределенными указаниями о целевых приложениях. Позднее (в 1998 году) операционная система BeOS была перенесена на общее аппаратное обеспечение PC, а мультимедийным приложениям было уделено более пристальное внимание, но система так и не привлекла критическую массу приложений или пользователей. Наконец, в 2001 году BeOS уступила комбинации антиконкурентного маневрирования Microsoft (судебный процесс продолжался в 2003 году) и конкуренции со стороны вариантов операционной системы Linux, адаптированных для обработки мультимедиа.
3.2.6. MVS
MVS (Multiple Virtual Storage) — ведущая операционная система IBM для мэйнфреймов корпорации. Ее происхождение связывают с OS/360, операционной системой IBM, появившейся в середине 60-х годов прошлого века. IBM планировала, что данная система будет использоваться клиентами на новых в то время компьютерных системах System/360. Потомки этого кода остаются основой сегодняшних операционных систем для мэйнфреймов IBM. Хотя код был почти полностью переписан, основная конструкция осталась почти совершенно нетронутой. Обратная совместимость поддерживается настолько тщательно, что приложения, написанные для OS/360, работают без модификаций в MVS для 64-битовых мэйнфреймов z/Series, появившихся на 3 архитектурных поколения позже.
Из всех рассматриваемых здесь операционных систем только MVS может считаться более старшей, чем Unix. Данная система также менее остальных подверглась влиянию идеи и технологии Unix и представляет надежнейшую конструкцию, противоположную последней. Унифицирующей идеей MVS является то, что вся работа формируется в виде пакета. Система разработана для наиболее эффективного использования машины для пакетной обработки больших объемов данных с минимальной необходимостью взаимодействия с пользователями.
Собственные MVS-терминалы (серии 3270) функционируют только в режиме блокировки. Пользователю предоставлен экран, который он заполняет, модифицируя локальную память терминала. Прерывание не происходит до тех пор, пока пользователь не нажмет клавишу отправки. Взаимодействие с помощью командной строки, подобное Unix-режиму непосредственного ввода данных с клавиатуры, невозможно.
Оснастка TSO, ближайший эквивалент интерактивной среды Unix, ограничена в собственных возможностях. Каждый пользователь TSO представлен остальной системе в виде условного пакетного задания. Данное средство является настолько дорогим, что круг его пользователей обычно ограничен программистами и обслуживающим персоналом. Обычно пользователи, которым необходимо только запускать приложения из терминала, почти никогда не используют TSO. Вместо этого они работают через мониторы транзакций, которые являются одним из видов многопользовательского сервера приложений, поддерживающего невытесняющую многозадачность и асинхронный ввод-вывод. В сущности, каждый вид монитора транзакций представляет собой специализированный дополнительный модуль разделения времени (отчасти подобный Web-серверу, выполняющему CGI-программу).
Другое следствие архитектуры, ориентированной на пакетную обработку, заключается в том, что создание подпроцессов является медленной операцией. В данной системе намеренно большая пропускная способность достигается ценой дорогостоящей установки (и связанной с этим задержки). Подобный подход хорошо соответствует пакетным операциям, но плохо сказывается на интерактивном отклике. Предсказуемым результатом является то, что сегодняшние пользователи TSO почти все время проводят в диалоговой интерактивной среде, ISPF. В редких случаях программисты делают что-либо внутри собственной среды TSO за исключением запуска экземпляра ISPF. Это устраняет издержки создания дочерних процессов ценой введения очень большой программы, которая выполняет все, кроме включения кофеварки.
Операционная система MVS использует аппаратный блок MMU. Процессы выполняются в отдельных адресных пространствах. Межпроцессный обмен данными осуществляется через совместно используемую память. В системе имеются средства для организации параллельной обработки (которая в MVS называется "созданием подзадач" (subtasking)), однако они используются незначительно, главным образом ввиду того, что данное средство легко доступно только из программ, написанных на ассемблере. Вместо этого типичное пакетное приложение представляет собой короткие серии вызовов тяжеловесных программ, связанных вместе с помощью JCL (Job Control Language — язык управления заданиями), обеспечивающим создание сценариев трудоемким и негибким способом. Программы в задании сообщаются посредством временных файлов. Фильтры и подобные им средства почти невозможно реализовать удобным способом.
Каждый файл имеет формат записи. Иногда формат подразумевается (например, предполагается, что встроенные в JCL файлы ввода имеют формат записи фиксированной длины (80 байт), унаследованный от перфокарт), но чаще он указывается в явном виде. Многие файлы системной конфигурации имеют текстовый формат, но файлы приложений обычно записываются в двоичных форматах, специфичных для определенного приложения. Некоторые общие инструменты для просмотра файлов развились из абсолютной необходимости, но до сих пор не являются простой для разрешения проблемой.
Безопасность файловой системы была поздним дополнением к первоначальной конструкции. Однако когда выяснилось, что безопасность необходима, IBM добавила соответствующие функции оригинальным способом: разработчики определили общий API-интерфейс функций безопасности, а затем все запросы на доступ к файлам перед обработкой направили через данный интерфейс. В результате существует по крайней мере три конкурирующих пакета обеспечения безопасности с различной философией дизайна, и все они весьма хороши, учитывая то, что известных взломов между 1980 и 2003 годами не было. Это многообразие позволяет при инсталляции выбрать пакет, который наилучшим образом подходит для локальной политики безопасности.
Сетевые средства также были добавлены с опозданием. В описываемой системе отсутствует понятие одного интерфейса для сетевых соединений и локальных файлов. Их программные интерфейсы разделены и полностью различны. Это действительно позволило набору протоколов TCP/IP достаточно безболезненно вытеснить собственную модель сети IBM — SNA (Systems Network Architecture — системная сетевая архитектура), которая считалась предпочтительным сетевым протоколом. В 2003 году все еще можно было увидеть использование обеих архитектур в определенной инсталляции, однако SNA все же отмирает.
Читать дальшеИнтервал:
Закладка: