создан 64битный кросс-тулчейн для DOS: dj64dev

Я подумал, что столь отборная некрофилия заслуживает темы в толксах.

но это не толксы, чювак…

Практического применения у этого поделия, надеюсь, нет.

Надо же будет куда-то с линукса валить

но это не толксы, чювак…

Блин, сорян… Как перенести?

UPD: Ага, спасибо за перенос.

при чём, под ДОСом он стартует ELF-файлы.

Поправка, 64-битные не способны работать под чистым ДОСом, только в эмуляторе!

The resulting programs run on the emulated DOS environment, with eg dosemu2 emulator. In theory the 64-bit DOS extender can be written to run such programs under the bare-metal DOS, but the future of DOS is probably in the emulated environments anyway.

Т.к. не существует «64-bit DOS extender» по типу 32-битного DOS-4GW

Как сочетать 64-битный код с 16-битным?

Как сочетать 64-битный код с 16-битным?

Точно также, как вызывают 16-битный код DOS API (для доступа к диску, сети) из 32-битного кода, созданного gjgpp. Нужен расширитель - https://ru.wikipedia.org/wiki/%D0%A0%D0%B0%D1%81%D1%88%D0%B8%D1%80%D0%B8%D1%82%D0%B5%D0%BB%D1%8C_DOS

Точно также не выйдет. Под 32 битами есть Vm8086, под 64 битами его нет.

Т.к. не существует «64-bit DOS extender» по типу 32-битного DOS-4GW

Вот же слабаки, чего ж не наклепали то? :) Спасибо за пояснение.

Экстендеры не используют V86, они переключаются назад в реальный режим, поскольку много всего нативно-досовского низкоуровневого (драйвера, не приложения обычно) в V86 может сломаться.

Сбор средств на FreeDOS-32

Как сочетать 64-битный код с 16-битным?

Я так понимаю, в рамках данного тулчейна - особо никак. По крайней мере, в видосе говорится, что даже если у вас есть 32битный ассемблер в проге, то это уже накладывает какие-то там существенные ограничения и трудности при сборке. А про 16битный код там вообще ни слова.

С другой стороны, я видел проект от того же аффтора, который именно это и делает. Тут у него, похоже, совмещаются 16битные асм-файлы фридоса и 64битный код. Попытки покопать исходник мало к чему приводят: такой наркоманской макросни я давно не видел. Видимо, ответ на вопрос «как», нам не светит. :)

Сбор средств на FreeDOS-32

А это, кстати, я видел: это был фейк. Chelson Aitcheson не имеет ни малейшего отношения к проекту freedos-32, и в фейкометании он известен давно.

Точно также не выйдет. Под 32 битами есть Vm8086, под 64 битами его нет.

v86 ведь нужен только для риал-модового 16битного кода? А не вообще 16битного кода. Так-то 16битный код можно гонять в защ.режиме, а вот конкретно риалмодовый - непонятно как. Но, вроде, в рамках данного тулчейна это и ни к чему.

Экстендеры не используют V86, они переключаются назад в реальный режим, поскольку много всего нативно-досовского низкоуровневого (драйвера, не приложения обычно) в V86 может сломаться.

Я уверен, что это не так: emm386 ЕМНИП переводил всё в прот моду и использовал v86. И ничего не ломалось. Конкретно про экстендеры - не знаю, но, если они и не используют v86, то причина в чём-то другом.

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

Если emm386 уже запущен - то логика немного меняется, они через его апи выходят в защищённый из v86-контейнера, но тут v86 делается не экстендерами а уже запущеным emm386.

Ну вот когда емм386 уже был запущен, то экстендеру же все равно надо вызывать риалмодовый дос. Соответственно, это он будет делать через v86. По-другому никак. А значит, что ему мешает делать то же самое и если емм386 не был запущен?

Про аппаратные прерывания в отсутствии емм386 я не подумал: с таким сетапом, видимо, все происходит как вы и описали. Но это не единственный сетап, а аппаратные прерывания - не единственные прерывания. :)

А значит, что ему мешает делать то же самое и если емм386 не был запущен?

