Divny clanek p. Zajicka v News on 'Net (long)

[Petr Balas]

Dovolim si par poznamek:

"Milan Kerslager" <milan.kerslager na spsselib.hiedu.cz> wrote in message
news:Pine.LNX.4.10.10008142016060.5425-100000 na pluto.spsselib.hiedu.cz...
> Dobry den,
>
> dost me mrzi pristup p. Zajicka k problemum, kterym nerozumi, takze jsem
> okometoval jeho zmateny clanek, ktery vysel 8. srpna v News on 'Net
> (http://www.bajt.cz/).
......
> Zminka o "neohrozenosti" ma na mysli asi to, ze v chranenem rezimu
> (protected mode, 32 bitovy rezim procesoru i386 a kompatibilnim) lze pamet
> chranit, v 16 bitovem rezimu (real mode, realny rezim) to nelze. 16 bitove
> instrukce tedy mohou psat "kam chteji" (a tak vznika pad systemu). V
> chranenem rezimu je vsak mozne vyuzit tzv. virtualniho rezimu x86, kdy lze
> vymezit oddeleny usek pameti, ktery bude 16 bitove uloze "prideleny".
> Nedokonale (mozna, ze pise zadne) vyuziti tohoto mechanismu vede k tomu,
> ze 16 bit. aplikace v M$ prostredi muze "sundat" cely system. Funkcni
> vyuziti nalezneme u OS/2, kde 16. bit. aplikace neohrozi jadro systemu,
> ale sunda jen blok pameti, kde bezi (vcetne "sve" kopie 16 bit. jadra OS).
> Takovychto chranenych useku muze byt (i v OS/2) vice a mohou byt naprosto
> nezavisle (to je vsak narocne na RAM pro duplikace 16. bit jadra systemu a
> dalsich datovych struktur v pameti).

Obdobne jako OS/2 se chova i Windows NT. Naproti tomu ve Win9x
to s ochranou poameti nevypada moc dobre. Dva Win9x problemy:
1) 16bit aplikace maji sdileny zacatek pameti a ten je kriticky.
   zkuste z DOS okna "debug" a v nem "f 0-7FFF 13" :-)
   nevim (a jsem liny vyzkouset) zda se to tyka i 32bit aplikaci
2) 32bit aplikace maji sdileny prostor 2G-3G kam se mapuji vsechny
   mapovane soubory, DLLka a tak dale. Vhodnym zasahem lze opet
   sestrelit system.

> Linux je plne 32 bitovy, prepnuti do realneho rezimu nepovoli a 16 bitove
> aplikace *musi* vyuzivat VMx86 (napr. DosEmu).

I kdyz pouzijete "virtualni" 16bit kod, tak pokud bude blbe namapovana
kriticka pamet (t.j. bude volne dostupna), tak jste v <censored>.


> Knihovny jsou v Unixovych systemech cislovany tremi cisly (napr.
> glibc-2.1.3 v RH 6.2). Nejnizsi je tzv. patchlevel a jeho zmena oznacuje
> opravu, ktera zachovava zpetnou binarni kompatibilitu (program linkovany
> proti 2.1.0 bude fungovat i proti 2.1.30). Prostredni je tzv. minor
> number, binarni kompatibilita neexistuje, program je potreba znovu
> prelinkovat (neni treba jej prelozit). Nejvyssi cislo je major number,
> meni se nejmene a vyjadruje generaci (tj. napr. velke zmeny filozofie
> knihovny, zmenu API [tj. zmena volani funkci, jejich nazvu, vyznamu a
> parametru]).
>
> Na major verzi se dela symbolicka linka (napr libc.so.6 -> libc-2.1.3.so),
> ktera oznazuje "default". O zavadeni dynamickych knihoven pri startu
> programu se stara dynamicky zavadec (dynamic loader, ld.so). Tim je
> zajistena centralni sprava a tak i moznost sdileni knihoven vice programy.
> Normalne loader respektuje symbolickou linku, jeho chovani lze vsak zmenit
> (tzv. preload knihovny, muze dojit k predefinovani, resp. zmene chovani
> "normalni" knihovni funkce, nebo se vyuzije zavedeni odlisne knihovny). Z
> toho vyplyva, ze v systemu lze mit vsechny verze knihoven a dokonce je lze
> uchovavat na libovolnych mistech v systemu.

Toto se wokna snazi resit dvemi zpusoby (funguje jen u novych windows):
1) DLLka lze nainstalovat k aplikaci a ne do systemu
2) Systemova DLLka jsou chranena - po jejich prepsani system navrati
   zpet puvodni verzi.
Jenom mi prijde, ze je to reseni dusledku a ne priciny :-(


> Zde je potreba si uvedomit, ze M$ si ulehcil praci a vyvoj ovladacu HW
> presunul do uzivatelskeho prostoru (user space).

Ehm a jste si jisty, ze vite o cem mluvite?

> Normalni programator
> nemuze bez detailni znalosti OS (u M$ predmetem obchodniho tajemstvi)
> napsat ovladac, ktery zapadne do jadra a nezpusobi katastrofu.

Informace nutne pro napsani ovladace HW jsou obsazeny v MSDN (chce to
alespon druhou uroven - stavalo to okolo 20kKc za rok). Dokumentace obcas
obsahuje chyby a priklady taky. Taky se najdou mista, kde je dokumentace
neuplna. A zdrojaky jadra aby clovek videl, co se kde deje by taky potesily
:-).

Jina situace je, kdyz chcete pdat neco slozitejsiho jako treba filesystem
nebo antivir - pak je dokumentace malo, ....

Zde ja ale IMHO casto chyba na strane vyrobce HW. Ti se snazi do
ovladacu zabudovat kazdou blbost. Okamzite me napadaji ovladace
k tiskarnam HP - verze pro WinNT4 typicky mu kdejakou blbost,
ale na siti casto vubec nejsou schopny tisknout. Za to bych zabijel.

> Pokud ovsem
> da tvurce OS programatorovi nadbytecne moznosti (napr. moznost zakazani
> preruseni, primy pristup k HW), pak lze takovy oladac snadno napsat.
> Bohuzel to povede k nestabilite systemu (ovladac HW pobezi s absolutnimi
> pravy a snadno shodi cely system).

Ovladac musi psat nekdo, kdo to umi. Jsou zarizeni, kde usermode program
staci. Ale jsou jine, kde rezie na prepnuti do spravneho kontextu a tak dale
je proste prilis velka. Zalezi na zarizeni.

> Ze je to nesystemove, vi i M$ a proto
> si u NT "osvojuje" ovladace (bud firma odevzda zdrojaky nebo si u NT se
> svym HW ani neskrtne a ztrati trh -> M$ usetri za platy programatoru).

A to jste zjistil kde? MS zacina vyzadovat CERTIFIKACI ovladacu, t.j.
firma ji posle ovladac, MS otestuje, ze ten ovladac neshodi pocitac,
pote jej elektronicky podepise a je to. Po zkusenostech s nekterymi
ovladaci se ji vubec nedivim.

Petr Balas (petr at petrbalas dot cz)