На /me напала техническая муза, и /me не смог от нее отбиться...
Итак, не пытаясь казаться умнее Танненбаума и K, попробую подумать, что вообще из ОСей можно бы написать на Форте.
Для начала, не будем путать операционную систему и набор утилит операционной системы. Минимальную ОС, умеющую передавать управление программам, написать действительно не так уж сложно. Но в стандартном PC-совместимом компьютере много периферийных устройств. Никто не считает, что процессор имеет ножки, подключенные к USB, HDD, клавиатуре?
Нет?... Это радует. Потому что процессор как таковой может разве что писать и читать ячейки памяти, да еще выдавать некие байтики на шину. BIOS позволит ему писать и читать блоки (сектора) с дисков и проверять коды клавиш... вобщем-то все. А дальше как раз и начинается работа ОС.
Начнем с того, что если мы хотим пользоваться одним винчестером без риска запортить его содержимое так, чтобы потом и Win (Linux) не прочитал, надо поддержать стандартную файловую систему. На сегодняшний день это хотя бы FAT32. Ее организация не запредельно сложна, но она
есть. Например, там есть заголовки, есть две копии собственно таблиц размещения (кстати, все в курсе, зачем две?), есть определенные правила исправления ошибок. Кроме того, хорошо бы еще уметь восстанавливаться после сбоев на поверхности (для bad-блоков есть свои пометки). Вот это все надо уметь делать. Опять же scandisk.
Идем дальше. Надо работать с сетью, USB и дисплеем. Напоминаю, драйверы потеряны. 99,9% функций, которые представляются в голове для работы с этими устройствами, существуют только в готовых ОС! Все это придется написать самостоятельно.
Наконец, самое интересное. Нам же еще надо встраиваемые системы? Они сейчас потребляют 96% выпускаемых процессоров. И вот тут мы узнаем, что большая часть таких систем вообще-то однозадачная, не имеет винчестера, сети и USB, а вывод ограничен простыми индикаторами. И все усилия по созданию ОС с вытесняющей многозадачностью, кучей периферии и умным распределением памяти пропали впустую, потому что кофеварка или "умный" двигатель просто не требуют такого. Вывод? Надо бы что-то универсальное, с настройкой на процессор, периферию и прочее. Итого: проект разрастается.
И в итоге мы приходим к старой как мир проблеме противостояния (или
дополнения) универсальности и специализации. Известно, что специализированное средство гораздо эффективнее решает частные задачи. В приложении к нашим реалиям это означает, что будет большой соблазн плюнуть на медленный процесс написания "совсем универсальной поддержки", потому что есть возможность быстренько написать то же самое, но для конкретных условий. И оно будет меньше, компактнее и быстрее. Так что резон делать очень даже серьезный. С другой стороны, провели абстрагирование от аппаратной платформы, и пожалуйста - внесением некоторых несложных настроек получаем адаптацию к любой аппаратуре. Это в теории. На практике сколько-нибудь грамотное тестирование этой универсальности и ее устойчивой работы с
разными настройками потребует столько человеко-часов, что к моменту завершения тестирования придется сразу же переходить к добавлению нового оборудования, процессоров и протоколов
Посмотрим теперь на сильные стороны Форта в существующих ОС.
1) Windows/*nix. Вобщем, персональные компьютеры разных типов. Форт сделан в виде shell, компактен, имеет возможность быстро оттранслировать и подключить различные файлы. Вобщем, мощный и очень хорошо расширяемый скриптовй язык, при этом обладающий производительностью скомпилированного кода (собственно, он же и есть компилятор). Опять же JIT, что позволяет не запускать сложные оболочки для написания простых программ. Интерпретатор позволяет быстро проверить написанный код (хорошо для приложений класса "Автоматизированное рабочее место"). Быстрое перемещение между уровнями - сейчас работаем с портами и файлами, а потом вызвали MS Excel... Настраиваемый синтаксис дает возможность создавать Domain-Specific Languages (Форт тут вообще неузнаваем - просто какая-то компактная программа). Все эти преимущества позволяют смириться с чуть меньшей производительностью и отсутствием возможности нарисовать мышью форму.
2) Встраиваемые системы начального-среднего уровня (уже не датчик освещенности, включающий настольную лампу, но еще и не роутер с Linux-ом внутри). Огромная проблема - широчайший спектр процессоров, периферии для них и режимов ее работы. Файлы настроек? Да как-то не вполне логично писать
Код:
КОЛИЧЕСТВО_USB 0
, если USB и в помине нет. Кстати, каждый лишний байт здесь будет служить основанием для отказа от такой системы - память не всегда измеряется в 256-Мб линейках. Дешевые системы могут иметь мало памяти, и тем они часто и ценны. Здесь опять Сцилла и Харибда: сделаем слишком много - будет громоздко, сложно в настройке и тестировании. Сделаем слишком мало - а что, собственно, сделано-то и как этим вообще пользоваться? Что же тут хорошего от Форта? А например, то, что он "с колес" готов работать, и часто никакой ОС вообще не требует. Записать в ПЗУ образ памяти форт-транслятора и при старте передать на него управление часто бывает достаточно. От ОС остаются, собственно, утилиты ОС, т.е. библиотеки поддержки аппаратуры, которые настолько же разнообразны, насколько разнообразна аппаратура. Вытесняющая многозадачность? Это кнопка "стрелка влево" будет вытеснять кнопку "стрелка вправо"?
Поллинг+прерывания.
Вообще, всегда логично и резонно активно использовать сильные стороны и всемерно устранять слабые. В чем сейчас слабая сторона Форта с организационной точки зрения? Малое community, невозможность организовать масштабный проект и тем самым пойти по проверенному пути, необходимость выполнения рутинных действий по повторению функциональности уже готовых решений. В чем сильная сторона? Быстрая разработка интерпретирующих надстроек, модификация правил интерпретации и компиляции. А в чем теперь сильная сторона mainstream? Готовые отлаженные библиотеки, масса кода, возможность найти "предельные" решения (максимально производительные, максимально универсальные, максимально совместимые со стандартом). В чем их слабость? Для эффективного использования требуется работать в том же стиле - загружать системы разработки, разрабатывать интерфейсы, связывать интерфейсные компоненты с кодом и компилировать. "Аморфность" и слабая формализуемость правил организации интерфейса для конкретного приложения (ну откуда же я знаю, что и в каком порядке захочу вызывать?) в сочетании с постоянным возрастанием объема полезного кода делают в последнее время популярными языки типа tcl - он как язык программирования может не так чтобы очень много, но вот организовать взаимодействие кнопок на экране с другим кодом может вполне. Объединяем сильные стороны Форта и сильные стороны ЯВУ... и получаем то, что есть. Форт может запускать код как оттранслированный им же, так и разнообразные dll. Есть готовое стандартное решение - пишем WINAPI. Нет - делаем его на Форте, или склеиваем из готовых кусочков с помощью Форта же. Задача заключается в том, чтобы еще больше усилить эту эффективность. Не надо пытаться сделать "такое же, только на Форте". Оно в
лучшем случае получится такое же (а в "нормальном" будет упражнением по освоению какого-то алгоритма). В худшем же будет бесцельно потраченное время и разочарование.