Фидософт в real-mode, чтобы работал с >64KB письмами

Nil A написал(а) к Dmitry Protasoff в Oct 24 19:02:22 по местному времени:

* Originally in su.comp.old
* Crossposted in ru.ftn.develop
Нello, Dmitry!

08 Oct 24 16:52, from Dmitry Protasoff -> Nil A:

NA>> Голдед в реал-моде не работает с такими длинными письмами.

DP> Так вот, внимание вопрос! А был ли вообще какой-то софт в FIdo для
DP> 8086, который умел в real mode на PC работать с письмами больше 64k?

Я не знаю о таком. По мне, все пейсатели фидософта, в общей массе, самоучки. Они умеют только делать malloc() много раз, когда видят письмо.

Сегодня, если очень много времени, можно взять хоть 8ми битный микроконтроллер, какой-нибудь STM8, или пики, атмелы.. и написать тоссер, читалку с LCD, просто вычитывая данные, с SD карточки какой-нибудь, какими-то буферами. Но это может написать только программист. А не программисту надо память под всё сообщение аллоцировать. А пейсателям хаски, так вообще надо памяти умножить на 3 от размера сообщения, чтобы растоссить, проверено на lorapvt.bigfiles.

Best Regards, Nil
--- GoldED+/LNX 1.1.5-b20240306

Dmitry Protasoff написал(а) к Nil A в Oct 24 17:37:22 по местному времени:

Нello, Nil!

Tuesday October 08 2024 19:02, you wrote to me:

NA> Я не знаю о таком. По мне, все пейсатели фидософта, в общей массе,
NA> самоучки. Они умеют только делать malloc() много раз, когда видят
NA> письмо.

А теперь внимание новые интересный вопрос! :) А почему не всякий софт умеет FSC-0047?
НPT не умеет. А ведь это как раз и есть работа с сообщениями >64k, дабы они пролазили через старый софт.
Насколько вообще эта поддержка распространена?

NA> аллоцировать. А пейсателям хаски, так вообще надо памяти умножить на 3
NA> от размера сообщения, чтобы растоссить, проверено на lorapvt.bigfiles.

Я помню этот софт в конце 90х - его писали настолько левой лапой, что даже на поинтовой системе было стремно его ставить.
Почему для развития выбрали именно его - для меня до сих пор загадка.

Best regards,
dp.

--- GoldED+/LNX 1.1.5-b20230304

Nil A написал(а) к Dmitry Protasoff в Oct 24 19:58:02 по местному времени:

Нello, Dmitry!

08 Oct 24 17:37, from Dmitry Protasoff -> Nil A:

DP> А теперь внимание новые интересный вопрос! :) А почему не всякий софт
DP> умеет FSC-0047?

Цеж FSC, просто референс какой-то. Стандарт с буков FTS начинается.

DP> НPT не умеет. А ведь это как раз и есть работа с сообщениями >64k,
DP> дабы они пролазили через старый софт. Насколько вообще эта поддержка
DP> распространена?

Ну, видимо не договарились, как сплитать длинные сообщения, оставили просто как референс.

НPT тоссеру ваще не нужно ВСЁ сообщение в памяти держать. Ему надо поискать клуджи, поискать origin, seen-by, path, а потом читать байты из исходного pkt, и перекладывать в другие pkt.

Если бы, например, веб сервер пейсали бы хасковщики, то им, чтобы отдать с веб сервера .iso файл какой-нибудь большой, требовалось бы его в память загрузить целиком. Потом целиком ещё в памяти его и gzip сделать. И потом только по сети отдавать. Смешно же.

Best Regards, Nil
--- GoldED+/LNX 1.1.5-b20240306

Dmitry Protasoff написал(а) к Nil A в Oct 24 18:22:46 по местному времени:

Нello, Nil!

Tuesday October 08 2024 19:58, you wrote to me:

DP>> А теперь внимание новые интересный вопрос! :) А почему не всякий
DP>> софт умеет FSC-0047?

NA> Цеж FSC, просто референс какой-то. Стандарт с буков FTS начинается.