То что экстендер не может захватить на себя управление системой в целом, он помогает только одному конкретному приложению. В случае с запущеным emm386 все действия по переключениям режимов в обе стороны делает он, и вся забота о совместимости всего этого с досом - тоже на нём (ведь он часть доса и там всё отлажено в этом плане, в том числе сам дос где надо пофикшен чтобы emm386 было удобнее). У экстендера всего этого нет, под него никто заранее не подстраивался, ему надо максимально изображать как будто ничего не менялось. Неожиданный для доса v86-режим как минимум сломает himem.sys который был подгружен почти у всех (потому что himem тоже использует защищённый режим временно), ну а так не только его.

Про аппаратные прерывания ты видимо не до конца понял в чём дело. Например, можно сделать кастомный драйвер мышки, который по одновременному нажатию двух кнопок мыши аварийно завершает текущую программу. Разумеется, про экстендер он ничего не знает, и завершать он её будет как обычную 16-битную. Так что экстендер передаёт управление обработчику в мышином драйвере, а назад управление уже не получает - и эта ситуация должна привести к корректной дальнейшей работе системы. Очевидно, для этого надо быть в точно том же режиме какой был до запуска проги.

С аппаратными я как раз понял, по тому и написал, что с ними вы правы. Но инт21 то он вполне может под в86 гонять. И более того, в присутствии емм386 нет альтернативы - обязательно будет под в86 его гонять.

Хаймем, кстати, имел 2 режима работы: в случае в86 он мог просто инт15 использовать, то есть, там был этот кейс предусмотрен.

ЕМНИП хаймем как раз вообще не использует прот моду, даже временно. У него 2 режима поддерживались: unreal mode и int15. Защ режим ему не был нужен, по этому он и был совсем маленький и простой. С переключалкой режимов он был бы больше.

по типу 32-битного DOS-4GW

Зато для него готовое название «DOS-64GW» напрашивается... :-D

Но инт21 то он вполне может под в86 гонять. И более того, в присутствии емм386 нет альтернативы - обязательно будет под в86 его гонять.

Да что ж такое то, сколько повторять? Нет нигде реалистичной спецификации на то, что может оказаться внутри int21. Начиная от разных несовместимых версий доса и заканчивая произвольными резидентными программами, безо всякой вежливости перехватывающими его и меняющими как угодно. Это чёрный ящик, лезть внутрь в автоматическом режиме чревато неожиданными проблемами. Да даже штатное: ну представь, юзер с помощью int21 читает файл, там получается ошибка диска, выводится abort/retry/fail, юзер жмёт abort, и всё - управление назад уже не возвращается, продолжается работа проги, из которой твой экстендер был запущен, а сам экстендер перетирается в памяти чем-то другим, но проц до сих пор в V86 режиме и в итоге всё крашится.

Любое прерывание, хоть аппаратное, хоть програмное, может содержать внутри кражу потока управления, и экстендер должен быть готов к тому, что возврата из прерывания уже не будет, его код затрут и больше не вспомнят. А значит, там должен быть полноценный самодостаточный реальный режим.

Чет как то максимально ненужно.

Даже в свое время мсдос 6.22 (1994 год) отставал от появившихся в тот же год net и freebsd

А сейчас и подавно не нужен

Не смотря на то, что в первой части вы всё верно написали, насчёт того, что в прерывании может быть всё что угодно, остальное не верно. Достаточно хорошо известно, что EMM386 именно что использовал V86 ради единственной DOS-сессии. Он манипулировал памятью, чтобы отобразить имеющуюся память выше мегабайта в адерсные дыры пространства меньше мегабайта. Это позволяло ядру DOS, драйверам загружаться в т.н. верхнюю память и UMB.

Я не знаю подробностей, но могу предположить, что ядро DOS и EMM386 умели общаться, т.к. EMM386 был драйвером DOS, загружался на раннем этапе и после этого ядро DOS сам перемещало себя в UMB. (Параметры config.sys DOS=HIGH,UMB). Подозреваю, что весь остальной код, включая код 16-битный драйверов и даже код BIOS мог работать не замечая, что находится в защищённом режиме из-за того, что EMM386 настраивал память V86 на эмуляцию адресного пространства реального режима. А поскольку из опыта программирования под Win95 я точно знаю, что даже в её ядре можно было свободно обращаться к портам, то так могло быть и с EMM386. Т.е., сидя в Ring0, EMM386 не ограничивал обращение к аппаратуре, что позволяло драйверам работать. А значит вся каша в прерываниях крутилась уже внутри защищённого режима и никак EMM386 не мешала.

