ОС RT-11 и поддержка Y2K !!!

[form]

В общем, моё мнение - надо выбрать несколько систем и пропатчить их на уровне исходников, вписав изменения прямо в KMON.

KMON мало.
Нужно еще в RMON подправить вызовы .SDTTM и .SFDAT.
С RMON все просто, с KMON придется немного повозиться - там команды раскиданы по оверлеям, и навскидку попытка просто добавить нужный код в V5.0 к примеру приведет к выходу за рамки оверлея.
Но в целом решаемо.

[AFZ]

Я тут подумал и пришел к выводу, что все эти дела, в действительности, никому не нужны. А что действительно нужно - это пропатчить три сгенерированные системы - RT11DS, RT11CD и ADOSSJ. Увы от всех трех систем в наличии только собранные файлы системы: RT11DS.SYS, RT11CD.SYS, ADOSSJ.SYS, и всё! Никаких исходников, никаких мапов, никаких объектных модулей - ничего! Поэтому вопрос: что-нибудь можно сделать, или как? Да, программу DIR.SAV можно просто заменить чем-то посвежее, что-то еще из внешних программ можно будет пропатчить позже или тоже заменить на версии посвежее, но все три ядра системы надо патчить так, как они есть.


form, что скажешь? И вообще, опиши изменения, вносимые патчами, желательно с фрагментами исходников. Чтобы можно было найти нужные места по коду и перетереть их, допустим, DESS-ом.

[form]

опиши изменения, вносимые патчами, желательно с фрагментами исходников.

В системе пропатчить надо несколько мест: KMON (команда DATE), RMON (вызовы .SDTTM, .SFDAT и код перевода даты если он включен в систему).
Под рукой сейчас нету фрагментов, но их можно посмотреть в исходниках v5.7 и сравнить с v5.6 - они наиболее близки, при сравнении как раз будет видно разницу y2k в данных местах.
Посмотреть же исходный код того от чего нет исходников легко - подойдет скорее всего 5.00 или 5.02.
Я начинал писать драйвер который при загрузке в память патчил бы RMON и отслеживал загрузку KMON, но руки не дошли.
Если кому не лень, идея такая:

• фрагменты кода которые отвественны за нужное начиная с версии 4.0 и до самого 5.6 существуют всего в двух-трех вариантах (код .SFDAT не существует для v4 [v5.7 не считаем - его не нужно править]), это относится и к рафосам-фодосам.
• код RMON ищется прямо в памяти и оттуда переставляются ссылки в драйвер
• начальный блок KMON (нужно будет вычислить номер блока на диске - берется из области каналов после открытия файла) и точка входа DATE в файле монитора ищется анализом файла монитора (начальное смещение можно найти в загрузчике, на память не подскажу)
• сам драйвер сохраняет адрес подпрограммы QCOMP (смещение 270 кажется), прописывает туда свой адрес и в момент входа в него (сразу после завершения чтения) проверяет было ли чтение по системному каналу (SYSCH), проверяет был ли прочитан KMON (он всегда читается по начальному номеру блока в файле и читается целиком), и прямо в буфере куда KMON был прочитан (берется из смещения Q$BUFF пакета [на входе если склероз не врет R4 будет содержать адрес xxCQE системного драйвера, оттуда можно взять адрес I/O пакета]), после чего отдать управление системной QCOMP.
• проверять чтение нужно именно по использованию SYSCH, а не по индексу устройства чтобы не патчить результат команды COPY например (при этом не нужно проверять индекс устройства - всегда будет SY и тип операции - всегда будет чтение).

Есть еще такое понятие как RMON patch space - это пустое место в конце RMON, его размер где-то в загрузчике хранится - туда можно вписать код для вызова и вызывать его через смещение относительно @#54. Это способ пропатчить прямо сам файл, но беда в том, что размер patch space разный, и он может быть недостаточным чтобы впихнуть в него нужный код.

У меня пока не будет времени заниматься этим. Если найду заготовки к драйверу - выложу.

[AFZ]

Я начинал писать драйвер который при загрузке в память патчил бы RMON и отслеживал загрузку KMON

Напомиаю еще раз: драйвер хорош, когда есть много памяти. А у нас есть три системы SJ, которые даже не FB/SB, а примитивные мониторы, которые даже операцию ввода-вывода останавливают не отработкой всех последовательностей завершения, а банальной командой RESET. И процессоры, на которых им предстоит работать, обычно, БЕЗ диспетчера памяти, а попадаются и машинки с памятью меньшей, чем 28К - допустим, ЦП М2 с одной платой П3 (20К слов), а то и с 16К слов. Недавно консультировал одного коллегу, так он пытался запустить RT11 на Э-60 (ЦП М2) с 8К слов. Да, не то, чтобы осмысленно работать, а просто запустить - тем не менее...

То есть, очень желателен именно двоичный патч, который можно было бы внести даже DESS'ом. Ты же, помнится, при патче даже что-то там оптимизировал, чтобы влезть куда-то (в оверлейный сегмент, кажется). Так вот, здесь задача еще более жесткая - надо влезть в собранную систему, и чтобы она работала. Можно, вероятно, грохнуть какую-либо команду, только вот ненужную команду у RT11 я знаю одну - BACKUP/RESTORE, и ее в моей любимой RT11DS (SJ) уже грохнули.

