Ето как популярността на DOS/4GW помогна на игрите в средата на ОС Windows 98

В началото на 90-те години на миналия век най-популярният екстендер за DOS беше DOS/4GW. По време на разработването на Windows 95 прекарвах много време в работа по съвместимостта на игрите с MS-DOS, така че виждах много банери на екстендери за DOS и най-често това беше DOS/4GW.

Може да се запитате: „Как тези игри изобщо вървяха на Windows 95, ако бяха с екстендер за DOS? Дали екстендерът нямаше безуспешно да се опита да премине в защитен режим, защото Windows вече работеше в защитен режим?“.

Уловката се състои в това, че тези разширители (extenders) всъщност бяха две свързани помежду си програми. Едната се използваше като сървър в защитен режим, а другата беше клиентска библиотека в защитен режим.

В началото съществуваше Virtual Control Programme Interface (VCPI), който се поддържаше от мениджъри на паметта като EMM386. Тези мениджъри на разширената памет почти не използваха защитения режим: единственото нещо, за което се грижеха, беше достъпът до паметта над ограничението от 1 МВ, за да могат да създават таблици на страниците, за да картографират разширената памет в рамката на страницата на разширената памет, но не извършваха никаква друга виртуализация. MS-DOS работеше във виртуална машина с пълен достъп до хардуера, а интерфейсът VCPI позволяваше на приложението MS-DOS да каже: „Сега трябва да получа пълен контрол над системата„, при което VCPI отговаряше: „Разбира се, няма проблем!„.

Интерфейсът VCPI бързо загуби своята популярност, тъй като нито една операционна система в защитен режим (като Windows 3.0 в режим Advanced Mode) не би позволила на някоя програма да получи пълен контрол над системата. По същество тя би спряла старата операционна система, за да позволи на програма от MS-DOS да поеме контрола в качеството си на нова отделна платформа. Windows 3.0 въведе нов интерфейс, наречен DOS Protected Mode Interface (DPMI), който позволяваше на MS-DOS програмите да изискват изпълнение на своя код в защитен режим, но само в потребителския режим на операционната система. Драйверът за достъп до DPMI продължи да контролира режима на ядрото.

И така, нека се върнем към DOS/4GW. При стартиране екстендерът DOS/4GW търси работещ DPMI сървър. Ако не го открие, той се инсталира като DPMI-сървър. Но ако DPMI-сървърът вече бе стартиран, той позволяваше на този DPMI-сървър да си остане стартиран.

Играта комуникираше само с тази част на библиотеката, която се отнася до DPMI клиента, използван за преход към 32-битов режим, за разпределението на паметта и за изпълнението на всички 32-битови задачи, които бяха необходими на съответната 32-битова игра.

С други думи, получаваше се следната блок схема:

И двата DPMI сървъра, Windows и DOS/4GW, реализират DPMI интерфейса, така че DPMI клиентът на DOS/4GW използва стандартните DPMI извиквания за комуникация с двата сървъра.

Това беше чудесно за съвместимостта на приложенията, тъй като ако имаше проблем с комуникацията на DOS/4GW клиентът с DOS/4GW сървъра, всичко, което трябваше да направим, беше да го отстраним еднократно и за всички игри наведнъж. От друга страна, ако проблемът не можеше да бъде отстранен, той щеше да срине много игри.

Голям риск, голяма печалба.

Като по чудо повечето игри просто работеха, въпреки че работеха под грешния DPMI сървър, за който бяха първоначално разработени. От време на време имаше проблеми с отделните игри. Най-често срещани бяха проблемите с игри, които приемаха, че цялата памет е физическа, и игри, които приемаха, че флагът за прекъсване не е виртуализиран, но в по-голямата си част всичко работеше достатъчно добре, така че останалите проблеми можеха да се решат като специфични за приложението грешки.