Итак, я закончил дизассемблирование и разбор библиотеки NETLIB.A. Хоть я и понимаю, что чудес на свете не бывает, но, как всегда, надеялся на маленькое чудо. Увы, получилось как всегда.
Код библиотеки написан весьма коряво, что, конечно, снижает производительность но облегчает разбор в IDA 
Кроме того, библиотека жестко привязана к функциям консольного драйвера МикроДос, и вызыает их прямым переходом. В результате, программы, использующие эту библиотеку, не будут работать в CP/M. Сама библиотека поддерживает кучу функций, описание которых лежит в файле C.TXT на том же диске, что и библиотека. Описание очень интересное, что и сподвигло меня на ее раскопку.
Насчет ответчика сети. В описании говорится, что это произвольно выбираемый РМУ, отвечающий серверу на команды передачи данных в режиме широковещательного адреса. Одна из функций библиотеки (15 - установка логической связи), должна возвращать адрес этого самого ответчика, и мне было интересно - где она его берет? Оказалось, что ответчик - это просто активный РМУ в сети с самым старшим адресом. И все. Не знаю как в мечтах автора библиотеки, но в реальной жизни РМУ отказывается отвечать на широковещательный адрес, даже если ему присвоить номер 15. Я еще раз прошел по коду ОПТС 2 - там однозначный запрет на передачу в сеть после приема широковещательного адреса и изменить это никак нельзя. Могу предположить, что эта возможность была в ОПТС 1. Что интересно - подпрограммы библиотеки действительно ждут ответа от сети при передаче, независимо от типа адресации. То есть ответчик в сети когда-то реально существовал.
Меня заинтересовала функция 9 библиотеки - из бейсика РМУ на экран РМП. Судя по описанию, она должна выгрузить из РМУ программу в токенах и показать ее на экран в текстовом виде, то есть распаковать. Я уже надеялся посмотреть фирменный распаковщик программ. Все оказалось проще. В РМУ посылается пакет S - запрос на получение данных типа 2 (бейсик-программа), а в поле +04 пакета S (которое копируется в ответный пакет R на то же место) указывается тип данных 0 - экран. И все. То есть сам РМУ должен распаковать программу и передать ее серверу уже в распакованном виде. Понятно, что этого не происходит - в коде ОПТС 2 просто нет такой возможности. Видимо, это тоже было заложено в ОПТС 1.
В библиотеке реализован автозапуск программ на бейсике, посылаемых по сети. Делается это так. После отсылки бейсик-программы, на РМУ пересылается коротенький самозапускаемый код:
Код:
basic_autostart_sub: ; DATA XREF: init_basic_autorun+Fo
ld hl, (word_63BF)
jp loc_362C
В ОПТС 2.0 это работать не будет - там по этим адресам нет ничего интересного. Общая идея этого кода - в HL загружается адрес начала программы, и управление передается интерпретатору. Похожий код имеется в конце обработчика команды LOAD - если в этой команде указан параметр R, то программа также автозапускается. И адреса там правильные. Но в бейсике ОПТС2 это работает не особо стабильно - иногда запускает программу, иногда нет. С причиной я разбираться не стал - придумал другой способ автозапуска.
Вообщем, библиотека оказалась не особо совместимой с сетью ОПТС2, и не особо полезной. Но все же, разобрав библиотеку, я почерпнул важную и полезную информацию.
Во-первых, прояснились поля +4 и +5 пакета S. Эти поля тупо копируются в ответный пакет R при передаче данных от РМУ к серверу, и никак не используются сетевым драйвером ОПТС. Оказалось, что поля эти используются самой сетевой библиотекой.
Поле +4 - это тип и назначение данных, принимаемых сервером от РМУ. Возможны такие значения:
Код:
0 - экран консоли РМУ.
2 - образ памяти с заранее определенной длиной
3 - образ памяти, ограниченный тремя нулями для данных или тремя байтами 1A (EOF) для бейсик-программы
4 - дисковый файл.
Таким образом, прояснилось назначение типа данных 4 (в ОПТС он не используется, начальный и конечный адрес установлены в 0). Это просто данные, подлежащие записи на диск.
Поле +5 пакета S - это адрес в памяти сервера, по которому загружаются принятые от РМУ данные. Используется в функции 14 (из ОЗУ РМУ в ОЗУ РМП) и ей подобными.
Также прояснилось, насчет мифических пакетов типа F и B, описания которых встречаются в документации по сети. На самом деле, такие пакеты по сети не передаются. Они существуют только внутри подпрограмм библиотеки, и используются для взаимодействия между отдельными процедурами, обозначая фазы сетевого протокола:
Код:
F - файловая фаза. Происходит открытие файла и подготовка к чтению-записи.
B - конец сетевого обмена при передаче данных
С - конец сетевого обмена при приеме данных
G - ошибка сетевого обмена
Похоже, код библиотеки и документацию к нему писали совсем разные люди. Иначе непонятно, зачем в документацию внесли информацию о кодах внутреннего взаимодействия библиотечных модулей. Пользователью снаружи это все равно недоступно.
Практической пользы от вышеописанного практически никакой - для реальной работы с сетью это не нужно. Разве только автостарт бейсика имеет реальную пользу. Но для раскопки сетевых программ все это может очень даже пригодиться. И еще - библиотека реализует протокол, немного несовместимый с ОПТС2. Видимо, под ОПТС2 была написана другая библиотека, но где ж ее искать...
Сейчас пойду править описание протокола в соседней ветке. Кроме того, получив кое-какие идеи из библиотеки, я доработал свою программу сетевого обмена. Сейчас дотестирую и тоже выложу в ту ветку.
Сообщение от forth32
Ответить с цитированием
Размещение рекламы на форуме способствует его дальнейшему развитию 