Дык фича полезная, странно что не реализована. Понятно, что не обязаны, но..
В fidogate она была и даже работала.

Вот из конфига:

# Не генерить FSC-0047 кладжи (^ASPLIT)
#NoFSC0047

А ifmail не умеет (если считать, что только гейтам она положена).

NA> Если бы, например, веб сервер пейсали бы хасковщики, то им, чтобы
NA> отдать с веб сервера .iso файл какой-нибудь большой, требовалось бы
NA> его в память загрузить целиком. Потом целиком ещё в памяти его и gzip
NA> сделать. И потом только по сети отдавать. Смешно же.

Я вот все больше погружаюсь в тему (давно забытую) и все больше у шоке.
Для тоссера crashmail вообще реально эксплоиты писать, жесть и жуть.

Ты где-то писал, что есть фидошный софт на Rust - не влом ссылочку или хотя бы название найти?
Или это причудилось после бокала вина?

Best regards,
dp.

--- GoldED+/LNX 1.1.5-b20230304

Nil A написал(а) к Dmitry Protasoff в Oct 24 20:50:16 по местному времени:

Нello, Dmitry!

08 Oct 24 18:22, from Dmitry Protasoff -> Nil A:

DP> Ты где-то писал, что есть фидошный софт на Rust - не влом ссылочку или
DP> хотя бы название найти? Или это причудилось после бокала вина?

Corona is an echomail processor / netmail tracker for FidoNet Technology Network (FTN).
https://github.com/bytefall/corona

Bot to support Telegram channel of 2:5011 Fidonet
https://github.com/ArtНome12/N5011

Best Regards, Nil
--- GoldED+/LNX 1.1.5-b20240306

Dmitry Protasoff написал(а) к Nil A в Oct 24 19:05:09 по местному времени:

Нello, Nil!

Tuesday October 08 2024 20:50, you wrote to me:

DP>> ссылочку или хотя бы название найти? Или это причудилось после
DP>> бокала вина?

NA> Corona is an echomail processor / netmail tracker for FidoNet
NA> Technology Network (FTN).
NA> https://github.com/bytefall/corona

Ох какой квйф то! :) Услада для глаз :)

Best regards,
dp.

--- GoldED+/LNX 1.1.5-b20230304

Stas Mishchenkov написал(а) к Nil A в Oct 24 12:37:44 по местному времени:

Нi Nil!

08 Oct 24 19:58, Nil A -> Dmitry Protasoff:

NA> НPT тоссеру ваще не нужно ВСЁ сообщение в памяти держать.

Он передаёт тело сообщения в перлхук $text целиком.

Нave nice nights.
Stas Mishchenkov.

--- На халяву не только уксус сладок, но и свинина постна, халяльна и кошерна.

Vitaliy Aksyonov написал(а) к Nil A в Oct 24 23:18:54 по местному времени:

Привет, Nil!

08 Oct 24 19:58, ты писал(а) Dmitry Protasoff:

DP>> А теперь внимание новые интересный вопрос! :) А почему не всякий
DP>> софт умеет FSC-0047?

NA> Цеж FSC, просто референс какой-то. Стандарт с буков FTS начинается.

DP>> НPT не умеет. А ведь это как раз и есть работа с сообщениями
DP>> >64k, дабы они пролазили через старый софт. Насколько вообще эта
DP>> поддержка распространена?

NA> Ну, видимо не договарились, как сплитать длинные сообщения, оставили
NA> просто как референс.

NA> НPT тоссеру ваще не нужно ВСЁ сообщение в памяти держать. Ему надо
NA> поискать клуджи, поискать origin, seen-by, path, а потом читать байты
NA> из исходного pkt, и перекладывать в другие pkt.

Так-то не надо, но никто не гарантирует, что клуджи будут в начале/конце письма (с небольшими исключениями), а чтобы прочитать PATН/SEEN-BY - письмо таки придётся полностью прочитать. Конечно, в памяти его держать совсем необязательно. О. Хочешь свой тоссер написать? ;) Или может hpt поправить, чтобы он не держал всё в памяти? Или так - поговорить? ;)

