Товарищи, добрый вечер.
Только что вспомнил одну неприятную особенность 98/ME, из-за которой оставил надежды всерьёз использовать его на физике. И патчами R. Loew она не лечится, хотя примерно про это же.

Сделал я себе как-то стенд с 98SE, хотел на нём всякий "ретро DevOps" поделать - т.е. поднять сайт на PWS, Synchronet, организовать удалённую админку и т.д. Диск у него был - всего гигов 40, т.е. патчи не требовались. Какое-то место я ещё отвёл под, кажется, NT4 и кое-какой экстремальный нерелейтед в дуалбуте, поэтому, возможно, 98 досталось даже меньше 32 гигов. Но с соседней машины на 7 удалось на этот раздел полностью скопировать часть моего архива дистрибутивов, относящуюся к 9x и досу. Но в один прекрасный момент пришлось (или я решил, для профилактики) прогнать скандиск, и он стал жаловаться на слишком длинные пути, даже без учёта VFAT.

И предлагал, не помню точно, то ли тупо поперемещать затронутые файлы повыше, но, скорее всего, - просто "удалить", усечь или что-то такое, т.е. не факт, что скандиск интересовала сохранность данных. А NT5 и всем виндам новее - это норм. С NT4 всё ещё грустнее: она искаропки видит либо FAT16, либо NTFS, и сторонний драйвер FAT32 нашёлся достаточно поздно. Вот здесь: http://toastytech.com/guis/miscb2.html - упоминается про некий FastFat32... и про какие-то USB-дрова для NT4.

Таким образом, вывел такую рекомендацию: ставить Win9x либо в виртуалку с проброшенной совместимой видеокартой, либо, если уж на физику - то большие объёмы/нужные данные лучше держать на шаре - хоть Samba с разрешённым SMBv1 для локальной сети. Ибо на локальных носителях (внимание, это относится и к USB-флешкам, особенно уже вставленным в момент загрузки) СкамДиск может устроить беспорядок.

Или... есть ещё один вариант - заменить скандиск на что-то другое. Конкретно в случае 98 я бы удалил виндовый скандиск, вместо досовского взял DOSFSCK из фридоса и, для полного счастья, на место SCANDISK.EXE положил враппер на условном паскале, преобразующий аргументы для скандиска в синтаксис DOSFSCK.
С ME, скорее всего, будет уже сложнее но, ИМХО, стоить того будет.

Эхх, скорее бы 3.11-98 подружили со стильно-модно-молодёжным фридосом. Или не с фридосом, а с Jemm386. Правда, просто брать и менять его на EMM386 из MS-DOS или DR-DOS не рекомендуют - значит, видимо, не факт, что одной поддержкой GEMMIS всё решится.

Эхх, всё-таки, напряжно с V86-многозадачностью в опенсорсном DOS.

Гуглил на эту тему, и вариантов получилось немного, один замечательнее другого.
- Либо, если я так хочу, чтобы в основе был FreeDOS, то нужно расчехлять HX DOS Extender, чтобы в нём запустить DOSBox-X, и уже в нём - винду 3.1, а это - накладные расходы. Радует хоть, что, если в досбоксе не пользоваться командой BOOT - то эффективность у него всё равно на порядок выше, чем если бы в этом же стеке на месте досбокса был QEMU или Bochs. Как бонус - досбоксу не обязательно презентовать всю ФС хоста, а можно, наоборот, врубить режим песочницы - сесурити, блин.
- Либо, если хочу сохранить ту легковесность, ради которой использую DOS на железе, но при этом получить многозадачность - но не фридос. А, например, классика-6.22, на которую после стильно-модно-молодёжного фридоса (особенно, с его FAT32 и LBA48 искаропки) возвращаться ой как влом.
- Есть, конечно, ещё один вариант, который подразумевает и нативное исполнение 3.1x в 386-режиме, либо вообще собственный легковесный аналог (MultiMAX), и опенсорсность DOS, но ещё он подразумевает полнейшие непонятки! Речь про DR-DOS, у которого, вроде, даже одну из версий официально открывали и форкали, но. Во-первых, насколько он реально опенсорсный, и все ли компоненты, или только ядро+комманд.ком, а что с местными EMM386 и TaskMAX/MultiMAX, тоже открыли? Во-вторых - если фридос - таки позиционируется как drop-in replacement для стандартной де-факто MS-DOS (и, в свою очередь, "новодельный стандарт де-факто"), то DR-DOS - это "параллельная вселенная", причём, если почитать - собственно, нормально совместимой с DOS она стала довольно поздно, а изначально это была тупо переименованная CP/M-86. Так что (((предчувствия))) по совместимости остаются. И по стабильности, особенно, если вспоминать, что ребята из DR-DOS Enhancement Project вообще не стесняются экспериментировать как поведут себя другие ОС, если наткнутся на раздел "FAT32+" с большими файлами, и спутают его с обычным FAT???, а основным дистром EDR-DOS сейчас, видимо, считается SvarDOS, который вообще trolling release.

