-Музыка

QuickBasic PDS 7.1 GUI и иже с ним

Воскресенье, 15 Февраля 2009 г. 03:38 + в цитатник


стащено с imagefap
Этот пост можно не читать, он целиком и полностью состоит из кодинг-ориентированного задротства.
Если какое-то слово в заголовке осталось непонятным, или не хватает интереса к теме, можно смело пропускать - ничего не упустите.


В колонках играет - David Bowie - Changes


Я решил выложить его здесь и на русском чтобы быть хоть как-то проиндексированным в сети на тему бесцельного кодинга в древнем компиляторе Microsoft QuickBasic (QBASIC,PDS). За отсутствием времени и желания правильно переводить его в технический английский, я укажу лишь ключевые слова, хотя на просторах нашей родины довольно мало задротов (здесь это не оскорбление), участвующих в теме написания GUI устаревшими средствами.

Я также не мню себя великим системщиком или кодером, играющим современными понятиями веб-ориентированного программирования, ограничиваясь языками высокого уровня начала-середины 90-х. Цель такого времяпрепровождения также непонятна мне, как и 8 лет назад, но наверное она схожа с целями таких же забугорных задротов, как Jacob Palm :

That's why I decided to make a graphical interface (GUI for short) myself. When you make a GUI yourself, you can leave out all the stuff you newer use anyway, which will make the GUI faster and smaller, allowing it to run on old computers, too.

Of course you don't necessarily have to replace Windows or DOS with your GUI. You can make one just for fun, or maybe for other people to use. The reason I make a GUI is that I think it's funny to see how much I can get the computer to do, how nice I can make it look, how far I can push QBasic and such.


То есть, цель донельзя тупиковая:) но интернациональная - я встречал GUI даже китайского производства с поддержкой символов настолько специфичного национального codepage. Кстати, сей сайт надеюсь в скором времени примет и мою наработку, когда я наконец застану Todd Suess'a в онлайне.



Предыстория

Когда я затеял всё это дело, было мне 12, и QuickBasic (что 1.1, что 4.5, что даже PDS) были уже крайне устаревшими средствами разработки, в области разработки приоритетным было уже направление user-friendly оконное программирования (и разгул web 1.0 с преподносимой мелкомягкими пресловутой интеграцией =), но для конечного пользователя ПК ориентирами того, что его любят, оставались естественно менюшки, окошки и курсоры. Ну и специфические детали вроде синенького (norton) или зелененького (w95) фона (от остального тётечки, печатающие одним пальцем тут же бежали с валидолом к админам тогда еще полностью локальных сетей).
И вот этот психологический мотив - зелененькое, и зацепил меня в некоем скриншоте (уж не помню у Тодда или кого-еще я его увидел) поделки на QB, именуемой Menuwork (или даже SqaureOS):
SqaureOSMenuwork
Больше всего меня поразила возможность писать остальными шрифтами, нежели пресловутым консольным, использовать мышь и вообще видноподобность в QB(!). Код сырца оказался на удивление понятным, и шрифтовые процедуры мне крайне понравились тем, что растровые файлы были редактируемы обычным блокнотом (значительно модифицированная, она до сих пор используется и в том, что я хочу показать). Спустя непродолжительное время, я был почти готов представить публике (но не представил =) первый блин комом:
 (646x505, 21Kb) (646x505, 32Kb) (646x505, 35Kb)

