Суббота, 19.08.2017, 17:43

..



Главная Регистрация Вход
Приветствую Вас, Гость · Браузер: « v»
[ Новые сообщения · Участники · Правила форума · Поиск · RSS ]
Страница 1 из 11
Всё об «Электроника БК0010(-01), БК0011(М)»! » Газеты | Документации | Статьи | Журналы » Газеты на «БК001x» » «Дuck Tales» » «Дuck Tales N#6» [20.01.95] (Автор: Dale publishing co.)
«Дuck Tales N#6» [20.01.95]
-=RUS=-Дата: Вторник, 12.08.2014, 15:37 | Сообщение # 1
Генералиссимус
Группа: Администраторы
Сообщений: 350
Репутация: 1
Статус: 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!


 
Всё об «Электроника БК0010(-01), БК0011(М)»! » Газеты | Документации | Статьи | Журналы » Газеты на «БК001x» » «Дuck Tales» » «Дuck Tales N#6» [20.01.95] (Автор: Dale publishing co.)
Страница 1 из 11
Поиск:

-=RUS=-
ICQ: 320867225