| -=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!
|
| |
| |
.