Мне не удалось запустить по-нормальному этот GUI сейчас по причине того, что много воды утекло, да и dosbox не идеален. И даже есть некое чувство стыда и смущения за первую попытку в силу детской непонятливости даже базовых принципов программирования интерфейсов и взаимодействия программ в многозадачных режимах.
Собственно в этом "эмуляторе" была еще одна задумка - плагиат на "тогда широко распространенные программы-шутки с какой-то там BBS", когда на EGA-дисплее 286 машинки появлялся логотип и рабочий стол 9x, но хоть с какой-то функциональностью. Как это всё работало? Естественно, море багов. Программулька умела рисовать окошки в духе Windows 95, выводить картинки собственного (ужасного) формата, где 4х-битное изображение для режима SCREEN 12 кодировалось 1 байтом (то есть правилось побайтно с помощью читаемых символов "X,;,|,\,/,:," через текстовый редактор), на дисплей оно выводилось оооочень медленно, курсор мыши тоже представлял из себя нечто из разряда индусского кода (см. lurkmore), текстовые рутины (см. выше=), а подоконное пространство из видеопамяти перекочевывало в неоправданно огромные массивы через PIXEL (а порой и перерисовкой всего дисплея запнимался). К файловой системе я вообще не мог тогда обращаться - вся поделка обращалась к большому файлу через LINE INPUT, со скрежетом который можно назвать "image" (зато он поддерживал так сказать LFN).
На мое нынешнее удивление, я даже тогда не изобиловал конструкциями GOTO, но некоторые вещи я все-таки в 12 лет не понимал. Например, кусок


CALL TExtractResource("EW95RES.DAT", "WarningIcon", "WARNING.OSP")
A = DrawWindow(100, 170, 350, 370, "Emulator Windows '95 Tasks", "")
CALL DrawPic("WARNING.OSP", 110, 200)
KILL "WARNING.OSP"
A = FPrint("An unknown error #" + STR$(ERR) + " was occured in", 150, 200, 0)
A = FPrint("active program. All unsaved data in this", 150, 215, 0)
A = FPrint("program will be lost. To do this, press the", 150, 230, 0)
A = FPrint("the End task button. No another way has", 150, 245, 0)
A = FPrint("been found.", 150, 260, 0)
CALL drawbutton(150, 340, 221, 360, "End task")


явно свидетельствует о том, что зря расходуется драгоценная память (64кб) для dummy-переменной A, в которой FPrint записывает всегда 0, а также выуживание картинки из этакого библиотечного файла и стирание её потом тоже не может не вызвать усмешки.

Следующую поделку почти такого же плана я сделал чутка позже, уже с аппаратным курсором, более аккуратными в прорисовке окнами в своем стиле (нехорошо всетки всё слизывать), но такую же бестолковую в плане файловых отношений и скорости. Да, она настраивалась, да, она умела запускать внешние EXE через SHELL, да, она К сожалению, скриншот я сделать не смог ибо за сколько-то лет потерял исходник я только помню, что уже научился использовать GET/PUT и использовал более миниатюрный основной шрифт Monaco.

RushА потом...потом году уже этак в 2002 я познакомился с Rush. Rush Soft (Joran Kok). Тогда еще алиас welcome.to/Rush работал и как система, так и сырцы были доступны. Для меня подобный подход к GUI в DOS был открытием - многое из принципов показались крайне привлекательными, к тому же в пакете сырцов прилагался Rush SDK, при помощи которого можно было более просто и понятно писать внешние программы под Rush. "Система" была однозадачной, но при том, что в VGA-режиме при запуске внешней исполняемой EXE (конечно, если в нем тоже прописана инициация SCREEN 12) экран от предыдущей программы не стирался, что и стало основой "псевдомногооконности", когда на передний план выводится какбе активное окошко. Таким образом, разработчики стандартизировали интерфейс в "библиотеке", которая использовалась при написании софта под Rush, и каждая программа представляла собой отдельный EXE, запускаемый из своеобразного Shell, использующего концепцию Program Manager'а из Windows 3.x
Именно поэтому сортамент программ, включенных в поставку Rush был очень велик - от звука до графики, форматирования дискет и прочих полезностей. Она была, как они грят, very nice (cute), окошки рисовались в стиле System 6 (Mac), хорошо настраиваема, имела выборщик файлов (окошко Open/Save as) тоже внешний, взаимодействие с которым происходило через внешние файлы (что впоследствие я позаимствовал).
Что насчет кода, так он хоть и был написан с немецкими каментами, тем не менее очень понятным и читаемым (тем более он практически не падал), с помощью него я наконец научился вовремя перед прорисовками скрывать курсор чтобы не возникало артефактов=), сохранять копию экрана на диск при уходе в SCREEN 0, их бинарный графический формат значков 32x32 (в которые легко преобразовывалось большинство иконок Windows 95)много полезных приемов я почерпнул из Rush, но тем не менее с прерываниями я все еще боялся общаться, опасаясь неуниверсальности (эта участь постигла меня позже через VESA в INT21h, также как и файловая рутина Rush через INT10h не работала в XP) и порчи кода неумелыми экспериментами. Но Rush вдохновил меня на написание GUI уже на их принципах и структуре.