Просто так взять и притащить MultiMAX во фридос? Насколько я понимаю, MultiMAX зависит от штатного EMM386 из DR-DOS (и от ключа /MULTI), а последний во фридосе не пойдёт.
Что-то другое, тот же DesqView/386? Во-первых, он так же зависит от QEMM, который, несмотря на исключительную совместимость со всем подряд, ущербнее не то что JEMM, но даже штатных XMM/EMM из винды 98! Тем более
https://github.com/fone32/desqview-examples

>IRQs and DESQview

>Due to performance reasons DESQview is reprogramming PIC to redirect IRQ (08h-0Fh for IRQ0-07h and 70h-77h for IRQ8-15) IRQs - probably it was done mainly to speed up performance by separating IRQ5 from interrupt 0Dh: the General Protection Fault (GPF). While it does not sounds like a good idea today it wasn't such a bad move back in its day.

>DESQview relocates IRQ0 to INT 50h and uses next interrupt vectors for the rest of IRQs up to INT 5Fh.

...

>IRQ redirection under DOS Extenders

>As noted earlier DESQview during startup is reprogramming PIC in order to redirect IRQs. If you are developing a DOS extended application that installs own IRQ handlers you have to check how your extender deals with this situation. Some DOS extenders - like Phar Lap TNT DOS Extender for example - always present IRQs at their original locations regardless of VCPI/DESQview setup. Other - like PMODE - may not be aware of DESQview at all and/or may ignore the DESQview behavior.

Я за виндой таких приколов не помню!
Плюс, если вообще начать копать про quality-of-life в DOS, то становится понятно, что V86-/VDM-решение должно быть такое, чтобы внутри был доступен хотя бы DPMI, не говоря уж о VCPI (так понимаю, вряд ли он чему-то, кроме DPMI-хоста пригодится) или конкретных DPMI-хостах, помимо DPMI ещё умеющих в минимальную эмуляцию Win32... И, если начать искать V86-/VDM-решения уже с этими критериями, то становится понятно, что кроме 98SE, 3.1x и, может быть, DR-DOS MultiMAX, особо ничего стоящего и нет.
Да, есть полуось, но она слишком привередлива к железу (у меня не загрузилась ни на одном физическом компе, даже которые можно назвать "старыми", и я их тоже считал для достаточно "аутентичными").
Да, есть dosemu, юзающий V86 на 32-битном линуксе, но, во-первых, 3.1 там идёт с костылями, а во-вторых - дык, кагбэ, я как раз от линукса уйти пытаюсь! Особенно - потому что нужный мне софт - он под линукс нативно есть, но в нативных никсах с ним слишком много п-вординга, ему лучше именно дос/винда/полуось/реактось, но про полуось - см. выше, реактось - "система для виртуалок", т.е. это точно не про легковеность.

Что там ещё из альтернативных решений могло остаться более-менее серьёзного? SCO Merge. Если просто погуглить - то ни 386-режим 3.1, ни DPMI не умеет, но постойте! Были же у него версии до Pro, т.е. не имеющие отношения к QEMU/kqemu, о таки поддерживающие Windows 9x, а Windows 9x - значит, штатный DPMI-хост! Как они это делали?
Гугл на это скажет, что для исполнения нативного виндового софта использовали Wine-подобный подход и кучу паравиртуальных дров. DOS-сессии, открытые из винды, так понимаю, продолжали юзать V86 от самого Merge.
То есть, Merge 4-5.3 - он винду именно что паравиртуализирует! А, всё-таки, как с DPMI?
После ещё нескольких запросов гугл отвечал, что Merge запускается в первом кольце защиты и гоняет VMM32.VXD с какими-то дровами во втором... и DPMI, в худшем случае, транслирует, как обычный MSVPC 2007...

А я ведь просто хотел (легковесное && опенсорсное) окружение для IP-фидоноды! Но раз это IP-нода, и то по определению "многолинейная" => binkd должен слушать даже во время тоссинга => эта среда должна уметь в многозадачность...

Но, походу, архитектура реальной ноды будет либо
"Windows 3.11 - DOSBox-X - HX DOS Extender - FreeDOS",
либо:
"Windows 98SE - Merge 5.3 - OpenServer 5 Definitive 2018", и в этом варианте - уже никакого опенсорса, кроме самого фидософта. Хорошо хоть, если с дровами на >>48123

>Intel D945GCLF2: Atom 330 @1,6Ghz 2C4T, 945, Rtl8169, HDA

у SCO будет лучше, чем у реальной 98.
DR-DOS сразу на прод ставить стремаюсь.

Ещё напрашивался вариант с досбоксом в KolibriOS, но, как минимум, его надо до-/заново портировать, чтобы подружить с сетевым стеком KOS (которого во времена прошлого портирования просто не было), а в идеале - портиовать уже не ванильный досбокс, а тот же DOSBox-X, потому что в ванильном - сеть всё равно поднимается адскими костылями (в ванильном - нужно настроить проброс COM-порта куда-то на отдельный шлюз, где телнетом будет отвечать pppd, и, соответственно, парный PPPD внутри досбокса, а в DOSBox-X - можно просто включить эмуляцию NE2000 в SLiRP-подобном режиме).