Эх
пересилил я себя, в который раз причём
Я витамина сразу понял а вот основная масса участников видимо не прониклась духом идеи - как говорят софисты "прежде чем отергать идею, надо проникнуть её духом"
Витамин спросил - какова вообще идея?
Я считаю что идея отличная, и ставлю за идею 5 баллов.
Далее, что плохого есть в идее.
Как уже отмечено инерция мышления и как итог - инерция в методиких создания программных продуктах на спекке. Но речь не об этом.
Мне кажется основная масса непоняток выходит из того, что витамин недостаточно внятно объяснил что это даст. А я попытаюсь это сделать.
Вот такая общая мысль.
Каждый из нас сталкивался при написании своих программ с тем, что надо рисовать 1 единственный символ в заданном знакоместе из заданного шрифта (расположенного в памяти). Стандартное RST 8 кажется по-моему только на заре программирования использовали - каждый сейчас пользует для этого свой код. Даже в случае, если надо рисовать символ 8x8 точек (что справедливо далеко не всегда). Вот первый претендент - процедура прорисовки символов. (здесь не торопитесь писать "опровержение", потерпите и дочитатайте тред до конца). Вызов - в программе - на внешнюю точку Call Scr.PrintChar8x8 (первая часть имени функции обозначает его модуль - модуль Scr)
Каждый из нас сталкивался с тем, что отсутствует эффективная процедура работы с диском (опять же стандартная #3D13 слишком медленнная, и даже имеющиеся в ней возможности порой значительно ограничены). Тут уж я исключаю такого рода проблемы как поддержка (полная) жёсткого диска, работа с расширенной файловой системой TRDOS Directory System и т.д. Поэтому второй претендет - бинарник для работы с носителями, в том числе с файлами. Вызов Disc.FileRead, Disc.SectorRead, Disc.SectorWrite. Кстати не факт, что даже те процедуры что сейчас есть для скачивания работают хорошо - я вот специально для себя писал очень хитрый дискожуйный процедур, который работает не посекторно а потреково, что уменьшает время решения разрешаемых ошибок чтения и уменьшает "головобуйство" дисководов, экономя их ресурс в том числе, но опять же не про это речь. Модуль - Disc.
Модуль опроса клавиатуры.
Не секрет, что клавиатурный менеджер висящий на прерываниях спекка опять же оставляет желать лучшего - нет буферизации нажатых символов, нет возможности (через него) определить нажатие функциональных клавиш - таких как SymShift, CapsShift; русскоязычная поддержка это вообще из области фантастики. KB.ReadKey - читает клавишу нажатую пользователем. KB.Clear - очищает буфер. Модуль соответственно - KB.
Модуль рисования всеразличных рамок - Window. Window.Show - прорисовывает окошко. Тут даже может быть целая система, учитывающая взаимозакрывания окошек (т.е. когда окошко одно частично закрыто другим, а потом это заднее окошко всплывает).
Модуль арифметических операций Arithm - работает с быстрой целочисленной арифметикой (скорость калькулятора ПЗУ SOS оставляет желать лучшего, хотя функционал там конечно богатый). Arithm.16mul16 - перемножает два 16битных числа. Arithm.16div16 - делает одно 16разрядное на другое.
Модуль работы с памятью - RAM. RAM.ChangePh - смена страницы памяти на заданную физическую. RAM.ChangeLog - смена страницы памяти на заданную логическую.
И вот, я хочу написать бут, хочу написать текстовый редактор, хочу написать вьюер, хочу написать игрушку. Что из этих процедур я буду использовать? Правильно - все из них. И тем не менее, в существующей среде каждая из программ использует свой воз и тележку - где хранится это всё добро, и мало того - по причине закрытости исходов, нежелания автора заниматься программой и т.д. и т.п. в программах есть глюки, которые (90%) являются следствием криво написанных перечисленных процедур. Т.е. битком забитый диск программами спекковский диск де факто повторяет себя почти на 90%. Кроме того, часто указанные процедуры цепляются к тексту в виде некоего дополнения к каждой из запускаемых программ - в итоге и без того ограниченное количество допустимых файл-ячеек в ТРДОС используется малоэффективно.
И теперь смотрим как это может быть - на диске лежит 1 pak файл, лежит 1 boot.B и кусочек кода к нему и лежат куча стартеров - файлов скажем с расширением R (взято произвольно, кстати они тоже могут быть в виде одного файла, и вообще здесь файловая структура не так критична). Эти стартеры могут быть и бейсик программами и просто кодом - это не так важно. Важно, что boot.b загрузит при старте линковщик (или компилятор если угодно), который будет уже работать с лежащими в pak файле указанными модулями.
Хочется подчеркнуть такой немаловажный с моей точки зрения момент - модули фактически являются законченным машинным под Z80 кодом с той лишь разницей, что он сопровождается заголовком релокации для того, чтобы можно было склеить эти модули с головной программой. Впрочем, лучше почитать документацию к модулям и станет понятно что обвинения в писюканстве и амижстве здесь бессмысленные.
И вот, запускаю я свой излюбленный вьюер - и что же? фактически, загрузится МОЯ логика реализованная в коде Z80 - мой код (назову это индивидуальный код) - т.е. только то, что в общем то и надо было написать для того чтобы куча библиотек превратилась в вьюер [основная масса существующего программного зоопарка несовершенна по причинами того, что кодер реализовав свою логику, которая на самом деле является изюминкой программы должен ещё и написать процедуры для отработки указанных действий - работы с дисками, клавиатурой, арифсетика, память и т.д.] - код будет просто дёргать нужные функции и я не буду задумываться о реализации универсального драйвера памяти (кроме случая когда он будет для меня слишком медленный, но это около 1% случаев всего кодописания), я не буду задумываться куда мне обратиться за опросом клавиатуры, я не буду задумываться даже на каком устройстве я сейчас работаю - потому что драйвер уже это сделает, потому что он включен в программу - ну и т.д.
Теперь, нажал я резет. Надоел мне вьюер, я захотел текст понабирать - и всё то же самое - загрузился только МОЙ индивидуальный код и все остальные модули подхватились сами.
Кстати тут очень интересный вариант, что модули будут лежать даже не на самом диске, а скажем на ЖД, или например во втором дисководе будет лежать диск с модулями - т.е. даже отпадёт необходимость на конечный диск писать библиотеки.
Общая мысль витамина такая - за каждой из программ тянется огромный шлейф повторно написанных процедур (вот уж действительно пора покончить с изобретением велика), которые можно и нужно использовать в стандартном виде и таким образом подтягивать и увеличивать общую эффективность программо-производства.
Напоследок хочу сравнить два подхода - которые как мне кажется в некотором смысле конкурирующие - 1) когда имеются ИСХОДНИКИ всех используемых процедур и в процессе компиляции всё собирается в один конечный файл 2) когда имеется модульная структура и фактически компилируется только индивидуальный код.
1) возможность расширения 100% за счёт стороннего кода; возможность подмены исходных возможно глючных библиотек - только при перекомпиляции всего кода; количество необходимых файлов (в килобайтах и в штуках) - большое
2) возможность расширения - отсутствует, это готовый код - только при перекомпиляции; возможность подмены библиотек - 100% за счёт модульной организации; количество необходимых файлоы (в штуках и килобайтах) - невелико.
Ответить с цитированием
Размещение рекламы на форуме способствует его дальнейшему развитию 
Сообщение от GriV
. Во вторых, ну сколько можно, товарищ Витамин С? Ну стормозили вы разок, не поняли, что я вам сказал, дык зачем на себя так долго дуться? простите себя уж! =)