Назвал я её незамысловато - BluOS. Ну конечно без ассоциаций с гомосексуалистами, прост преобладал в оформлении синий цвет.
Она до сих пор мне навевает ностальгию по задротству тех времен)
 (643x484, 54Kb) (640x480, 54Kb) (640x480, 4Kb) (640x480, 5Kb) (640x480, 5Kb) (640x480, 7Kb) (640x480, 10Kb) (640x480, 6Kb)
Буквы OS (не путать с alx rose) в названии были очередным отсылом к сайту Тодда, где каждый второй ребенок-кодер изображал из GUI операционную систему. Ребячество, конечно)
Тем не менее, в 2002 году я даже выпустил add-on в виде версии 1.5, которая устраняла некоторые недостатки и без того хрупкой (и УЖАСНО глючной системы), которая писалась в попыхах. Любая неточность могла привести к halt и повисанию программы вплоть до необходимости перезагрузки, ведь я не приписал туда нормальный error handler.
В целом, BluOS напоминала Rush, с измененным интерфейсом (полностью переписанным), но также состоящая из нескольких EXE-файлов, с главным конфиг-файлом (именно конФиг, фиг чего в нем поймешь спустя годы не глядя в source code) в корне диска, запускающаяся только в screen 12 (со старыми шрифтовыми рутинами), и такой же кучей разнообразного софта к BluOS. Между прочим, игры я портировал даже просто из qbasic-овых исходников, например Frogger by Matt Bross 97 года написания, и Game 2000 непосредственно из Rush. Я даже попытался реализовать несколько изначально тупиковых идей - подобие гипертекстового браузера (конечно офлайн) с собственным форматом (это ужасная штука, поверьте) - на скриншоте, и побуквенный синтезатор речи. Удивительно, но в VirtualPC на чистом DOS (и даже в XP!!!) звук работал отменно - я добавил поддержку SB16 к системным событиям, благодаря чему научил QB45 читать и понимать WAV PCM файлы малого размера. Увы, эта рутина не захотела по-нормальному понимать даже PC Speaker в PDS 7.1, может чего и придумал бы с буфером и "дочитыванием" конца файлов). Формат значков Rush - .RTI был успешно слизан вместе со значками как более быстрый и удобный (он был бинарный) чем мой формат картинок. Файл-браузер и selector, представленный общим исполняемым COMMON.EXE (с параметрами), наотрез отказался видеть папки как папки в чистом DOS через прерывание, а не через анализ файла после SHELL "DIR /B>temp", поэтому выглядит по нынешним меркам достижений GUI в QB крайне убого и нефункционально. Что касается контрольных элементов, окон и прочего экранного stuff'а, он был крайне прост, но реализован почти полностью - кроме перемещения окон (not draggable), изменения размеров (not resizable), так сказать static (как и Rush). С тех пор моя работа с бинарными файлами стала более уверенной, курсоры мыши хоть и вызывались через прерывание, но я мог их программировать по своему усмотрению. Компиляция программ для BluOS была тоже процессом веселым - надо было компилировать EXE требующий BRUN45.EXE, который какбе уменьшал размер программы, но в то же время привязывал её к выполнению строго из BluOS, сам же EXE переправлялся в Hex-редакторе на то чтобы требовать переименованный BRUN45 (мелкомягкие конечно не погладят по голове за такое), и переименовывался в *.BLU (который BluOS опознавал как исполняемый). Процедура задротная, но полезная для разыгрывания спектакля о "серьезной" системе =)
На деле же, сейчас просматривая самописную документацию к этой поделке, делаю вывод о том, что это была моя единственный законченный проект, который я вот так просто взял-и-запустил в эмуляторе - ни тебе настройки, ни разных "File not found - at line 0" при запуске...

