Новости
Описание
Текущая версия
История
Скриншоты
OS Menuet
Дистрибутивы
Загрузчики
Программы
Статьи
FAQ
Hardware List
Рассылки
Наша команда
Публикация
Конкурс
Форум
О Menuet
Другие OS
Программисту
|
|
|
Никита Лесников (nlo_one@mail.ru) По каким критериям определяют, "хорошая" программа или "плохая"? Ответ простой: по разным. Пользователю наплевать на внутреннюю архитектуру, лишь бы выглядело покрасивее. Программисты же оценивают софт иначе: у них хорошая программа должна быть быстрой, простой, гибкой, надежной и, самое главное, занимать как можно меньше места. Сейчас можно часто услышать "наставления" "чайников": "если программа\игра большая - значит, хорошая, если маленькая - нечего даже устанавливать". Существует множество опровержений данного факта, но на вышеобозначенных "специалистов" они обычно не производят никакого впечатления. Финнский студент Вилле тоже хочет еще один раз опровергнуть упомянутое высказывание, дав программистам возможность писать на ассемблере под ассемблерную ОС. Факт в том, что многие разработчики несерьезно относятся к процессу программирования, не используя потенциал MeOS на полную мощность. Цели их переубеждения и посвящена данная статья. Вроде бы все откровения сказаны, начнем... Большие объемы данных. Как-то раз на форуме MenuetOS.org Tony Ruotto спрашивал, как в асме объявить массив, заполненный числами от 0 до 99. Ему предложили с десяток различных способов, но все они сходились в одном: написать какую-нибудь директиву, которая вставит нужный массив в исполнимый код. Конечно, хорошо, если массив занимает 100-200 байт, но если 5-6 мегабайт? Лично у Вилле в WEBVIEW наблюдается следующая картина: в исполнимом файле только 5 Кб кода, а все остальное заполнено нулями. Неужели не эффективнее использовать директивы equ для вычисления адресов переменных, а инициализировать из значения с помощью элементарных rep stosb? У меня в MHC используется именно такой подход, т.к. по другому просто нельзя: общий размер окон поиска и хеш-таблицы более 2-x мегабайт, и при использовании "стандартного" метода объявления данных архиватор просто не влез бы на дистрибутивную дискету! Поэтому всегда объявляйте переменные более 200-300 байт размером косвенно, с помощью директив equ - это поможет Вам уменьшить размер Ваших программ. Перерисовка окна. ПРИМЕЧАНИЕ: Данный совет, возможно, покажется некоторым банальным, но я, тем не менее, привожу его здесь. Во-первых, не забывайте включать оконную функцию в "рамки" из вызовов 12-й функции. Отсутствие такого "обрамления" часто влечет за собой существенные проблемы, как, например, "зависание" программы при попытке перетаскивания окна. Во-вторых, как можно чаще используйте буферизованный вывод графических данных, как, например, это сделано в FIRE. Надеюсь, никому не надо объяснять разницу в скорости записи/чтения в видеопамять и обычное ОЗУ? Кроме того, сложность реализации и необходимость задания большого количества параметров при вызове 1-й API-функции очень сильно замедляют попиксельный вывод. Многооконные приложения. Наверняка, Вам известно, что в MeOS каждый процесс может иметь только одно окно. С первого взгляда проблема создания многооконных приложений кажется неразрешимой, если не учесть одно "но"... А именно: последние версии Менуэта позволяют запустить несколько процессов в адресном пространстве одной задачи (Примеры программ, использующих этот метод: AIRC, THREAD). Так что же мешает запустить по процессу для каждого окна? Единственное, о чем надо позаботиться, так это выделение индивидуальных стеков. Более подробные сведения о создании нескольких процессов в одной задаче см. SYSFUNCS.TXT и "Programming with MenuetOS". Изменение размера и положения окна в realtime. Потребность в динамическом изменении размеров окна возникает нечасто. Тем не менее, у многих она вызывает проблемы, хотя способ ее реализации смехотворно прост. Необходимо всего лишь объявить глобальные переменные, описывающие длину, ширину, цвет фона и др., и при необходимости изменять их значения с последующим вызовом оконной функции. При этом оконную функцию необходимо также немного подправить: вместо задания констант в вызове 0-й функции нужно написать ссылки на соответствующие переменные. Кроме того, оконная функция ОБЯЗАТЕЛЬНО должна быть "обрамлена" вызовами 12-й функции, иначе никакого эффекта наблюдаться не будет. Те же самые действия можно использовать для изменения положения окна на экране. Эмуляция FPU с помощью Fixed-Point арифметики. Возможно, Вы, прочитав заголовок данного подпункта, усмехнетесь: "А зачем вообще эмулировать сопроцессор? Неужели есть пользователи, у которых он не интегрирован с главным процессором?". Таких пользователей, несомненно, очень мало, но суть проблемы в другом. Вам не надо объяснять, что Menuet - система многозадачная, а потому требующая постоянного сохранения состояния задач для предотвращения "вылетания". Так вот, дело в том, что сохранение состояния сопроцессора в Менуэте не предусмотрено, а потому любая попытка использования инструкций FPU приведет к аварийному завершению работы приложения. Однако необходимость в точных вычислениях возникает довольно часто. Поэтому здесь я опишу один из самых простых, но одновременно и очень эффективных способов: арифметику с фиксированной точкой (Fixed-Point arithmetics). Fixed-Point числа представляют собой обычные двоичные числа, между жестко заданными двоичными разрядами которых стоит воображаемая точка. Причем чем дальше от 0-го разряда данная точка отстоит, тем точнее будут вычисления. Т.к. Fixed-Point числа представляют собой обычные двоичные числа, арифметические действия над ними можно выполнять обычными математическими командами процессора. Необходимо только написать процедуры конвертации из Fixed-Point формата в обычное число и обратно. Сделать это очень легко: т.к. точка всегда расположена между жестко заданными разрядами, конвертации сводятся в обычным сдвигам. Например, у Вас в регистре EAX есть некоторое целое число, которое вы хотите преобразовать в Fixed-Point формат с четырьмя двоичными разрядами после точки. Сделать это просто: достаточно использовать команду shl eax,4. Для обратной конвертации в целое число с отбрасыванием дробной части используем команду shr eax,4. Для того, чтобы округлить Fixed-Point число до ближайшего целого, необходимо выделить дробную часть, потом конвертировать Fixed-Point в целое число, и, проанализировав дробный "хвост", принять решение. Опять же, допустим, что Fixed-Point число хранится в регистре EAX. Тогда округлить его до ближайшего целого можно следующим образом: mov bl,al and bl, 1111b shr eax,4 cmp bl,7 jna no_increment inc eax no_increment: Процедуры ввода\вывода чисел в Fixed-Point формате попробуйте написать сами. В этом разделе описаны инструменты, которые я использую для разработки программ под MeOS, и которые Вам также могут пригодиться. Во-первых, нужен сам Менуэт для тестирования программ. А как же без него? Но здесь существуют некоторые неудобства. Менуэт грузится с дискеты очень медленно. Можно, конечно, заставить MASH запускать приложения с HD, но это не лучший выход. Лично я пользуюсь тремя самодельными утилитками, которые когда-то написал за полчаса. Это mextract, который отделяет образ диска от MSETUP.EXE и записывает его в файл MSETUP.IMA, mdistr, создающий MSETUP.EXE из MSETUP.IMA, и mdosload, эмулирующий функции BIOS и грузящий Menuet из MSETUP.IMA в текущей папке в чистом DOS'е. Файл MSETUP.IMA можно редактировать программой WinImage. Когда-нибудь надо посерьезнее заняться этими программками и опубликовать их в Internet, т.к. они одновременно облегчат жизнь разработчиков и сделают реальностью запуск Menuet'а из Boot-Menu DOS'а. В принципе, любой более-менее разбирающийся в системном программировании человек может написать что-либо подобное на C или Паскале меньше чем за час. Во-вторых, желательно скачать из Инета FASM for Windows(ссылка есть на MenuetOS.org в разделе "Documents"). Все-таки пока что удобнее писать программки под Windows, иногда подгружая Менуэт для их тестирования. В-третьих, нужен какой-нибудь файловый менеджер, т.к. FASM работает из командной строки, да и с файлами там работать удобнее. Лично я использую FAR, что рекомендую делать и Вам. На мой взгляд, лучшего файлового менеджера просто нет и не факт, что когда-нибудь появится. И, раз вы решили пользоваться FAR'ом, скачайте для него замечательный плагин "Colorer" (адрес не помню, поищите на Рамблере или Yahoo!). Он добавляет к редактору и вьюверу FAR замечательную возможность: подсветку синтаксиса более 90 языков, в том числе и ассемблера. Теперь вы сможете набивать ассемблерный код прямо во встроенном редакторе, что, несомненно, очень удобно. Ну вот, вроде бы все сказано, удачного программирования! P.S. Если в "Аспектах" вам что-нибудь не удалось реализовать, пишите мне на E-Mail: nlo_one@mail.ru. Я пришлю вам нужный исходник. Также присылайте свои пожелания и критику. |