Нет нигде реалистичной спецификации на то, что может оказаться внутри int21.

Есть неоспоримый факт: при наличии емм386 или qdpmi - он выполнит его в в86. Без всяких но и если. С этим вы согласны?

Да даже штатное: ну представь, юзер с помощью int21 читает файл, там получается ошибка диска, выводится abort/retry/fail

А это как и с хаймемом: вы снова попались на невалидном примере. :) Этот кейс тоже предусмотрен, ведь фатальная ошибка диска вызывает прерывание какое-то, кажется 24h. Его обработчик - а, в данном случае, им и будет являться сам экстендер - обработает ввод пользователя как ему надо.

А значит, там должен быть полноценный самодостаточный реальный режим.

Задайтесь вопросом: как эти экстендеры под виндой95 работали? Уж там-то они точно в риалмод не переходили ни коим боком. Да и сама винда, будучи экстендером, тем не менее выполняла весь риалмодовый код без перехода в риалмод.

Даже в свое время мсдос 6.22 (1994 год) отставал от появившихся в тот же год net и freebsd

Ну смотря в чём. :) Под ДОС очень много совта было в те годы. Юниксы и рядом не валялись по кол-ву всякого «домашнего» совта. А то, что там, типа, многозадачность - ну кого это тогда волновало. :)

Я не знаю подробностей, но могу предположить, что ядро DOS и EMM386 умели общаться

ЕМНИП даже нет - не нужно им это было. УМБ можно было получить и драйвером PCIUMB - без защ режима и без емм386.

умели общаться, т.к. EMM386 был драйвером DOS,

Факт его бытия драйвером, использовался виндой при старте. Через иоцтлки винда говорила емму отдать ей карту памяти и позволить стартовать из риалмода. Этот протокол назывался GEMMIS. Ещё, еммом пользовался хаймем, когда переходил на использование инт15 (его емм и предоставлял). Так что я согласен с вами, что ДОС отлично работал и без знания о том, под ЕММом он, или сам по себе. Да и биос тоже. И только хаймем и винда имели небольшие протоколы для работы с емм.

Я не знаю подробностей, но могу предположить, что ядро DOS и EMM386 умели общаться, т.к. EMM386 был драйвером DOS,

Да, я про это выше писал, и именно поэтому для стороннего экстендера это не вариант. Экстендер только может пользоваться апи уже загруженного emm386 если он есть.

А значит вся каша в прерываниях крутилась уже внутри защищённого режима и никак EMM386 не мешала.

А ещё потому что emm386 не нужно планировать как оно будет выгружаться из памяти.

Задайтесь вопросом: как эти экстендеры под виндой95 работали?

Так же как и под emm386.

Ещё раз повторю: если в системе обнаружен гипервизор защищённого режима уровня ОС - работа идёт через него с V86 режимом, сделанным этим гипервизором. Если его нет - то ставить свой гипервизор затея неразумная, потому что разработчики ОС про него не знают и будут баги, поэтому делается всё через переключение в реальный режим.

Так что я согласен с вами, что ДОС отлично работал и без знания о том, под ЕММом он, или сам по себе. Да и биос тоже. И только хаймем и винда имели небольшие протоколы для работы с емм.

Есть некоторый нюанс во всем этом в том, что EMS-память появилась до emm386, емнип, может даже до процессора 386, был консорциум из Lotus (сейчас об этой компании все забыли), Intel и Microsoft, который выпустил спецификации такой памяти с API для работы окон памяти в верхнем пространстве. Сама память предоставлялась аппаратно отдельными платами.

Так что думаю, что MS-DOS начиная с примерно 3-й, максимум 4-й версии, писалась с оглядкой на EMS.

Потом, в 80386 появилась возможность софтово эмулировать EMS-платы с помощью драйвера emm386. Который MS кажется позаимствовала у Quarterdeck с их QEMM-драйверами, но это отдельная история. qemm, кстати, иногда вместо emm386 использовался, в нем вроде больше было фич каких-то, впрочем уже плохо помню.

