Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 32
Так получилось что никогда не программировал под DOS/4GW, но играл как и все. Можете рассказать подробнее и с примерами как это выглядело со стороны программы?
На Си или на асме? На Си это было прозрачно совершенно. Хотите мегабайт для массива? Просто выделяете этот мегабайт. Компилятор Watcom всё остальное делал сам.
А вот так на Watcom делались вставки на асме в 32-битном режиме:
pragma aux putscreen parm[]=\
"mov esi,dpt"\
"mov ecx,16000"\
"mov eax,ecx"\
"mov edi,0xa0000"\
"rep movsd"\
modify [esi edi ecx eax];
Я на Watcom написал аналог DooM.
Посмотрите, там есть все настройки компилятора.
Да никак. У вас просто было 32-битное адресное пространство без всего этого геморроя со страницами.
Так вся фишка dos4gw (во всяком случае, при использовании wacom c с дефолтными настройками) – что вам dos4gw прямо на старте программы проц переводит в защищённый режим и делает плоское адресное пространство (с известными адресами видеопамяти и т.п.). Вы просто работаете на всём готовом (и модель памяти – "самая маленькая", cs/ds/es/ss назначены на одно и то же и не трогаются никогда).
В простейшем случае программа просто писалась с расчётом на 32-битность и плоскую модель, собиралась Watcom C(++), компоновщик которого сам ваш код компоновал в формат LE (OS/2 Linear Executable), затем добавлял к нему DOS MZ заголовок и сам DOS/4GW как DOS stub. При запуске получившегося ехе первым получал управление DOS/4GW (т.к. DOS не понимал формат LE и видел только MZ часть), который, как и описано в статье, искал уже работающий DPMI-сервер (через прерывание INT 2F, закреплённое за DPMI), при отсутствии оного сам «вешался» на это прерывание, а дальше через функцию того же INT 2F (обрабатываемую либо самим DOS/4GW, либо «чужим» DPMI-сервером) переходил в защищённый режим, через функции INT 31 (DPMI API уже в 32-битном режиме, DPMI-сервер и его должен обрабатывать) выделял память под пользовательскую программу, загружал её туда (разбирая уже LE-часть) и в конце концов «прыгал» на пользовательскую точку входа, указанную в LE-заголовке.
Другая часть «магии» Watcom находилась в его стандартной библиотеке, которая «заворачивала» работу с файлами/консолью в вызовы DOS через функции всё того же INT 31, выделяла/освобождала память опять же через INT 31 итд.
Если программе не требовалось что-нибудь низкоуровневое вроде установки обработчика прерывания, прямого доступа к видеобуферу и подобного, она выглядела как самый обычный С/С++. Для низкоуровневых же вещей требовалось уже вручную вызывать всё тот же INT 31.
Как-то так.
И этот dos/4gw стаб можно было тупо оторвать, оставив остальное, положить рядом отдельностоящий dos4gw.exe, положить ему конфиг (.ini кажется), а в конфиге прописать свап-файл - и гонять в игры, которым не хватало установленной физической памяти.
Для включения виртуальной памяти достаточно было задать переменную среды SET DOS4GVM=1
Но, тут была проблема - если в игре был звук на саундбластере, то через некоторое время она крешилась. Реально поиграть можно было только без звука.
И вот какой парадокс - спасал Windows 95, именно 95, в нём была лучшая поддержка DOS/4GW, в Windows 98 такой уже не было.
То есть я хотел поиграть в свою любимую игру Blood, а она требовала 16 МБ, а у меня было всего 8 МБ, я просто запускал её под Windows 95.
И всё прекрасно работало и не крешилось на звуке. Только частый своп иногда притормаживал игру.
Интересно, как расширитель определял, что запущенная именно игра. Или же программы тоже шли хорошо.
В смысле, именно игра? А какая разница с не игрой?
По тексту кажется, что приоритет был на игры:
нам достаточно было устранить их один раз и сразу для всех игр. С другой стороны, если проблему нельзя было устранить, это бы сломало множество игр.
Чудесным образом большинство игр просто работало, несмотря на то, что они запускались не под тем DPMI-сервером, для которого разрабатывались изначально. Иногда возникали проблемы с отдельными играми. Самыми частыми оказывались проблемы с играми...
Интересно, а был вообще какой-нибудь более-менее популярный софт под DOS/4GW? В 90-е уже все под Windows переползали, чтобы была потребность в защищенном режиме, но именно под ДОС - это что-то специфическое должно быть...
Вряд ли он был. Дело в том, что этот софт не требовал выжимать от аппаратуры всё, а потому гораздо лучше его писать с использованием Windows API. А вот игры требовали максимума отдачи от оборудования (в Windows первые Direct-X были кривыми и тормознутыми по сравнению с прямой работой с аппаратурой, да и от COM-модели разработчиков игр тошнило), потому даже в 1997 тот же Duke Nukem 3D шёл под MS-DOS.
Duke Nukem 3D это начало 96-го
игра -- одногодка первого Quake
FoxProX работал под DOS4/GW.
Пара ссылок по теме - не единым DOS4/GW, не зря же в статье написано "видел много баннеров расширителей DOS "
386Max и иже с ним
http://www.sudleyplace.com/
https://github.com/sudleyplace/
Хвастались, что оно Windows 3.1x из под себя могло запустить, т.е. было совместимо максимально.
Другие, например HX
https://github.com/Baron-von-Riedesel?tab=repositories
К слову, полную спеку DPMI как всегда зажали, породив кучу almost works.
Под Clipper 5, насколько помню, такие расширения были
Игры же.
Игры - это само собой, я имел в виду - для чего-то помимо игр
Числяк. Ну в смысле когда надо много считать, а данные не помещаются в 64k (а использование указателей вида сегмент:смещение создаёт лишние тормоза). Хотя этот софт трудно назвать популярным, это для единиц)
Ну и довольно долго винду недолюбливали всё-таки. Когда ресурсов у компа не так много – не хочется тратить их зазря.
Просмотрщик картинок Sea.
В те времена, видев на экране надпись DOS/4GW я знал, что игра будет хорошей, даже не понимая, что это и зачем. Вот такие забавные ассоциации у меня)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как популярность DOS/4GW помогла играм в Windows 95