Но законченный проект - как пройденный этап, стало скучновато. Задумался наконец о том, что надо както хотя бы показывать многозадачность, и стандартизировать всю ту массу вещей, написанных до этого - то, что через внешние EXE вызывать программы - удел не то что DOS'a, но даже нехватки памяти, стало понятно после открытия этак пятой программы в BluOS. Я начинал несколько вещей одновременно - от "максимально-настраиваемой-универсальной-GUI-с-моноядром-на-дискете" до "минимально-производительной-системы-с-моноядром-которое-вызывалось-каждый-раз-как-надо-было-делать-что-то-с-экраном":
1) первая меганастраиваемая система была всеголишь GUI в одном EXE с простеньким увы однозадачным scripting language (языком скриптов), который должен был заменить язык написания программ, чтобы сделать их универсальнее и работать даже с 5"25 FDD на CGA-дисплее с теми же 64кб памяти. Идея провалилась изза того что СЕРЬЕЗНЫЙ script-интерпретатор - дело еще слишком сложное для 14-летнего совсем-не-мега-кодера да еще и на QBasic, но могла удасться будь я умнее тогда да и шире кругозор был бы. История не любит сослагательного наклонения =) По правде говоря, нынешние многие поделки, присланные Тодду, на этом и построены, но в таком же тупике как и я.
2) второе направление - взаимодействие с одним EXE через внешние файлы, с самого начала сакс, ибо глюки на каждом шагу, хотя универсальность в пределах ПРОСТЕЙШИХ программ можно было бы сделать. Но это пошло и глупо, посему закрыто и больше не поднимается =)

И я решил больше времени уделить эстетике того, что делаю, грамотным error handler'ам и удалению всевозможных багов.
Закос под NT4 и Mac =)Сплошные глюки...Да, да, размер ровно такой же как и в макеи окошко почти такое же

За основу была взята частичка Rush, отвечающая за окошки (остальное пришлось писать САМОМУ ибо Rush был построен оператором DRAW(!) и не поддавался анализу на листочке карандашиком, и даже шрифты(!)), handler верхнего меню, шрифтовая рутина самая первая была переписана до неузнаваемости добавлением ВСЕЙ кодовой таблицы, все контролы тоже. Все это я делать начал в том же 2002, и периодами открывая, доделывал. На верхних скринах то, что было вначале (и тупик, полный).
 (640x480, 5Kb) (640x480, 10Kb) (640x480, 9Kb) (640x480, 8Kb) (640x480, 9Kb) (640x480, 8Kb)

Летом 2008 года, уже понимая, что с многозадачностью путем запуска EXE и сохранения области памяти в файл с последующим восстановлением содержимого не прокатит (эта идея запала в душу из MS-DOS Shell, где была программка dosswap, но которую не удалось разобрать и принцип действия остался неясен), поэтому я углубился в улучшение. Стоит заметить, что раньше времени я даже не буду называть этот GUI каким-то определенным именем, пусть будет просто "sox mac" =)
Теперь, даже в screen 12, все работало почти без лагов, а если они и случались (как на первом скриншоте) - это результат неправильного указания путей в .INI (мои процедуры iniWrite, IniRead$, IniDelete - теперь и в QB =)))). Теперь я работал полностью в PDS 7.1, что снимало некоторые ограничения - главное - Far Strings, массивы теперь какие угодно!). Как-то раз я делал себе программку для расчета некоторых задач курса Сопротивления материалов, и эта GUI очень помогла мне реализовать то, что не было доступно моим рукам в оконном программировании.
Я даже написал своеобразный SDK (исключительно рабочий), для того чтобы упростить написание расположения окошек и "controls". Здесь целью было уже устранить почти все возможные недостатки прорисовок и общения с дисками. Мне удалось:
1) грамотно разбирать файлы получаемые SHELL 'DIR' и сделать ОЧЕНЬ ДАЖЕ работающий file selector, частично через прерывание дисков
2) научить поделку общаться с 16-цветными .ICO (с маской) и .BMP, что позволило отказаться от самого-первого-медленного-формата-картинок и даже формата .RTI (куда проще в винде рисовать же?), загружать монохромные курсоры 16x16 формата .CUR, "говорить" с .INI на одном языке, ну и много частных нюансов в отношении совместимости.
3) собственно курсоры больше касаются мыши, которая в некоторых местах умеет теперь drag-n-drop и double click (все как у людей)
4) не знаю зачем, но я добавил такие элементы управления, как TabsBar, DownListBox, Slider, они редко используются, но те вещи, которые присутствуют в любой "панели управления" CPL Windows-систем =)
5) окна! теперь! перетаскиваются!
с тех пор я сел наконец за самое главное - менеджер окон, что стало бы ХОРОШИМ подспорьем в написании GUI со скриптовой многозадачностью.
Рассказ получился сумбурным, с налетом задротства, ностальгии по детству и наивности, полным ошибок и неточностей, но... пора переходить к делу, собственно к чему я в текущем моменте добился-дописался.


