= Сообщение: 156 из 2735 ==================================== RU.FTN.DEVELOP = От : Mithgol the Webmaster 2:5063/88 02 Jan 14 22:27:18 Кому : All 02 Jan 14 22:27:18 Тема : PhiDo, скриншот 3 FGHI : area://RU.FTN.DEVELOP?msgid=2:5063/88+52c5b6e8 = Кодировка сообщения определена как: CP866 ================================== Ответ: area://RU.FTN.DEVELOP?msgid=2:5020/830.36+52c9739d ==============================================================================
Как нетрудно видеть на нижеследующем скриншоте, мне удалось сделать эхолист в PhiDo по своему содержанию подобным эхолисту в GoldED-NSF. По сравнению с предыдущим скриншотом я добавил в него столбец количества новых сообщений.
Двигаясь по этому пути, я пришёл к более глубокому разочарованию в нынешнем фидонетовском программном обеспечении, нежели то разочарование, которое было первоначально вызвано просто негипертекстовостью.
Во-первых, я никак не могу понять, по какой причине GoldED-NSF создаёт такие .JLR-файлы, в которых первые четыре байта в шестнадцатеричной системе счисления имеют вид 7C 34 12 5B, и следующие четыре байта также имеют вид 7C 34 12 5B.
По стандарту JAM первые четыре байта должны быть хэшем CRC-32 от имени пользователя, взятого в нижнем регистре (что означает, что буквы 'A-Z' в имени становятся буквами 'a-z', но больше никаких изменений), а вторые четыре байта должны содержать уникальный идентификатор пользователя.
Я так понимаю, что создатели GoldED+ решили, что CRC-32 ── достаточно уникален для идентификатора, и этим объясняется подобие второй четвёрки байтов и первой.
А вот почему именно 7С 34 12 5B ── то есть число 0x5b12347c (в записи языка Си или JavaScript) ── этого я никак не могу себе объяснить.
В конфигурации GoldED-NSF первое значение UserName стоит Mithgol the Webmaster, однако CRC-32 от строки 'mithgol the webmaster' будет 0xa4edcb83.
В конфигурации GoldED-NSF параметру RegisterName задано значение SysOp, однако CRC-32 от строки 'sysop' будет 0x8ab05249.
Если вдруг только от строки 'mithgol' брать CRC-32, то выходит 0x41cfb294.
Откуда тогда 0x5b12347c берётся-то?
(В итоге я плюнул и научил PhiDo пренебрегать содержимым первых восьми байтов.)
Во-вторых, я убедился, что поле activemsgs в структуре FixedHeaderInfoStruct внутри .JHR-файла может содержать неверное число сообщений, не совпадающее с количеством записей в .JDX-файле, не содержащих -1 в полях CRC32 и смещения. Так как к JAM я обращался только посредством Голдеда и Husky, то теперь я гляжу на эти программы с некоторым подозрением. Хорошо ещё, что sqpack (также часть Husky) восстановил мне корректные значения activemsgs в заголовках .JHR-файлов.
В-третьих, я убедился, что для выяснения количества новых сообщений приходится читать минимум три файла: сперва .JLR (в котором указан номер последнего прочитанного сообщения), затем .JHR (в котором указан номер BaseMsgNum, от которого ── а не от единицы ── в общем случае идёт нумерация), и наконец .JDX (чтобы сосчитать, сколько после этого номера идёт других сообщений, не подвергнутых удалению).
Можно также просто читать (и считать) сообщения от новых к старым до тех пор, пока у очередного сообщения в заголовке MessageFixedHeader поле MessageNumber не будет искомым номером. Однако читать их нужно по смещениям, взятым из .JDX, а сами заголовки лежат в .JHR, так что опять же те же три файла читать в общем.
Всё это несколько мрачно. Я посмотрел на даты и убедился, что формат баз JAM создан в 1993 году и что формат баз Squish создан с 1991 по 1994 год (однако уступает JAM по числу одновременно хранимых ссылок на ответы к сообщению ── так что этот чуть более новый формат едва ли не хуже старого JAM). Двадцать лет фидошники принуждены были пользоваться ими, но никто не создал ничего получше?!
* изначально написано в эхоконференцию Ru.Fidonet.Today * также было отослано в эхоконференцию Ru.FTN.Develop
Фидонет будет великим и гипертекстовым! [Ru.Mozilla] http://Mithgol.Ru/ Mithgol the Webmaster. [Братство Нод] [Team А я меняю subj]
... Правительство не решает проблем, оно финансирует их. (Рональд Рейган) --- Знаешь ли ты, что "гравёр" пишется через "ё"? * Origin: А что нам йети // Да на это ответит? (2:5063/88)