Есть еще такое понятие как RMON patch space - это пустое место в конце RMON, его размер где-то в загрузчике хранится - туда можно вписать код для вызова и вызывать его через смещение относительно @#54. Это способ пропатчить прямо сам файл, но беда в том, что размер patch space разный, и он может быть недостаточным чтобы впихнуть в него нужный код.

А вот это может быть решением - в тех собранных системах это пространство, если его, конечно, не заняли, уже никому не потребуется - единственная доработка, которая требуется этим системам - RT11DS (SJ), RT11CD и ADOSSJ - это Y2k, так, что всё, что там оставили - наше.

[form]

Напомиаю еще раз: драйвер хорош, когда есть много памяти.

Драйвер поддержки Y2K должен уложиться в несколько слов.
Резидентная часть минимальная, нерезидентная глубоко пофигу лежит она внутри файла монитора или за его пределами.

двоичный патч

Патч поверх системы можно внести если там есть для этого место.
Довольно небольшое, но часто и его нет.

Можно, вероятно, грохнуть какую-либо команду, только вот ненужную команду

Это настолько нифига не даст, что даже рассматривать не стоит. Разве что нужно освободить 3-4 слова, но столько обычно и так найдется.

[BlaireCas]

А в чем проблема с Y2K? Я какую-то систему заюзал от патрона наверное и она нормально к датам относится. (собственно скрин вон в теме про подключение старого компа к новому монитору). Какие-то вещи факапнулись, но в основном вон все даты точно написаны.
https://zx-pk.ru/threads/34641-rgbdi...92#post1162592

[form]

А в чем проблема с Y2K?

С Y2K проблем нет, начиная от того, что последняя версия в принципе изначально поддерживает даты до 2099 года без всяких переделок вместе со всеми утилитами, кончая тем, что известно что переделать в любой веросии системы.
Но насколько я понял хочется "именно вот это" уже собранное, исходников нет, карты памяти нет, как на планете щелезяка.

- - - Добавлено - - -

А вот это может быть решением

Самый простой способ (если нет карты памяти) - найти RMON stack.
Секция PATCH$ идет сразу после него и до границы блока.
Стек ищется легко: он забит словами 125252.
На примере RT-11SJ V5.0 из дистрибутива:

BLOCK NUMBER  000046
000/ 000207 125252 125252 125252 125252 125252 125252 125252 *..***************
020/ 125252 125252 125252 125252 125252 125252 125252 125252 ******************
040/ 125252 125252 125252 125252 125252 125252 125252 125252 ******************
060/ 125252 125252 125252 125252 125252 125252 125252 125252 ******************
100/ 125252 125252 125252 125252 125252 125252 125252 125252 ******************
120/ 125252 125252 125252 125252 125252 125252 125252 125252 ******************
140/ 125252 000000 000000 000000 000000 000000 000000 000000 ***..............*
160/ 000000 000000 000000 000000 000000 000000 000000 000000 *................*
200/ 000000 000000 000000 000000 000000 000000 000000 000000 *................*

Здесь видно, что секция PATCH$ начинается по смещению 46142, размер 636 (414.) байт.
Проверяем по карте памяти:

 PATCH$  046142 000636 = 207.   words  (RW,I,LCL,REL,CON)
                        $RMEND  046142

Все точно.
Вот эти 207 слов мы можем добавить к RMON во время загрузки системы.
По смещению 4736 находится размер в виде $RMEND-KMON, его нужно увеличить на нужное количество байт.

[AFZ]

Самый простой способ (если нет карты памяти) - найти RMON stack.
Секция PATCH$ идет сразу после него и до границы блока.

Заглянул внутрь RT11DS (SJ). Есть, но похуже, начинается со смещения в блоке 304, т.е. всего 158 слов.

Это настолько нифига не даст, что даже рассматривать не стоит. Разве что нужно освободить 3-4 слова, но столько обычно и так найдется.

Ну почему же? Можно было бы использовать этот кусок оверлейного сегмента вместо родного. Думаю, подменить вызываемый оверлей не так сложно. О! А нельзя ли из одного оверлея вызвать второй? На том же уровне вложенности, без возврата. Блин, забыл, как это называется...

[form]

Думаю, подменить вызываемый оверлей не так сложно.

Подменить оверлей вообще без проблем, и менять существующие для этого не обязательно: оверлеи идут последними в образе - добавить еще один в конец несложно - если склероз не врет, в отличие от SAV тут нет ни таблицы оверлеев ни подпрограм переадресации. Есть только вычисляемый ID.
Главное - учесть оверлейные вызовы.
Наиболее простой способ - оставить старый оверлей, а из него вызвать новый - тогда не придется заботиться о вызовах из других оверлеев.
Впрочем можно сначала посмотреть по исходникам есть ли такие вызовы.
Сам оверлей KMON должен уложиться в 2 блока.

[AFZ]

Заглянул внутрь RT11DS (SJ). Есть, но похуже, начинается со смещения в блоке 304, т.е. всего 158 слов.

Заглянул внутрь RT11CD. Чуть лучше - на 17 слов больше. На ту часть, которая в RMON'е 158 слов хватит, или как? Или, хотя бы, 175 ? Не нашел ADOSSJ, ближе к вечеру спрошу у Макса.

Наиболее простой способ - оставить старый оверлей, а из него вызвать новый - тогда не придется заботиться о вызовах из других оверлеев.

Ну, если это так легко, то почему же мы до сих пор не сделали все это?

Сам оверлей KMON должен уложиться в 2 блока.

Это предельный размер оверлея или что?