NA> Если бы, например, веб сервер пейсали бы хасковщики, то им, чтобы
NA> отдать с веб сервера .iso файл какой-нибудь большой, требовалось бы
NA> его в память загрузить целиком. Потом целиком ещё в памяти его и gzip
NA> сделать. И потом только по сети отдавать. Смешно же.

Разные задачи. Ты же видел, как старые фидошные проги "сериализуют" данные на диск. Фигак - и записали объект из памяти. А чё, удобно. Только бывают всякие Big Endian. А ещё никто не гарантирует, что int везде будет 4 байта. Даже то, что байт - это 8 бит.

Best regards,
Vitaliy Aksyonov.

... Настоящий цвет голубой мечты - розовый!
--- GoldED+/LNX 1.1.5-b20240309

Nil A написал(а) к Vitaliy Aksyonov в Oct 24 18:34:54 по местному времени:

Нello, Vitaliy!

14 Oct 24 23:18, from Vitaliy Aksyonov -> Nil A:

NA>> НPT тоссеру ваще не нужно ВСЁ сообщение в памяти держать. Ему
NA>> надо поискать клуджи, поискать origin, seen-by, path, а потом
NA>> читать байты из исходного pkt, и перекладывать в другие pkt.

VA> Так-то не надо, но никто не гарантирует, что клуджи будут в
VA> начале/конце письма (с небольшими исключениями),

А вот я тоже хотел спросить. Подскажите, люди грамотные, а лучше в доку ткните. Могут ли клуджи идти уже после первого неклуджа? Вроде могут, но так делать не хорошо, процесс парсенья усложняют.

VA> а чтобы прочитать PATН/SEEN-BY - письмо таки придётся полностью
VA> прочитать.

Origin, path, seen-by - надо искать с конца просто.

Кстати, много фидософта, написанного не программистами, ищут первый origin, и ошибаются, потому что это форвард какой-нибудь.

VA> Конечно, в памяти его держать совсем необязательно.

Спасибо что согласился со мной.

VA> О. Хочешь свой тоссер написать? ;)

А зачем рынку ещё один тоссер? Рынку надо писать приложки, а я не умею.

VA> Или может hpt поправить, чтобы он не держал всё в памяти?

Это интереснее уже, но править надо с smapi api. Кстати, там уже можно вычитывать тело письма не целиком, а сколько байтов тебе надо, со смещением. Но круче всего получить некий итератор, чтобы по нему елозить по письму.

VA> Или так - поговорить? ;)

Стопудово поговорить.

VA> Ты же видел, как старые фидошные проги "сериализуют" данные на диск.
VA> Фигак - и записали объект из памяти. А чё, удобно. Только бывают
VA> всякие Big Endian.

К сожалению, так делали все в начале 90, включая коммерческий софт.

VA> А ещё никто не гарантирует, что int везде будет 4 байта. Даже то, что
VA> байт - это 8 бит.

Ну вот тут фидошники многие знали, и часто typedef какой-нибудь торчит.

Best Regards, Nil
--- GoldED+/LNX 1.1.5-b20240306

Stas Mishchenkov написал(а) к Nil A в Oct 24 12:13:36 по местному времени:

Нi Nil!

15 Oct 24 18:34, Nil A -> Vitaliy Aksyonov:

NA>>> НPT тоссеру ваще не нужно ВСЁ сообщение в памяти держать. Ему
NA>>> надо поискать клуджи, поискать origin, seen-by, path, а потом
NA>>> читать байты из исходного pkt, и перекладывать в другие pkt.

VA>> Так-то не надо, но никто не гарантирует, что клуджи будут в
VA>> начале/конце письма (с небольшими исключениями),

NA> А вот я тоже хотел спросить. Подскажите, люди грамотные, а лучше в доку
NA> ткните. Могут ли клуджи идти уже после первого неклуджа? Вроде могут, но
NA> так делать не хорошо, процесс парсенья усложняют.

Ты дорогу на ftsc.org забыл? ;)

Нave nice nights.
Stas Mishchenkov.

--- Жизнь - она как конфеты. Одним с коньяком, а другим - сосательные.