Bugful SVGA VESA GUI with some kind of window manager writed in QuickBasic PDS 7.1 but not compilable because of time and motivation deficite =)
Это первый самый сырой скриншот!

Заголовок я написал на english чтобы их поисковики хотя бы обратили внимание на этот пост. Сразу скажу - моя наработка по какой-то еще неизвестной мне причине работает только у меня на двух компах. Я подозреваю вину карточек ATI, с которыми почему-то захотел работать только ЭТОТ метод общения с VESA. Быть может, светлые головы загорятся и попробуют помочь мне исправить этот досаднейший недостаток, не позволяющий показать общественности ни-че-го (ну код могу) кроме скриншотов. А второй недостаток заключается в том, что насколько бы глубоко я ни копал, мне рано или поздно (при других рутинах QB VESA) придется делить код на библиотеку и собственно код, что трудоёмко и задротско, а посему мне лень этим заниматься, время столь драгоценно.
LiveInternet портит большие картинки, за полными если не верите - обращайтесь
Я готов выразить благодарность Сергею AZote, программисту из Пензы, понявшему мою задротскую страть и предложившему помощь своей библиотекой общения с дисками (но тоже требует времени), но я всячески сопротивляюсь тому, чтобы смириться с фактом необходимости включать в конечный GUI известной в своих кругах non-sourced мегабиблиотеки для QuickBasic FutureLibrary 3.5 (увы, я нашел только версию QB45, что уже связывает меня по рукам, код существующей GUI уже перевалил за рубеж нормального размера).
Итак, возможности поделки по функциональности схожи с версией для screen 12, но для VESA пришлось модифицировать (с добавлением изрядной доли глюков) рутины мышиных курсоров, которые стали совсем неидеальны изза невозоможности использовать hardware cursor. Также были заменены все PSET и LINE-подобные операторы на соответствующие VESA подпрограммы обращения к INT33h. Из-за того, что я никак не могу понять принцип хранения в видеопамяти 16-битных данных для точки (читать и разбивать на цвета не умею, писать - да), приходится ограничивать режимы работы дисплея 32-битными, то есть 4хбайтными.
Меняем шрифты в INI файле, и разрешение через своеобразную панельку =)Благодаря ХОРОШЕЙ БЛИН системе ntvdm я не могу по человечески из винды общаться с XMS, и по той же причине все области видеопамяти мне приходится сохранять во временные файлы, что ооочень тормозит работу. Словом, с VESA и XP всё сыро чуть больше, чем полностью. Разрешение экрана варьируется от 640x480 до 1280x1024, которым соответствуют HEX-режимы SVGA. Мышиные курсоры теперь тоже прописываются в system.ini (tribute to Windows 3.x), и все полностью грузятся из .CUR-файлов, но оставляют много артефакты изза перерисовки и недоработанных новых методов MouseHideCursor и MouseShowCursor. Разумеется, VESA кроме неудобств, доставляет порой и удовольствие - полноцветные битмапы (bitmaps) и .ICO (пришлось переписать рутины), вполне работающий GIF-плеер в одной подпрограмме ImageDrawGIF для анимашек (но блин, последовательный, надо сделать бы так чтобы он в процессе обновлял), и наконец - портированный просмотрщик JPEG от Antoni Gual.
Все эти скриншоты были сделаны встроенной рутиной ImageSaveBitmap, не вышло же эмулятор пустить. Честно говоря, как раз таки возможность работы с JPEG сподвигла меня на всю эту заварушку с VESA GUI, и собственно рутина VESA была переработана тоже от просмотрщика Антонио. Это было нелегко - разобраться в исходнике декодирования при помощи таблиц Хафмана, но все же алгоритм средней скорости (не первой версии) был переработан так, что средний JPEG выводился в дисплей менее чем за 3 секунды (!!!это очень хороший результат для QuickBasic!!!). Я полностью отказался от формата .RTI и всех остальных несильно универсальных форматов в пользу наибольшей совместимости - единственным камнем преткновения стали шрифты - тут царит все та еще переделанная процедура из MenuWork;), хотя конечно, хотелось бы включить поддержку растровых шрифтов .FON, но мелкомягкие держат описание формата в ублюдском TXT-файле про Windows 2.0 1980-х годов придумывания. В идеале стоило включить векторные TTF хотя бы не-OpenType шрифты, но изза явных проблем со свободным использованием (а рутины-то где-то в сети есть...) по правам на собственность и, скорее всего, падением производительности в разы, пришлось на время от них отказаться. А жаль. Взамен всего этого я решил ввести понятие "inline text formatting", которое было реализовано в одном из GUI в коллекции Todd'а. Суть в том, что рутиной FontFMTPrint вызывается анализ обычной строки, в которой посылаются теги вида "{U}{B}{N}{I}{r000}{b000}{g000}{u}", которые преобразуются в управление начертанием символов и цветом текста.Inline text formatting, подобие HTML или строчек rtf =)
Также еще одним параметром теперь указывается максимальная пиксельная длина строчки до переноса (Y-длина еще не реализована, она будет уже со скроллингом), то есть не случится теперь печальной ситуации, когда окно окажется размером меньше, чем строка, которая испортит изображение на фоне. В одном из скриншотов я показал, что можно изменять размеры окна, при этом меняется длина X-лимита строчки (зато испортит изображение снизу, если пережать).
Была существенно переработана процедура текстовых полей (TextBoxDraw, TextBoxHandle), ныне курсор ввода появляется в том месте, где пользователь нажал мышкой на символ, и при вводе с клавиатуры мышь может свободно гулять по экрану, делать нажатия, обрывая ввод. В обработчик также добавлен лимит символьной длины вводимого текста (0 - неограничен), а при выходе за рамки поля текст прокручивается, и возможно использование стрелочных клавиш и PgUp/PgDn/Home/End. Да, стоит еще отметить своеобразный ClipBoard - переменную, отвечающую за нажатие в TextBox'е клавиш типа Ctrl+X/V/C, и копирование текста. Этого очень часто не хватает в knee-maiden-GUIs =).
Изменение размера окна и тексовых ограничений Теперь хочется сказать про оконную подсистему (GUI window manager). Код оконной системы достаточно прост, почти избавлен от переходов GOSUB, а если рисовать в модальном однооконном режиме (то есть не надо думать об остальных), проблемы описывать элементы управления и события нет - все умещается в одной подпрограмме без конфликтов, двумя (а часто одним) оператором - вызовом единожды рутины рисования элемента (TextBoxDraw, ListBoxDraw, ButtonDraw...), и функции обработки нажатия (handler) на этот элемент в цикле (TextBoxHandle, ListBoxHandle, WindowClosePressed...). В эту VESA-версию я также добавил элемент управления окном "скрутка" (roll), которая в Mac-системах служит заменой Minimize в виндах. При скрученном состоянии элементы управления и содержимое окна не должно рисоваться, а при перемещении перемещается только заголовок. Все эти возможности реализованы в небольшой демонстрации возможности многооконной работы. Это своеобразный Window manager, окошко, которое нельзя закрыть (я не хочу! я так сделал!), в котором есть список всех открытых окон, и некоторые функции управления ими - переключение, закрытие и создание пустого окна.
Калькулятор вместе с другими окнами никак не конфликтуетЗдесь у окна есть несколько параметров - положение (2), размер (2), минимальный размер (2) - для возможности изменения размера и предотвращения печальной ситуации, имя окна и заголовок окна (строчка). Window manager состоит из четырех подпрограмм, отвечающих за работу обработчика закрытия и скручивания (а вдруг в окне чето было не сохранено допустим?), обработчика MouseOver (если нужно показать подсказку одного из элементов окна), отловщика нажатий (самое главное - что нажато, что дальше делать) и собственно рисователя окон. Конечно же, можно трогать другие "события" - перемещение, изменение размеров, но обычно достаточно этих четырех. В этих 4х подпрограммах происходит выбор CASE от имени окна, какое из них в данный момент активно, и чего ждать от пользователя. То есть, чтобы придумать новое окно со своими элементами, нам нужно прописать в эти 4 подпрограммы случаи с окном определенного имени. А далее - все зависит от фантазии программиста. Единственное, что не есть хорошо, что все переменные нового окна (там если TextBox есть, то у него есть строчка со значением) должны быть SHARED или COMMON. Для наглядной демонстрации я добавил приложение калькулятора а-ля windows в отдельное окно. Пользоваться им можно, но осторожно - может возникнуть внештатка вроде 'деления на ноль', и поэтому предварительно все операции выводятся в MessageBox (как на скриншоте с иконочкой Vista =). А для демонстрации того, что окна могут иметь функциональную независимость, выведена панель настройки VESA режима, и они могут сосуществовать с другими окнами, перекрывать друг друга и не терять работоспособности.ага ага, поменял шрифт и фон - уже называйся виндойЧто касается скорости, она оставляет желать лучшего изза сохранения и восстановления области экрана "под окном" из отдельных временных файлов процедурами SVGAGet2file и SVGAPutFromFile. Механизм такой - при перетаскивании или каких-либо операциях с параметрами окон дисплей сначала восстанавливается в состоянии чистого (с обоями или без), меняются параметры окон, а затем все окна снова перерисовываются с новыми параметрами. Это медленно, особенно если присутствует окошно вырисовки JPEG с моей самодовольной фотокарточкой . То же самое происходит при закрытии одного из окон, создании нового и т.п.
Словом, для того чтобы всё это заработало так, чтобы можно было смотреть на это как на законченную поделку и показывать с поднятым вверх носом, сюда еще предстоит вложить немало ночей (чем я пока заниматься не собираюсь), приписывая стабильный МНОГОФУНКЦИОНАЛЬНЫЙ интерпретатор скриптов, нормальные VESA-рутины, XMS, общение с дисками (файл-селектор вообще пришлось убрать из кода, заново писать надо полностью вместе с AZote), и наконец расформировать код на библиотеку и собственно программу. Без этого она не будет работать ни в DOS, ни в XP.