P.S. Сейчас погуглил, все-таки первые публичные спецификации EMS появились не до 80386, но можно сказать, что одновременно с ним в 1985-м году, в теже годы выпускались платы расширения с набортной памятью до 4 Мб. Предназначалось исходно это все для 8086 и 80286-х компьютеров. Драйверы emm появились уже где-то в 1987-м году.

Да, я про это выше писал, и именно поэтому для стороннего экстендера это не вариант. Экстендер только может пользоваться апи уже загруженного emm386 если он есть.

Ну не совсем так. Экстендеры не работали напрямую с емм - они юзали VCPI. Этот протокол позволял им выполняться в ринг-0 и настраивать память как они того хотят. Чисто теоретически, в этом случае они могли бы и в риалмод уходить, только вот зачем? Если они не из-под него даже стартовали при таком сетапе. Боюсь, без взгляда в исходники экстендеров (коих, к счастью, дофига) мы не придём к согласию, какой же режим они использовали при наличии у них VCPI (под виндой VCPI уже не было).

Наличие VCPI = есть уже установленный гипервизор (emm386 или винда). Он сам поддерживает v86 и экстендеру нет причин от него отказываться.

Так что думаю, что MS-DOS начиная с примерно 3-й, максимум 4-й версии, писалась с оглядкой на EMS.

Так и есть: про EMS он знал. Про емм386 - не особо.

в нем вроде больше было фич каких-то, впрочем уже плохо помню.

Он намного больше УМБшек давал, так как ухитрялся отсвапливать страницы биоса. Он их возвращал назад только когда кто-то дёргал соотв прерывание. qemm была классная штука. :) Было 640Кб, а с ним - аж целый мегабайт!

Наличие VCPI = есть уже установленный гипервизор (emm386 или винда). Он сам поддерживает v86

VCPI разве его поддерживает? Хмм… глянул исходник dos32a - да, поддерживает. :) Ну тогда действительно возможен ваш вариант.

EMS-память появилась до emm386, емнип, может даже до процессора 386

На XT уже была. Именно чисто аппаратная реализация.

консорциум из Lotus (сейчас об этой компании все забыли)

Программа Lotus 1-2-3, Excel тех времён. Всё затевалось ради него. 640 Kb был минимум, на котором он вообще запускался. EMS нужен был, чтобы что-то серьёзное можно было делать. Всё остальное уже дополнение.

А разве можно из protected mode вернуться обратно в real mode без перезагрузки?

А разве можно из protected mode вернуться обратно в real mode без перезагрузки?

Однозначно. Проблема была на 286, но и там, со временем, появились ворк-эраунды. Учитывая то, что в86 там не было отродясь, а вот экстендеры - уже были, можно предположить, что они использовали loadall286 в качестве ворк-эраунда.

А разве можно из protected mode вернуться обратно в real mode без перезагрузки?

Перезагрузка не всегда видимая глазом. :) На той же двойке официальный путь был именно перезагрузка процессора, с подготовкой памяти так, чтобы после перезагрузки запустился не BIOS, а нужный код, который сделает всё, что надо в реальном режиме.

чтобы после перезагрузки запустился не BIOS, а нужный код

Если я правильно понимаю, то всё было не совсем так. Нельзя изменить адрес старта проца - он фиксирован и документирован. Но некоторые вендоры биоса пошли навстречу юзерам, и добавили какой-то хук, который и можно было задействовать. В общем, если я ничего не путаю - до появления loadall286, нормальных ворк-эраундов не было, и всё оставалось на милости вендора биоса. Конкретно как долго такая вакханалия продолжалась - неохота копать. :)

Нельзя изменить адрес старта проца - он фиксирован и документирован.

Ну да, это при содействии BIOS, но это «не некоторые вендоры». Это официальный способ, поддерживаемый всеми.

«Для обеспечения возврата в реальный режим после сброса по адресу, записанному в области данных BIOS 0040h:0067h можно использовать байты 5 и 0Ah.» https://frolov-lib.ru/books/bsp.old/v06/ch2.htm

