-=RUS=- | Дата: Вторник, 12.08.2014, 15:37 | Сообщение # 1 |
 Генералиссимус
Группа: Администраторы
Сообщений: 352
Статус: Offline
| Я хочу, чтоб к штыку приравняли ки-борд!
#####│ #│ #│ #####│ #│ #│ #│ #│ #│ #│ #│ #│ ##│ #│ #│ #│ #│ #│ ###│ #│ #│ #│ #│ #│ #│ ##│ #####│ #####│ #####│ #│ #│
▒▒▒▒▒▒ ▒▒▒▒▒ ▒ ▒▒▒▒▒▒ ▒▒▒▒▒ ▒ ▒▒ ▒ ▒ ▒ ▒ ▒ ▒ ▒ ▒ ▒▒▒▒ ▒▒▒▒▒ ▒ ▒▒▒▒▒▒ ▒ ▒ ▒ ▒ ▒ ▒ ▒▒▒▒▒▒ ▒▒▒▒▒▒ ▒▒▒▒▒
Независимая файловая газета для программеров
══════════════════════════════════════════════════════════════ Основана в июне 1994 года N#6, 20.1.1995 Цена отсутствует ══════════════════════════════════════════════════════════════
┌───────────────────────────────────┐ │ !!! НОВАЯ РУБРИКА !!! │▒ ╞═══════════════════════════════════╡▒ │ *** Дuck-клуб *** │▒ ╞═══════════════════════════════════╡▒ │ СПЕЦИАЛЬНЫЙ ВЫПУСК: │▒ │ Операционная система - какая она? │▒ └───────────────────────────────────┘▒ ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
┌───────────┐ │ Дuck-КЛУБ │▒ └───────────┘▒ ▒▒▒▒▒▒▒▒▒▒▒▒
В редакцию начали приходить первые письма, и это отрадно - значит, наша работа кому-то нужна. Письма с критикой, с кон- кретными предложениями, с информацией... Но сколько людей, столько мнений. И, соответственно, назрела необходимость соз- дать в нашей газете Дuckуссионный клуб. Что мы и делаем.
Итак, тема сегодняшнего Дuck-клуба - ОПЕРАЦИОННЫЕ СИСТЕМЫ.
В качестве материала для обсуждения предлагаем Вам статью Антона Чижова "Файловая система", опубликованную в журнале "Библиотека информационных технологий. Вып. 1 - "По страницам журнала "Компьютерный мост""." - М, Наука, 1990.
* * *
Эти заметки о программировании я пишу в необычной для себя манере: не буду обобщать, не буду точно формулировать свои мысли, хочу просто порассуждать о тех областях программирова- ния, к которым профессионально имею отношение. В последние 3-4 года я занялся несколько необычной деятель- ностью: стал выдумывать (естественно, с участием друзей и просматривая соответствующую литературу) новые варианты орга- низации файловых систем. Периодически и в западной, и в совет- ской печати появляются статьи о каких-нибудь новых разработках в области организации файловых систем. Что я подразумеваю под "организацией файловых систем"? По моему убеждению, методы хранения данных на внешних носи- телях не слишком изменились за годы развития компьютеров. Ко- нечно, вначале данные хранились на устройствах последователь- ной записи (перфолентах, магнитных лентах), но такую форму хранения информации с некоторой псевдопараллельностью для маг- нитных лент вообще не хочется рассматривать. Это тема для от- дельного разговора, тем более, что свойства ленты как носителя информации как-то пересекаются со свойствами WORM-устройств. WORM (Write Once, Read Many) - один из трех основных типов оп- тических дисков с однократной записью. Как и на магнитной лен- те, данные дописываются в конце. Корневой каталог на устройствах прямого доступа - дисках - был придуман давно. Были придуманы и имена файлов: без масси- вов данных работать трудно. Тогда же наметилось два подхода. Один из них взваливал на плечи пользователя большой груз системных параметров, которые необходимо было задать для создания файлов и доступа к ним: размеры физической и логической записей, способ буферизации, режим доступа к файлу с возможностью доступа к этому же файлу из других программ, и другие параметры, смысла которых многие не представляют, но аккуратно переписывают из одной программы в другую. Большинство советских программистов прошли школу JCL - языка управления заданиями компьютеров ЕС. Однако указывать все эти немыслимые параметры заставляют пользователя! Другой подход - в общем-то, другая крайность - все решает система. Пользователю (программисту при написании программы) надо только указать, что он хочет считать из файла. Такой дос- туп был принят в ОС UNIX. Начисто "выметаются" методы доступа к данным. Программист все делает сам. В качестве инструмента имеются Open, Close, LSeek, Read, Write и в общем-то все. Кро- ме того, с появлением UNIX повсюду внедрились подкаталоги и динамическое распределение пространства на диске. Это исполь- зовалось и до UNIX, но стало применяться все вместе как на уровне реализации, так и на уровне системного интерфейса, мне кажется, только с UNIX. Конечно, какие-то методы доступа выполнялись в виде объект- ных библиотек. Но такой стиль в организации системы породил некоторую анархию в методах доступа к данным. Скорость базы данных во многом зависит от того, как организовано хранение самих данных, справочников, индексов и т.д. И, естественно, аккуратно выполняя базу данных, программист реализует и неко- торый метод доступа к данным. Хороший программист с блеском разрешает эту задачу, иначе мы, скорее всего, не увидим напи- санную им программу. Но при этом программист затрачивает много сил на написание довольно общей части - собственно на метод доступа. Современные файловые системы имеют обычно оригинальные (для пользователя) именования файлов. Это несколько букв и цифр, почему-то разделенных точкой. Размер имени файла обычно слиш- ком мал для достаточно полного указания его назначения, но ве- лик для запоминания. Очень часто буквы могут быть только латинскими и нашему пользователю приходится записывать, что имя ZAPIS1.TXT - это одно, а JFTRES14.DOC - это совсем другое. Причем ему еще нужно объяснить, что DOC - это не слово ДОС, а сокращение слова document. Программистам иногда кажутся смешными эти проблемы, они привыкли к английским буквам и сокращениям типа CHKDSK. Мне лично произнести это имя трудно, но невольно приходится делать при вызове команды (из-за чего я ее переименовываю). Поэтому при недостаточном знании языка каталог напоминает текст международной телеграммы: русские названия - английскими буквами, что тяжело для пользователя. Еще одна проблема: зачем программисту знать, что между ком- пиляцией и получением готовой программы есть еще одна стадия - линковка. И вытекающая отсюда необходимость иметь .OBJ файл. Обычно при создании программы программист пишет .C, .H (если на C) файлы. Затем вызывает пакетный файл и получает... .OBJ, .MAP, .SYM, .LST, иногда .TMP и, наконец, .EXE файлы. После исправления ошибки он вдруг обнаруживает в каталоге .BAK фай- лы, которые не просил создавать. Если же .H и .C файлы имеют одинаковые имена, например TEST.C и TEST.H, то трудно дога- даться, что содержит TEST.BAK. Программисты (в общей массе) любят не пользователя, а прог- раммирование. Но пользователя, как и пешехода, надо любить. Пользователи составляют большую часть человечества. Это поль- зователи изобрели компьютер и воспитали из себя программистов. И тут мировых пользователей стали "давить" (как пешеходов у Ильфа и Петрова). Если пользователя давить, то получается программирование ради программирования. За примерами далеко ходить не надо. Настолько плохо обстоит дело с отладчиками. Большинство программистов воспринимает их как чисто отладочное средство, так как в отладчике настойчиво используются A, B, C и т.д. Почему у программистов не 16 пальцев на руках! Все было бы так просто! А с десятью пальцами сумеет ли он посчитать, сколько будет 14*6 в восьмеричной системе счисления? Появились даже часы с калькулятором, работающим в двоичной, восьмеричной и шестнадцатеричной системах счисления! Это все следствия одной проблемы - неправильной структуры системного обеспечения, а отсюда стиля программирования. Ко- нечно, особенно у нас, в СССР, играют роль и такие факторы, как отсутствие рынка программных средств, попытки всех писать для себя инструменты и совсем немного ими пользоваться, так как необходимо вновь писать более хорошие инструменты и т.д. Но для меня сейчас ближе проблемы структуры системного обеспечения. Структура файловой системы (наконец-то до нее добрались) - составная часть этого. Файловая система должна играть значительно большую роль, чем сейчас: создавать большие возможности программисту и легко управляться конечным пользователем. Для этого она должна сос- тоять из набора компонент, которые, как детали в пластиковом конструкторе LEGO, можно прикреплять друг к другу, создавая сложные композиции. Идея, древняя, как мир - разделяй и властвуй! Но этим тези- сом может воспользоваться только тот, кто умеет, во-первых, разделять. Это очень непростая задача. С одной стороны, надо сохранять целостность системы, с другой - разделить на незави- симые компоненты. С одной стороны, система должна аккуратно реализовать то, что сейчас необходимо, с другой, позволять расширять себя не только новыми детальками, но и видами клея, который скрепляет детальки, новыми формами деталек, которые даже в голову не могли прийти при конструировании первого ва- рианта. Такая система не может модернизироваться, а только расширяться. Если предусматривать расширение экстенсивное - добавление новых деталек, которые постепенно должны заменить старые, то получатся, как в MS DOS, две файловые системы - старая, использующая FCB, и новая, в стиле UNIX. И хотя старой никто практически не пользуется, ее приходится тянуть за со- бой. И, конечно, система кирпичиков должна базироваться на со- ответствующей поддержке в ядре системы.
* * *
Трудно не согласиться, что описанная А. Чижовым структура ОС является наиболее рациональной. Хорошая операционка должна быть прежде всего модульной, расширяемой. В противном случае очередная версия системы либо теряет совместимость с предыду- щими, либо вынуждена тащить за собой груз прошлых неудач. Как же должна выглядеть хорошая операционная система?
────────────────────────────────────────────────────────────── (Все нижеследующее является исключительно личным мнением Dale corp. и, соответственно, может (и должно быть) оспорено). ──────────────────────────────────────────────────────────────
По определению, ЯДРО системы должно содержать только необ- ходимый минимум функций - наименьшее возможное их количество, позволяющее организовать ВСЕ операции с внешними устройствами. Все, что можно вынести в утилиты (копирование и переименование файлов, конфигурирование системы, etc.), должно быть вынесено в них. Интерпретатор командной строки и процессор пакетных файлов также должны быть подгружаемыми по мере необходимости. Попутно встает вопрос: а нужна ли командная строка вообще? Гораздо удобнее ввести в NORTON-подобную оболочку режим запус- ка программы с параметрами. Все остальные функции, реализуемые командной строкой, уже давно перешли в оболочки. Кроме того, избавившись от жестких требований командной строки, можно упростить и усовершенствовать язык пакетных файлов. Достаточно очевидна необходимость совместимости версий сис- темы "снизу вверх" (т.е. как минимум последующих с предыдущи- ми) как по формату диска, так и по системным функциям. Это означает безбедную жизнь для пользователя и значительную эко- номию труда программиста - последнему не придется каждый раз модифицировать свои разработки для обеспечения их работоспо- собности под новой версией системы. Еще одна полезная возможность, которую неплохо иметь в сис- теме - работа не только с устройствами произвольного доступа (НГМД, винчестеры, электронные диски и т.п.), но и с нефайло- выми устройствами - магнитофоном, принтером, модемом - пример- но так, как в MS-DOS. Так, в последней вывод текста на принтер сводится к простому копированию соответствующего файла на не- файловое устройство "PRN". В совокупности с легко изменяемым набором подключаемых (а не жестко встроенных в систему!) драй- веров это значительно упрощает работу. Система должна быть более приспособленной к особенностям БК, нежели существующие. Нужна ли пользователь ANDOS совмести- мость с IBM сейчас, когда он набивает текст на БК? Вряд ли. Эта совместимость понадобится только через некоторое время, когда он запишет набранный текст на диск и вставит последний в дисковод IBM. И только ради этого радостного момента ANDOS каждый раз перекодирует имена, тасует кластеры, распаковывает и запаковывает ячейки FAT... Однако того же результата можно добиться и другим способом - всего лишь написать к любой су- ществующей системе пару утилиток: одну - для переброса файлов с IBM на БК, другую - для обратного. Нет, система для БК должна иметь свою собственную организа- цию, близкую не какой-то там IBM, а именно БК. Взять хотя бы каталог. Во-первых, необходимо 16-символьное имя, причем без какой-либо логической обработки. Опыт показывает, что перепа- ковка имени в ANDOS порождает немало проблем. Далее, каталог не должен быть фиксированного размера - в будущем это помешает нормальной работе с устройствами, значительно более емкими, нежели гибкие диски. Как следствие, каталог произвольного раз- мера нельзя считывать в ОЗУ целиком (кто знает, до каких раз- меров он может разрастись?). В то же время доступ к каталогу не должен сильно замедлять работу. Чрезвычайно нужен файлер - подпрограмма, позволяющая выб- рать нужный файл с помощью инверсной строки. Вход в файлер происходит по EMT 36 с пустым (состоящим из пробелов) именем в блоке параметров. Сохранение и восстановление участка экрана под появляющимся окном обязательно - ведь для некоторых прог- рамм порча экранного ОЗУ означает их гибель. По тем же причи- нам файлеру нельзя пользоваться стандартными EMT. Кроме пере- ключения текущего устройства и выбора файлов, файлеру можно поручить также удаление последних и другие несложные операции. И, наконец, операционку следует разделить по платформам. Система, предназначенная для работы на БК-0010, не должна со- держать в себе ненужных здесь переключений страниц, подгрузок "десяточного" монитора и прочих "одиннадцатых" прибамбасов. Ее же вариант для БК-0011 (полностью совместимый по внешним свя- зям, т.е. по формату диска, функциям, драйверам, etc.), напро- тив, не включает ни байта того, что необходимо только на "де- сятке". Попытка системы поддерживать обе платформы одновремен- но пагубно сказывается на ее длине (особенно это касается за- грузчика).
────────────────────────────────────────────────────────────── Вы познакомились с одним из мнений по поводу того, как дол- жна выглядеть хорошая операционная система. Если Вы хотите высказать свое мнение, внести свои замечания, предложить новую тему для разговора - пишите! Дuckуссионный клуб ждет Ваших пи- сем!
───────────────────┬───────────────────────────┬────────────── УЧРЕДИТЕЛЬ │АДРЕС РЕДАКЦИИ: │ Тираж Dale Publishing co.│241047, Брянск 47, а/я 109.│неограниченный ───────────────────┴───────────────────────────┴────────────── Номер сверстан в издательской системе VorteX!
|
|
| |