В заключение хочу сказать, что в идеале хотелось бы, чтобы вся эта поделка стала похожа хотя бы на GCOE, с некоторыми чертами GIMI (увы, он выглядит настолько же современным, насколько первая моя поделка - EW95 стабильной). Я не представляю себе даже подобие какого-нибудь ресурсоемкого фотошопа (хотя, лучше для примера взять AutoCAD...), написанного на будущем скриптовом языке под этот GUI, но хотелось бы это видеть

P.S. window manager в данной стадии неидеален в принципе - стоит переработать Z-order, порядок перекрытия окошек друг другом, задача которую я пока не смог придумать как реализовать, работает, но хромает.
Я искренне надеюсь, что ко мне не возникнет претензий по поводу портации частей кода JPEG декодера, наглой эксплуатации дизайна интерфейса Apple 1984 года (я всегда буду подмигивать и говорить что вдохновлен GUI Rush), и неоправданных обвинений в адрес всемилюбимой корпорации. Этот "проект" является некоммерческим, посему если возникают предложения или вопросы, я готов к сотрудничеству. Спасибо всем заинтересованным, кто осилит этот пост, для связи - либо здесь в каментах к посту (хотя от аудитории сервера ждать не стоит мне этого...), либо по другим каналам связи icq/mail.

Best regards,
SoXiE, 15 feb 2009


Рубрики:  этот удивительный мир вокруг нас
Метки:  



 

Добавить комментарий:
Текст комментария: смайлики

Проверка орфографии: (найти ошибки)

Прикрепить картинку:

 Переводить URL в ссылку
 Подписаться на комментарии
 Подписать картинку