Это мягко говоря, преувеличение. С документацией плохо. Если просто из любопытства почитать тему, то да, есть что почитать и посмотреть - "много букаф", интересные фото и скриншоты.Сообщение от fifan
Но нет документации для программиста в нормальном виде. Да и для пользователя документации нет, это значит, что надо читать всю эту тему, запоминать информацию. Даже HELP-ов нет, хотя это совсем не проблема - вывод текстового файла на экран, если нажали <F1> и нужный HLP-файл есть на диске.
Здесь все на PC, потому тексты должны быть сразу доступны на PC, а не в каком-то левом формате, чтобы прочесть который надо истратить море времени и усилий. Зачем применять нестандартную собственную кодировку, для конверсии из которой нет программ. У меня есть программка ORD.EXE 20-ти летней давности для чтения и конверсии текстов ОРИОНА во всех кодировках в формате ORD, но и она не расчитана на такие тексты.
Почему в DSDOS использована не КОИ-8 или КОИ-7 и даже не АЛЬТ-кодировка, а кодировка полученная из КОИ-8, в которой для символов выше C0 отксорен бит D5. Пришлось написать программку на QUICK-бейсике, чтобы конвертировать в нормальный вид, но и это не помогло, т.к в одном файле нормальные разделители 0D,0A, а в других только 0D. Логично было ожидать единообразие.
Обычно экранные процедуры делают искейп-кодами, т.к тогда сохраняется к ним доступ из ЯВУ. Так делали даже в промышленных графических терминалах, например, цветной графический ИЗОТ-1031C. В данной системе нет разделения на DOS-BIOS и DOS-BDOS, один общий BDOS, потому и функции, что должны быть в ROM-BIOS или в загружаемом драйвере включены в BDOS. Экранный драйвер с оконными функциями полезно выделить в отдельный файл (обозвав XBIOS), чтобы его можно было использовать без DSDOS.
А ещё лучше сделать установку теневого ПЗУ (Shadowy ROM) в адресах 0...7FFF и прошить туда этот цветной оконный драйвер, дополнив его процедурами для поддержки мыши и GUI. Причём можно сделать грамотно, чтобы это никого не напрягало и проблем бы не создало. Стандартизуются только интерфейс и функции (а будет это физически реализовано за счёт апп.доработки в теневом ПЗУ или у того, у кого его нет будет отнимать кучу места в ОЗУ ОРИОНА и дико тормозить, - это не важно).
Зачем понадобился формат ORI? Это нестандартный формат, его даже эмуляторы не поддерживают. Не было смысла плодить сущности. Что он даёт относительно формата ORD, кроме никому ненужной сигнатуры? Но ведь и без сигнатуры в 16 байтов, каждому ясно, что если расширение ORD, то это формат ORDOS. У меня все файлы для 4-х разных 8-ми разрядок имеют расширение ORD, потому что это удобнее, чем МГ-производные форматы RKO, RKP, RKR, RKA, RKS, GAM...
Формату ORD не хватало контрольных сумм. Для PC это не актуально, а вот для реального ОРИОНА с эл.диском из излишнего ОЗУ, где у памяти нет 9-го бита паритета для контроля дохлоты, КС намного полезнее, чем дата файлов. Кстати, в других DOS такой проблемы нет, т.к есть КС секторов.
Но как раз 4 байта метки файла в базовом стандарте ORD свободны (занят лишь 1 бит в первом байте, как флаг R/O). Потому 15 битов я сначала резервировал под дату файла, а 2 последних байта использовал, как КС. Но т.к апп.часов у меня в ОРИОНЕ не было, то бит с оффсетом 12 я обычно использовал в качестве токена для расширения файла, что позволяло 128 расширений (COM,BAT,TXT,ASM,TX,AS...) и не мешала ORDOS флагу R/O. А два последних байта ORDOS-метки использовал для КС. В моих оболочках LORD специально есть команда нормализации ORD-файлов (директива <N>), которая подставляет контр.сумму ORD-файла.
В эмуляторе на PC контр.сумма ORD-файла не важна, в то же время дата доступна. Потому разумно этими 4-мя байтами распорядиться так. 1 байт - байт паритета блока (сумма байтов по XOR), в значительной степени это замена КС, 2 байта - дата файла и 7 битов на расширение файла. Давайте подумаем все вместе и введём общепризнанный разумный стандарт на эти 4 байта, - ранее я встречал кучу вариантов их использования и сам использовал по разному.
Логика панелей в нортоне DC$ имеет неудобство, т.е не как общепринято. При нажатии вправо в левой панели указатель не должен сразу перескакивать на соседнюю панель. По первому нажатию клавиши <вправо> указатель должен перескакивать на самую нижнюю строку текущей страницы, а если уже на последней строке страницы (списка файлов), то на последнюю строку последней страницы. И только если указатель стоит на самом нижнем файле в списке, то по нажатию вправо происходит переход в правую панель. Для перехода между панелями служит TAB. А клавиши <влево> и <вправо> в панели служат для перехода к первой и последней строке отображаемой страницы.
Раз DSDOS теперь может работать с нормальным КНГМД, то отчего в дистрибутивах эмуляторов нет поддержки дисковода в DSDOS-конфигах. Обычный нормальный КНГМД многие эмуляторы поддерживают, в отличие от КНГМД для SP-DOS. Почему не попросить авторов эмуляторов доработать конфиг-файл, предназначенный для DSDOS? Это же дописать всего несколько строк. А в саму DOS полезно встроить внешний файл-драйвер, при замене которого DSDOS начинает работать с другим типом носителя (флоп, винт, флэш).
Ответить с цитированием