VCPI, DPMI, V86 a další
-=-=-=-=-=-=-=-=-=-=-=-=-
All parts should go together without forcing. You must remember that
the parts you are reassembling were disassembled by you. Therefore,
if you can't get them together again, there must be a reason. By all
means, do not use a hammer.
-- IBM maintenance manual, 1925
Přesto, že strašáci jako EMS, XMS, UMB, HMA atd zmizeli, situace
není až tak růžová. Microsoft s Intelem nám přichytali další.
Protože DOS o protected módu neví, nejpřirozenější způsob jak
pod ním provádět protectedmódový program je k němu přidat nějaký
zavaděč, který se napřed postará o nastolení protected módu.
To samo o sobě znamená vyplnění několika tabulek, vypnutí A20 gate
a přepnutí procesoru. Není to nic strašného.
Průšvih ale je, že DOS i BIOS je pouze 16ti bitový a v 32bitovém
protectedmódovém prostředí prostě nepoběží. Proto by takový program
už nemohl ani na disk. Intelové kvůli tomu udělali režim jménem
V86. To je režim procesoru, kdy se procesor tváří, jako kdyby byl
v normálním (reálném) režimu, ale přesto je v protected módu. Tedy
real modový program (DOS a BIOS) běží, ale program zprostředkující
protected mód (v tomto případě to tedy není systém) nad nimi má
stejnou kontrolu, jako nad normálním procesem v protected módu
dokonce včetně virtuální paměti. Tento režim například bežně
používají i programy jako EMM386, nebo QEMM pro emulaci okénka
do EMS. Nevýhodou tohoto režimu je, že ne všechny instrukce procesor
zvládá sám a některé se musí emulovat (podobně jako koprocesor
na 286). Tyto instrukce pak běží samozřejmě pomalu. Mezi ně patří
většina instrukcí, které jsou normálně privilegované a protected
módovy program si je nemůže dovolit - například cli a sti. Proto
16ti bitové programy pod V86 jsou pomalejší a navíc v emulaci mohou
být chyby. Pro většinu věcí to ale stačí.
Musí se ale emulovat i interrupty a proto jsou systémová volání
pracující hlavně s interrupty docela pomalá. Je také nutné data pro
ně připravit do nějakého transfer bufferu, aby náhodou nebyly mimo
dolních 640 KB. Proto přístup k disku pod protected módem hlavně
v případě, že přistupujete po malých kouscích je výrazně pomalejší.
32 bitový přístup k disku pod Windows dělá přesně to, že nahradí
DOSová volání pro práci s diskem 32 bitovým kódem a tak se ušetří
několik přechodu mezi protected a V86 módem při přístupu k disku
(volá se jenom BIOS). Nejedná se tedy o opravdový 32 bitový přístup
(že by se IDE řadič krmil 32 bitovými čísly - což je také možné.
V případě, že toto všechno vyřešíte, pořád není vyhráno.
Privilegovaný program řídící protected mód musí být totiž pouze
jeden. Jak jsem už říkal, EMM386 a Qemm tento mód využívají a proto
váš program se pod nimi proste nespustí. Při pokusu o přechod
do protected modu zkolabuje. K tomu vzniklo rozšíření VCPI.
V případě, že je VCPI server v paměti, nepoužijete standardní kód
pro inicializaci protected módu, ale požádáte VCPI server, aby vám
předal řízení. Ten to udělá a vy tak získáte kontrolu. Nakonec ji
zase předáte zpátky.
Aby toho ale nebylo málo, jednou se Bill špatně vyspal
a vymyslel Windows. Ty jsou také od verze x.y v protected módu, ale
VCPI nepodporujou. Ztratily by totiž možnost provádět multitásking
v případě, že předají řízení. Proto byl vytvořen nový standard
jménem DPMI. DPMI znamená DOS protected mode interface. To DOS je
zcela zcestné, protože z DOSem nemá nic společného. Jinak je ale
název docela vpořádku.
Jedná se o jakýsi ovladač, který na daném interruptu (podobně
jako třeba ovladač myši) zpřístupňuje nejběžnější věci, které
protected módový program dělá (přepni do proteted módu, zavolej
realmodový interrupt, práce s virtuální pamětí atd...)
32 bitový program tedy pak nepotřebuje svůj vlastní kód pro
inicializaci protected módu, V86 apod. Prostě a jednoduše volá
DPMI. Aby to ale nebylo tak snadné, DPMI bylo navrženo pro 286,
která už měla jakýsi protected mód, ale tak zvoraný, že ho stejně
nikdo nepoužíval. Díky tomu má DPMI mnoho omezení. Navíc DPMI
neběží na všech počítačích a proto program stejně musí mít i jiné
cesty k inicializaci. Existuje několik verzí DPMI a díky velké
komplikovanosti standardu jsou skoro všechny implementace nějak
zbugované.
Pokud ale běží zrovna dobrý DPMI server, máte lineární paměť,
možnost mapovat si co chcete, volat realmodové interrupty a další
věci, což většinou stačí k životu. Jedna z největších komplikací je
pouze naprosto zbytečné omezení na velikost zásobníku (zásobník se
musí určit na začátku). Normálně (v Linuxu apod.) to vypadá trochu
jinak. Zásobník je na konci adresovatelného prostroru, zatímco
halda na začátku a rostou tedy proti sobě. Paměť se procesru předá
až v případě, že k ní poprvé přistoupí, proto program nepotřebuje
na začátku několik GB paměti. Program má potom vpodstatě neomezený
zásobník a haldu.
DPMI tedy není nikterak dobrý standard, ale jde používat.
Protože ho mají v API Windowsy i OS/2 asi se jen tak něčeho lepšího
v Billových a podobných systémech nedočkáme.
výheň