Nekun @nekun@qoto.org

Анон, не задумывался над тем, насколько ограничена ширина канала связи естественного общения у людей?

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

Именно так я и воспринимаю эту картинку: положим, основной разъём на затылке - основная линия скоростного нейроинтерфейса, два поменьше - резервные линии, зрительный контакт - сигнальная линия согласования и контроля потока, соединённые руки - предохранительный мастерсвитч-вотчдог, который перед установлением соединения программируется на автоматическое отключение, чтобы не зависнуть ненароком в радости полного, неограниченного погружения друг в друга.

@rf @ru
Original: https://danbooru.donmai.us/posts/4014225

Предлагаю показать ваших лучшего мальчика и лучшую девочку.

Почему они? Казалось бы, не может быть на реальном человеческом теле показано это смелое, захватывающее, одновременно яркое и вызывающее, но тёплое и мирное, мягкое изящество черт подростковой юности, к которому стремятся в аниме. Но нет, всё же есть художники, которые могут доказать на себе, что это возможно. Как же здорово, что они дают некоторую надежду, что когда-нибудь можно будет ослепить "незыблемую" природу своими мечтами.

Original: https://store.nekun.in/bestboy.jpg
https://store.nekun.in/bestgirl.jpg
@ru @rf

Абсолютно совместимый DOS стаб.

https://github.com/Nekun/compatstub

Как известно, каждый исполняемый PE EXE начинается с DOS-заглушки: поскольку у него одинаковое расширение с 16-битным исполняемым форматом MZ EXE, принятым в DOS, в начало PE помещают небольшую MZ-программу, чтобы при попытке запуска в DOS выводилось сообщение об ошибке и происходило корректное завершение, а заголовок расширяют полем с указателем на начало заголовка PE.

Так вот, оказывается что эта программа совместима лишь с MS[PC]-DOS 2.0+: при попытке запустить заглушку в PC-DOS 1.00 в консоль выводится мусор и система зависает, хотя поддержка EXE в ней есть и даже есть ранняя версия LINK в этом формате на загрузочной дискете! Обращаемся к официальному мануалу[1], видим что сискола int21h/4Ch для завершения ещё нет. Меняем на традиционный прыжок в PSP на int20h, всё так же. Запускаем debug.com our_exe.exe: видим, что хотя PSP сформирован правильно и управление передано в новый выделенный сегмент (в отличие от COM, EXE грузится по нулевому смещению в отдельный от PSP CS), а в нём пусто. Загрузчик не загрузил исполняемый модуль!

В том же мануале [1] есть описание формата EXE и видим, что он ещё не стабилизировался, и некоторые поля ещё числятся резервными: в частности, e_cblp, который указывает размер последней 512-байтной страницы загружаемого модуля. Так как размер EXE-шника указывается в следующем поле e_cp в 512-байтных страницах, то в DOS 1.x размер исполняемого файла должен быть кратен 512 байтам. Обратившись к публично доступным исходникам [2], смотрим код загрузчика (в DOS 1.x загружает command.com, в 2.x, емнип, перенесли в ядро). Согласуясь с исходником, отреверсил COMMAND.COM PC-DOS 1.0, и увидел что отличия в коде несущественные. Так вот, при подсчёте размер заголовка в 16-байтных параграфах пересчитывается в размер в 512-байтных страницах, округляется в большую сторону и вычитается из числа страниц для загрузки по CS:0: https://github.com/microsoft/MS-DOS/blob/master/v1.25/source/COMMAND.ASM#L2050 . Потом, размер читаемого блока задаётся 512 байт и загружаемый модуль начинает читаться из файла по прежде высчитанному округленному в большую сторону размеру заголовка в страницах. Стало быть, размер заголовка тоже должен быть кратен 512! Ну а стабы PE очень маленькие, без таблиц релокации и обычно занимают с заголовком порядка сотни байт. По-видимому, с самого начала формат EXE разрабатывался с расчётом, что им будут пользоваться только действительно по необходимости, когда нельзя втиснуться в один сегмент 8086 и вплоть до DOS 2.0 забыли предусмотреть и произвольный размер кода, и размер заголовка без кучи релоков.

В общем, сделал абсолютно обратно совместимый стаб: 512 байт на заголовок, 512 байт на код, jmp [<initial ds>:0] для завершения, и теперь наш код работает даже на PC 5150+64KB RAM+PC-DOS 1.00, равно как и во всех последующих DOS. На удивление мало линкеров позволяют заменить дефолтный стаб: в GNU ld этого вообще не предусмотрено, а в lld-link хоть и есть опция /stub, но она не задействована в коде. Пока обнаружил только форматёр fasm и MS LINK. Мануально, к сожалению, поменять стаб тоже отнюдь не просто: 32-битные PE почти всегда position-dependent, а загрузчик ложит по ImageBase образ всего файла, начиная с MZ: поэтому изменив размер заглушки, смещения в коде будут разрушены. Рудиментарную таблицу релоков нередко стрипают, и информации для патчера не остаётся.

[1] http://www.textfiles.com/bitsavers/pdf/ibm/pc/dos/6172220_DOS_1.0_Jan82.pdf
[2] https://github.com/microsoft/MS-DOS/blob/master/v1.25/source/COMMAND.ASM

@ru @rf

https://www.transmissionzero.co.uk/computing/win16-apps-in-c/

Тут уже не совсем консистентно, но блядь, это уже Win16 начальной версии! К Win32 с восьмёрки даже манифест прикручивать не надо, чтобы подхватило системную тему.

Немного примеров годного "классического" подхода к GUI.

(фулл) https://store.nekun.in/good-ui.png

Я, если честно, не понимаю пренебрежения некоторых пользователей никсов к графическим интерфейсам, да и примеры они приводят далеко не самые удачные, типа чатиков для "простых пользователей" с тремя бестолковыми контролами, размазанными по огромному окну и грустной рожей при сбоях вместо документации. В хорошем GUI чувствуешь себя как в кабине самолёта: компактно, полнофункционально, структурировано, самодокументировано. Жаль, что такой подход сейчас сохранился по большей части в профессиональном ПО для Windows.