Ага, спасибо за инфу! Вот как раз запись этих «5 или 0А» в кмос-память у меня и отложились как нечто вендор-специфичное. А запись адреса возврата в 0040h:0067h - как «некий хук». Сами понимаете, что запись в кмос, только ради возврата из прот моды - это такой себе костыль. Хотя, ещё покопавшись, нашёл, что более поздние биосы уже не требовали записи в кмос, а использовали магическое значение 1234h в 0040h:0072h для этой же цели. В общем, некий кавардак явно имел место быть.

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

Или это теряние прерываний надо было отдельно как-то подкостыливать.

А вот как раз по ссылке выше Фроловы пишут, что если в кмос записать 5, то будет сброс контроллера прерываний. А если 0ха то не будет. Мож вы 5 записыали, вот он их и терял? Правда тогда приходится предполагать, что Фролов ошибается, рекомендуя именно 5 и записывать, дабы автоматом базу вернуть в стандартное состояние. А ещё есть вариант, что вы не маскировали прерывания на момент сброса? Интересно, у вас старый код сохранился? :) Я полагаю, там что-то простое должно быть. Сам я на 286х не кодил, так что конкретно с этим моментом не сталкивался. Но выглядит так, будто бы потерять прерывание можно только в результате сброса контроллера (если оно уже было активно на этот момент), либо забыв их вовремя замаскать на проце перед подачей ресета.

Я ничего в кмос не записывал, подробностей не помню, видимо способ с 1234.

Ну то есть маскали прерывания и руками возвращали базу на место, а потом давали ресет? И какие-то прерывания после этого больше никогда не шли?

Не «какие-то», а те которые пришли в неудачное время. Возможно, те которые уже пришли на проц, но про был с cli и не принимал их, а потом ушёл в ребут, или те, которые пришли во время самого ребута, он же не мгновенный - отличить первое от второго програмно невозможно.

Сами понимаете, что запись в кмос, только ради возврата из прот моды - это такой себе костыль.

Там вообще всё через костыли работало. Включая поиски недокументированных возможностей.

Возврат в реальный режим на двойках через triple fault https://www.transl-gunsmoker.ru/2009/11/redux.html

Syscall на тройках через invalid instruction https://www.transl-gunsmoker.ru/2009/11/blog-post.html

отличить первое от второго програмно невозможно.

Да оно и не нужно если прерывания в обоих случаях запрещены. Ведь если вы под CLI стоите, то прерывание не может пропасть. Вы можете сделать ресет проца, но контроллер прерываний-то об этом даже не узнает (если не писать 5ку в кмос). Соответственно, если всё верно реализовано, прерывания должны дождаться STI, что бы между этими событиями ни происходило. Кроме, возможно, сброса контроллера прерываний. Тут надо спеку смотреть, но, ЕМНИП, там нет прям какого-то выделенного сброса. Я думаю, биос просто сам маску дефолтную ставит, потом базу выставляет на дефолтную, и весь сброс. Я предполагаю, что вы CLI делали как-то поздновато. Прерывание успевало проскочить, когда уже обработчики защ режима все деинициализированы.

Кстати… а вот такой вопрос: если у вас экстендер использует риалмод, то как же он обеспечит обработку в защ режиме тех прерываний, которые пришли пока мы были в реалмоде? Это ж, поди, работать может только если в риалмоде вообще прерывания не разрешать. А если кто вдруг разрешил - ну всё, экстендер уже не поймает прерывание из риалмода. А под экстендером ведь кто-то может попробовать протмодовые драйвера запустить - они должны ловить все прерывания, а не «некоторые». Выходит, схема с использованием риалмода всё же не жизнеспособна?

Syscall на тройках через invalid instruction

Так вроде ж HLT для этого был, но прикольно. :)

hlt не для этого. Она останавливает процессор до получения прерывания. Самым быстрым способом завесить Win95 был com-файл с двумя инструкциями cli и hlt. Даже их шестнадцатеричные коды помнили наизусть. :)

не, она для этого как раз. :) Это она в риалмоде ждёт прерывания. А в в86 её переиспользовали в сисколл: там она сразу кидает исключение, и ничего не ждёт. По этому и удивительно, что они использовали УД вместо этого.