Коммандер.

[Spectre]

Обычно количество строк заранее неизвестно; его можно узнать, произведя предварительное форматирование текста. "К счастью", длина файла в TR-DOS ограничена 255-ю секторами, но в 48K длинный файл "перелопачивать" придется долго.
В TR-DOS Navigator'е ничего этого не делается. Текст разбивается на строки в процессе вывода, какими бы длинными они не были (хоть весь текст одна строка!). Считаются именно байты, и результат не плохой.

Я собственно нигде и не спорю, что считать по байтам можно, тем более что это самый простой способ. Я просто утверждал, что единственный способ добиться плавности изменения счетчика - это считать именно строки, потому что скроллинг осуществляется именно по строкам (а не по байтам). Разбивка строк, разные разделители строк, скорость подсчета и прочее - все это решаемо. Например, посмотрите QC 3.11...

Вот какая "процентная" формула там используется:
процентная_величина_прокру ченного_текста=адрес_в_тексте_на_котором_о� �тановился_вывод/(длина_текста_в_байтах/100)

На ассемблере это выглядит так:

LD    BC,адрес_в_тексте_на_котором_остановился_вывод
CALL    11563;значение из BC на стек калькулятора (СК)
LD    BC,длина_текста_в_байтах
CALL    11563;значение из BC на СК
RST    40
DB    #A4;значение 10 на СК
DB    #A4;значение 10 на СК
DB    4;умножение
DB    5;деление
DB    5;деление
DB    56;конец
CALL    11733;значение с СК в A с округлением его
        ;до ближайшего целого

Счетчик показывает величину прокрученного текста, и принудительное значение "100%" никогда не выставляется.

Я обычно использую собственную процедуру деления для этого расчета:

    LD DE,55    ; текущая строка
PERCDIV LD BC,0        ; делитель (заранее высчитанный исходя из числа строк)
        CALL DIVIS

[...]

DIVIS   LD A,B
        OR C
        RET Z
        LD A,#10
        LD HL,0
DIVIS2  RL E,D,L,H
        SBC HL,BC
        JR NC,$+3
        ADD HL,BC
        CCF 
        DEC A
        JR NZ,DIVIS2
        RL E,D
        RET

Можно было бы пофиксить эти ошибки самому, и опубликовать только эту информацию.

Если кому нужно та дока - напишите мне и я ее вышлю. Просто в таком (необработанном) виде не хочется выкладывать на всеобщее обозрение.

Если модули организованы как в Real Commander'е, то идея действительно плохая. А вот если сделать динамическую подгрузку оверлеев в зависимости от выполняемой функции, то идея хорошая. Недостаток - нужно держать в дисководе "системный" диск, но и он обходится, если оверлейный файл будет на RAM-диске (в 128K).

Проблема модулей (оверлеев, плагинов) на спектруме (не только касательно коммандеров) в том, что их пишет только автор программы и все. В том-же RC была изумительно документированная система работы с модулями, куча примеров, поддержка автора и тем не менее количество написанных модулей (сторонними авторами) совсем не впечатляет (несколько штук). За время, пока Pawel писал все эти доки, он возможно сам бы написал эти несколько модулей.