Ji°φ Peterka

╚ßst 5.: OvladaΦe sφ¥ov²ch karet - nositelΘ vzßjemnΘ spoluprßce

Po₧adavek nezßvislosti zßkaznφka na konkrΘtnφm dodavateli, kter² je jednφm ze zßkladnφch pilφ°∙ vÜech otev°en²ch (open) °eÜenφ, je v souΦasnΘ dob∞ snad nejvφce napln∞n v oblasti nabφdky osobnφch poΦφtaΦ∙ PC. Chcete-li si takov² poΦφtaΦ koupit, m∙₧ete si vybφrat z nabφdek mnoha a mnoha v²robc∙, a rozhodovat se podle ceny, dodacφch a zßruΦnφch podmφnek, celkovΘho renomΘ v²robce resp. prodejce apod. P°itom mßte rozumnou zßruku, ₧e vßmi zvolen² poΦφtaΦ bude odpovφdat standardu poΦφtaΦ∙ PC - ₧e na n∞m bude mo₧nΘ provozovat vÜechny b∞₧nΘ programy pro osobnφ poΦφtaΦe, a takΘ ₧e si k n∞mu budete moci p°ikupovat nejr∙zn∞jÜφ hardwarovΘ dopl≥ky od kterΘhokoli v²robce.

Pokud budete chtφt zapojit sv∙j osobnφ poΦφtaΦ standardu IBM PC do lokßlnφ poΦφtaΦovΘ sφt∞ (nap°φklad do sφt∞ typu Ethernet), budete si muset p°ikoupit jeÜt∞ nezbytn² sφ¥ov² hardware, ve form∞ tzv. sφ¥ovΘ karty. DneÜnφ poΦφtaΦe PC jsou do znaΦnΘ mφry modulßrnφ, a lze je snadno rozÜi°ovat pomocφ karet Φi desek, kterΘ se instalujφ do voln²ch zßsuvn²ch pozic (neboli tzv. slot∙) na matiΦnφ desce (tzv. motherboardu). To je z°ejm∞ hlavnφ d∙vod, proΦ jeÜt∞ i dnes, v dob∞ vÜeobecnΘho nßstupu lokßlnφch sφtφ, nenφ pot°ebn² sφ¥ov² hardware standardnφ souΦßstφ poΦφtaΦ∙ PC, ale pouze voliteln²m dopl≥kem, °eÜen²m nejΦast∞ji prßv∞ formou sφ¥ovΘ karty.

Nabφdka sφ¥ov²ch karet pro poΦφtaΦe PC je dnes takΘ velmi bohatß, a pokr²vß znaΦn∞ ÜirokΘ spektrum - od nejlacin∞jÜφch "bezejmenn²ch" (no-name) karet a₧ po nejdra₧Üφ znaΦkovΘ karty od renomovan²ch v²robc∙. JednotlivΘ karty se p°itom mohou dosti v²razn∞ liÜit, pokud jde o jejich schopnosti i konkrΘtnφ zp∙sob ovlßdßnφ.

Podobn∞ je tomu i s nabφdkou nejr∙zn∞jÜφho sφ¥ovΘho softwaru - takΘ zde se potencißlnφm zßkaznφk∙m nabφzφ velk² v²b∞r sφ¥ov²ch operaΦnφch systΘm∙, sφ¥ov²ch utilit a mnoha dalÜφch program∙.

V tuto chvφli se ale neodbytn∞ vnucuje zcela zßsadnφ otßzka: "je mo₧nΘ libovoln∞ kombinovat sφ¥ovΘ karty a sφ¥ov² software"? Nebo jinak: "mohu se spolehnout, ₧e ten sφ¥ov² software, pro kter² se rozhodnu, dokß₧e spolupracovat s kteroukoli sφ¥ovou kartou, kterou si ke svΘmu poΦφtaΦi koupφm (nebo kterou ji₧ ve svΘm poΦφtaΦi mßm)"?

PokroΦilejÜφ u₧ivatelΘ si pak k tΘto zßkladnφ otßzce jist∞ p°idajφ i nßsledujφcφ dilema: "budu-li provozovat soub∞₧n∞ vφce ·loh, kterΘ pracujφ se sφtφ, dokß₧φ se o jedinou sφ¥ovou kartu rozumn∞ pod∞lit"?

Ka₧d² s ka₧d²m?

Cesta vzßjemnΘho p°izp∙sobenφ vÜech mo₧n²ch program∙ vÜem mo₧n²m sφ¥ov²m kartßm tedy nenφ sch∙dnß ji₧ z principu. O jejφ efektivnosti ani nemluv∞.

Mo₧nou alternativou by bylo omezit se jen na podporu menÜφho okruhu sφ¥ov²ch karet od "renomovan²ch" v²robc∙, a po₧adovat od nich zp∞tnou kompatibilitu nov∞ vyvφjen²ch karet s ji₧ existujφcφmi. To je ale znaΦn∞ diskriminujφcφ v∙Φi ostatnφm v²robc∙m, kte°φ by nesm∞li p°ichßzet s vlastnφm °eÜenφm, ale museli by se p°izp∙sobovat n∞kolika mßlo "vyvolen²m" °eÜenφm.

A₧ na holΘ ₧elezo?

To je na jednΘ stran∞ velmi v²hodnΘ, proto₧e p°i takovΘmto p°φstupu "a₧ na holΘ ₧elezo" m∙₧e sφ¥ov² software maximßln∞ vyu₧φt vÜech schopnostφ konkrΘtnφ sφ¥ovΘ karty. Na druhΘ stran∞ je ovÜem nutnΘ mφt na pam∞ti, ₧e zp∙sob ovlßdßnφ na ·rovni "holΘho ₧eleza" je pro ka₧dou sφ¥ovou kartu obecn∞ jin². D∙sledkem je pak nemo₧nost p°izp∙sobenφ stylem "ka₧d² s ka₧d²m", citovanß v p°edchozφm odstavci.

Krom∞ toho je ale t°eba si uv∞domit takΘ to, ₧e sφ¥ovΘ karty nejsou zdaleka jedin²m druhem hardwaru, kter² dneÜnφm poΦφtaΦ∙m zajiÜ¥uje p°φstup do poΦφtaΦov²ch sφtφ. Jsou pouze jeho p°eva₧ujφcφ formou, pou₧φvanou pro p°ipojovßnφ personßlnφch poΦφtaΦ∙ standardu IBM PC do lokßlnφch sφtφ, zatφmco nap°. v rozlehl²ch sφtφch se jednotlivΘ uzlovΘ poΦφtaΦe propojujφ pomocφ pevn²ch (ev. i komutovan²ch) telefonnφch okruh∙, radiov²ch Φi dru₧icov²ch spoj∙ apod., a tyto p°enosovΘ cesty se nejΦast∞ji p°ipojujφ p°es vhodnΘ p°izp∙sobovacφ prvky (zejmΘna modemy) na sΘriovß rozhranφ poΦφtaΦ∙. Tφm ale nenφ repertoßr mo₧n²ch zp∙sob∙ p°ipojenφ na sφ¥ jeÜt∞ zdaleka vyΦerpßn - nap°φklad p°enosnΘ poΦφtaΦe s oblibou vyu₧φvajφ ke svΘmu zapojovßnφ do sφtφ adaptΘry, p°ipojovanΘ k jejich paralelnφmu rozhranφ (paralelnφmu portu). JinΘ druhy poΦφtaΦ∙ zase majφ ekvivalent sφ¥ovΘ karty ji₧ zaintegrovßn na svΘ systΘmovΘ desce, nebo vy₧adujφ pou₧itφ sφ¥ov²ch karet specifickΘho druhu apod.

OvladaΦe musφ psßt v²robci hardwaru!

No a prßv∞ v definici tohoto rozhranφ je skryt dalÜφ zdroj problΘm∙: kdo mß p°φsluÜnß pravidla a konvence stanovit?

M∙₧e to samoz°ejm∞ b²t i v²robce sφ¥ovΘho hardwaru, ale v praxi takovßto rozhranφ stanovujφ tΘm∞° v²luΦn∞ tv∙rci sφ¥ov²ch program∙. Ti p°itom mohou navrhnout p°φsluÜnΘ rozhranφ tak, aby vychßzelo vst°φc pot°ebßm jednΘ konkrΘtnφ sφ¥ovΘ aplikace Φi jednoho konkrΘtnφho systΘmovΘho programu, kter² se sφtφ pracuje (nap°. sφ¥ovΘho operaΦnφho systΘmu), a v²robci sφ¥ov²ch karet (Φi jinΘho sφ¥ovΘho hardwaru) pak mohou ke sv²m produkt∙m p°idßvat ovladaΦe pro jednotlivΘ konkrΘtnφ aplikace. Tato strategie vÜak znovu narß₧φ na problΘm, kter² jsme ji₧ n∞kolikrßt citovali: v²robce sφ¥ovΘ karty nem∙₧e anticipovat pot°eby aplikacφ, kterΘ budou vytvo°eny teprve v budoucnu. Pot°ebnΘ ovladaΦe pro n∞ sice m∙₧e napsat a₧ dodateΦn∞, ale jejich nßslednß distribuce jednotliv²m zßkaznφk∙m nebude nikdy bezproblΘmovß (ani zcela zadarmo).

Univerzßlnφ rozhranφ k sφ¥ovΘmu hardwaru

Ve sv∞t∞ plnΘm institucφ, zab²vajφcφch se tvorbou a vydßvßnφm vÜelijak²ch standard∙ a norem, by bylo mo₧nΘ oΦekßvat, ₧e standard pro p°φsluÜnΘ rozhranφ vznikne prßv∞ touto cestou. Prav² opak je ale pravdou: vÜechna dnes pou₧φvanß rozhranφ pro p°φstup k sφ¥ovΘmu hardwaru vznikla jako vlastnφ (tzv. proprietßrnφ) °eÜenφ softwarov²ch firem, a teprve Φasem se z nich staly vÜeobecn∞ uznßvanΘ standardy. V tomto Φlßnku se podrobn∞ji zastavφme u t°ech z nich, kterΘ jsou v dneÜnφ dob∞ nejrozÜφ°en∞jÜφ:

• rozhranφ tzv. paketov²ch ovladaΦ∙ (packet drivers),
• rozhranφ tzv. NDIS ovladaΦ∙ (NDIS drivers).
• rozhranφ tzv. ODI ovladaΦ∙ (ODI drivers),

Sdφlenφ sφ¥ov²ch adaptΘr∙

V²Üe avizovan² problΘm pak nastßvß v okam₧iku, kdy jeden a tent²₧ sφ¥ov² hardware (jednu sφ¥ovou kartu) pot°ebuje sdφlet vφce takov²chto sestav protokol∙. Pokud by ka₧dß z nich "sahala" a₧ p°φmo na sφ¥ovou kartu, a chovala se p°itom tak, jako kdyby byla na poΦφtaΦi sama, skonΦilo by to zcela jist∞ naprost²m fiaskem.

Jakmile ale dojde k "oddßlenφ" jednotliv²ch sestav protokol∙ od sφ¥ovΘho hardwaru a pod n∞ se vlo₧φ vhodn² ovladaΦ, je mo₧nΘ tento ovladaΦ uzp∙sobit tak, aby dokßzal spolupracovat s vφce sestavami protokol∙, a rozd∞loval mezi n∞ veÜkerß p°ijφmanß data.

VÜechny nßmi zvolenΘ druhy ovladaΦ∙ tuto schopnost majφ, ale ka₧d² z nich ji implementuje pon∞kud odliÜn²m zp∙sobem, ze kterΘho pak vypl²vajφ i n∞kterΘ zajφmavΘ d∙sledky.

Rozhranφ paketov²ch ovladaΦ∙

Zajφmavß je i samotnß historie vzniku tohoto rozhranφ: jednou z ·pln∞ prvnφch implementacφ protokol∙ TCP/IP pro poΦφtaΦe IBM PC byl ·sp∞Ün² v²zkumn² projekt profesora Jerry Saltzera na znßmΘ Massachussets Institute of Technology, jeho₧ v²stupem byla i soustava program∙, nazvan²ch PC-IP. Tyto programy, implementujφcφ v∞tÜinu standardnφch aplikacφ TCP/IP, byly v roce 1985 uvoln∞ny (jako to voln∞ Üi°itelnΘ programy, tzv. freeware), a staly se zßkladem, na kter² zßhy navßzala °ada dalÜφch v²zkumn²ch projekt∙ i Φist∞ komerΦnφch aktivit.

Jednou z nich bylo i zalo₧enφ firmy FTP Software, Inc. (v lednu 1986), kterß si p°edsevzala pokraΦovat ve v²voji PC-IP na komerΦnφ bßzi, a uplatnit p°itom n∞kterΘ dalÜφ myÜlenky, kterΘ v rßmci projektu MIT ji₧ nebyly realizovßny. V²sledkem byl kvalitnφ a dodnes velmi ·sp∞Ün² komerΦnφ produkt PC/TCP, jeho₧ prvnφ verze se dostala na trh v dubnu 1986. Jednou z osobnostφ, kterΘ u firmy FTP Software uplatnily svΘ myÜlenky, byl John Romkey (kter² se jeÜt∞ jako student v²znamnou m∞rou podφlel na realizaci p∙vodnφho PC-IP na MIT). Takovouto myÜlenkou bylo i vytvo°enφ standardizovan²ch ovladaΦ∙ sφ¥ovΘho hardwaru, kterΘ John Romkey nazval paketov²mi ovladaΦi (packet drivers), a kterΘ firma FTP Software zaΦala ve sv²ch produktech pou₧φvat. Specifikace p°φsluÜnΘho rozhranφ (tj. rozhranφ mezi paketov²mi ovladaΦi a sestavami protokol∙ vyÜÜφch vrstev) vznikla na p°elomu let 1986 a 1987, a byla zßhy pln∞ zve°ejn∞na - aby se jφ v²robci mohli p°izp∙sobit, a ke sv²m sφ¥ov²m kartßm psßt nezbytnΘ paketovΘ ovladaΦe.

V²robc∙m ovÜem chvφli trvalo, ne₧ paketov²m ovladaΦ∙m "p°iÜli na chu¥". Mnohem d°φve si je oblφbili u₧ivatelΘ z akademick²ch kruh∙, kte°φ zaΦali psßt paketovΘ ovladaΦe pro nejr∙zn∞jÜφ ji₧ existujφcφ sφ¥ovΘ karty. Vzhledem k obvyklΘ praxi na univerzitßch v USA se tyto ovladaΦe staly voln∞ Üi°iteln²mi, a to dokonce i ve zdrojovΘm tvaru. ┌lohu hlavnφho koordinßtora p°itom na sebe vzala jedna z univerzit v USA, Clarkson University ve m∞st∞ Potsdam ve stßt∞ New York, u kterΘ se nejr∙zn∞jÜφ paketovΘ ovladaΦe postupn∞ shroma₧∩ovaly, a₧ jich zde vznikla velmi bohatß a dob°e udr₧ovanß zßsoba. Proto se takΘ o paketov²ch ovladaΦφch n∞kdy hovo°φ jako o "Clarkson packet drivers", a o jejich sbφrce jako o tzv. "Clarkson packet driver collection". Ta se samoz°ejm∞ stala takΘ hlavnφm referenΦnφm zdrojem pro volnΘ Üφ°enφ vÜech paketov²ch ovladaΦ∙.

V souΦasnΘ dob∞ ale ji₧ nemß Clarkson University s udr₧ovßnφm a Üφ°enφm tΘto sbφrky nic spoleΦnΘho. Stßle se o ni sice starß stejn² Φlov∞k, jako na univerzit∞ (pan Russell Nelson), ale nynφ ji₧ v rßmci firmy Crynwr Software. Proto se takΘ p°φsluÜnß sbφrka paketov²ch ovladaΦ∙ nynφ oznaΦuje jako "Crynwr packet driver collection".

PaketovΘ ovladaΦe byly a stßle jsou voln∞ Üi°itelnΘ programy (tzv. freeware). Lze je tedy zφskat bu∩ zcela zdarma (nap°φklad prost°ednictvφm sφt∞ Internet), nebo i b∞₧nou listovnφ poÜtou za mal² manipulaΦnφ poplatek (pokr²vajφcφ cenu poÜtovnΘho, magnetickΘho nosiΦe atd.). Formßln∞ tedy nejde o produkt, ke kterΘmu by byly poskytovßny dalÜφ podp∙rnΘ slu₧by, obvyklΘ u komerΦnφch produkt∙ - p°edevÜφm pak tzv. u₧ivatelsk² support, spoΦφvajφcφ p°edevÜφm v technickΘm poradenstvφ, odstra≥ovßnφ chyb, v²voji nov²ch verzφ atd. V praxi je ale sbφrka paketov²ch driver∙ dob°e udr₧ovanß na nezßvaznΘ a neformßlnφ bßzi, a p°φpadnΘ chyby jsou v nov²ch verzφch odstra≥ovßny (v listopadu 1993 se objevila ji₧ 11. verze sbφrky paketov²ch ovladaΦ∙ - Crynwr packet driver collection, Release 11.x)

Postoj v²robc∙ sφ¥ovΘho hardwaru k paketov²m ovladaΦ∙m nenφ jednotn². V∞tÜina z nich sice pφÜe ke sv²m produkt∙m i nezbytnΘ paketovΘ ovladaΦe, ale existujφ i takovφ v²robci, kte°φ tak neΦinφ (nejspφÜe kv∙li svΘmu nep°φliÜ kladnΘmu postoji v∙Φi voln∞ Üi°iteln²m program∙m bez u₧ivatelskΘho supportu). Na druhΘ stran∞ tv∙rci nejr∙zn∞jÜφho sφ¥ovΘho softwaru s paketov²mi ovladaΦi vesm∞s poΦφtajφ, a svΘ produkty vybavujφ schopnostφ pracovat s tφmto druhem ovladaΦ∙. Existujφ dokonce takovΘ produkty, kterΘ s niΦφm jin²m ne₧ s paketov²mi ovladaΦi nepoΦφtajφ. Jsou to p°edevÜφm nejr∙zn∞jÜφ voln∞ Üi°itelnΘ programy, pochßzejφcφ z akademickΘho prost°edφ.

Jak funguje paketov² ovladaΦ

Obr. 1: Paketov² ovladaΦ a RM ISO/OSI

Paketov² ovladaΦ je tedy program, kter² z jednΘ strany komunikuje se sφ¥ovou kartou, a z druhΘ strany s jednou nebo n∞kolika sestavami protokol∙ (protocol stacks), kterΘ implementujφ p°enosovΘ protokoly vyÜÜφch vrstev, poΦφnaje vrstvou sφ¥ovou - viz obrßzek 1.

Paketov² ovladaΦ je v₧dy jedin²m programem, kter² pracuje s danou sφ¥ovou kartou. Zde je tedy situace vcelku jednoduchß - sφ¥ovß karta p°edßvß veÜkerß p°ijatß data prßv∞ a pouze "svΘmu" paketovΘmu ovladaΦi (p°i souΦasnΘ existenci vφce sφ¥ov²ch karet v jednom poΦφtaΦi mß ka₧dß z nich nainstalovßn sv∙j vlastnφ paketov² ovladaΦ). Zp∙sob, jak²m paketov² ovladaΦ komunikuje se sφ¥ovou kartou, tedy nesk²tß ₧ßdnΘ principißlnφ problΘmy. Je samoz°ejm∞ specifick² pro dan² sφ¥ov² hardware (kartu), ale to je podstatnΘ (a hlavn∞ "viditelnΘ") pouze pro toho, kdo paketov² ovladaΦ pφÜe, a nikoli pro toho, kdo jej pou₧φvß.

Zajφmav∞jÜφ je spφÜe zp∙sob komunikace paketovΘho ovladaΦe sm∞rem "nahoru" - tedy sm∞rem k sestavßm protokol∙, kterΘ implementujφ p°enosovΘ protokoly vyÜÜφch vrstev (sφ¥ovou vrstvou poΦφnaje). Tento zp∙sob komunikace je v₧dy jednotn², a je dßn prßv∞ specifikacφ rozhranφ k paketovΘmu ovladaΦi, vytvo°enou firmou FTP Software.

VeÜkerß komunikace, iniciovanß protokoly vyÜÜφch vrstev, mß formu programovΘho p°eruÜenφ - jeho konkrΘtnφ Φφslo (od 60H do 7FH) se pro ka₧d² paketov² ovladaΦ stanovuje v okam₧iku jeho instalace. Paketov² ovladaΦ touto cestou (tj. prost°ednictvφm p°eruÜenφ) nabφzφ p°edem stanoven² repertoßr slu₧eb, popsan²ch v definici rozhranφ k paketov²m ovladaΦ∙m - nap°φklad slu₧eb pro odesφlßnφ jednotliv²ch datov²ch paket∙.

Zajφmav² je i zp∙sob komunikace mezi paketov²m ovladaΦem a protokoly vyÜÜφch vrstev v p°φpad∞ p°φjmu dat, kdy inicißtorem nutn∞ musφ b²t paketov² ovladaΦ. Zde platφ obecnΘ pravidlo, ₧e protokol vyÜÜφ vrstvy, kter² chce od paketovΘho ovladaΦe jakßkoli data p°ijφmat, se u n∞j musφ nejprve p°ihlßsit. Jako souΦßst svΘ "p°ihlßÜky" p°itom musφ zadat i vstupnφ bod do svΘ rutiny, kterß mß b²t p°i p°φjmu volßna. Kdy₧ potom paketov² ovladaΦ n∞jak² datov² paket skuteΦn∞ p°ijme, p°edß jej jeho skuteΦnΘmu adresßtovi tak, ₧e zavolß tuto jφm urΦenou rutinu. Pravidla rozhranφ k paketovΘmu ovladaΦi dokonce urΦujφ, ₧e tak Φinφ dvakrßt: poprvΘ volß p°φsluÜnou rutinu proto, aby tato zajistila vytvo°enφ dostateΦn∞ velkΘ vyrovnßvacφ pam∞ti (bufferu) pro p°φjem paketu. Paketov² ovladaΦ potΘ sßm zkopφruje datov² paket do tΘto vyrovnßvacφ pam∞ti, a druh²m volßnφm p°φsluÜnΘ rutiny o tom informuje p°φsluÜn² sφ¥ov² protokol.

R∙znΘ t°φdy paketov²ch ovladaΦ∙

Alternativou k tomuto p°φstupu paketov²ch ovladaΦ∙ by bylo ·plnΘ zakr²vßnφ veÜker²ch specifik pou₧φvan²ch p°enosov²ch cest p°ed vyÜÜφmi vrstvami (tuto strategii aplikujφ tzv. ODI ovladaΦe, viz dßle).

Sdφlenφ paketovΘho ovladaΦe

Pro funkΦnφ schopnosti paketov²ch ovladaΦ∙ je velmi podstatnΘ, jak²m zp∙sobem rozpoznßvajφ typ datov²ch paket∙ a jak konkrΘtn∞ postupujφ p°i jejich rozd∞lovßnφ mezi vÜechny potencißlnφ p°φjemce.

P°esn² algoritmus, podle kterΘho paketov² ovladaΦ postupuje, je sice pon∞kud komplikovan∞jÜφ, ale bez v∞tÜφ ·jmy na obecnosti lze °φci, ₧e p°φsluÜnΘ rozhodovßnφ se d∞je jen na ·rovni linkovΘ vrstvy. Jin²mi slovy: paketov² ovladaΦ se rozhoduje podle ·daj∙, obsa₧en²ch v hlaviΦce datovΘho rßmce linkovΘ vrstvy, ale ji₧ se nedφvß "dovnit°" paket∙, kterΘ jsou obsa₧eny v datovΘ Φßsti t∞chto rßmc∙ (konkrΘtnφmi typy datov²ch rßmc∙ linkovΘ vrstvy a rozpoznßvßnφm jejich obsahu v p°φpad∞ sφtφ typu Ethernet jsme se podrobn∞ji zab²vali v minulΘm dφlu tohoto volnΘho serißlu).

Z toho pak vypl²vß zßva₧n² d∙sledek: paketov² ovladaΦ nap°φklad dokß₧e odliÜit IP paket od IPX paketu (tj. paket, kter² pat°φ sφ¥ovΘmu protokolu IP z rodiny protokol∙ TCP/IP, odliÜφ od paketu, kter² pat°φ protokolu IPX ze soustavy protokol∙ IPX/SPX sφtφ Novell Netware). Co ale paketov² ovladaΦ ji₧ nedokß₧e odliÜit, jsou nap°φklad dva IP pakety, kterΘ pat°φ r∙zn²m instancφm protokolu IP. V praxi to tedy znamenß, ₧e p°i pou₧itφ paketovΘho ovladaΦe je mo₧nΘ soub∞₧n∞ provozovat vφce aplikacφ, ale tyto musφ pou₧φvat r∙znΘ p°enosovΘ protokoly na ·rovni sφ¥ovΘ vrstvy (nebo mohou sdφlet jednu sestavu p°enosov²ch protokol∙, a pot°ebnΘ rozd∞lovßnφ paket∙ mezi vφce potencißlnφch p°φjemc∙ si musφ zajistit vlastnφmi silami na vyÜÜφ ·rovni).

Uve∩me si konkrΘtnφ p°φklad: p°i pou₧itφ paketovΘho ovladaΦe m∙₧eme vedle sebe provozovat nap°φklad klientsk² shell sφt∞ Novell NetWare (kter² pracuje s pakety IPX), a n∞kterou z verzφ protokolu NFS pro MS DOS (nap°. PC-NFS, Beame&Whiteside NFS apod., kterΘ pou₧φvajφ IP pakety). Tφmto zp∙sobem pak m∙₧eme z jednoho poΦφtaΦe s MS DOSem zφskat souΦasn² a pln∞ transparentnφ p°φstup jak k soubor∙m na file serveru systΘmu Novell NetWare, tak i k soubor∙m na UnixovskΘm file serveru. To je zvlßÜt∞ v²hodnΘ v p°φpad∞, kdy pot°ebujeme jednoduch²m zp∙sobem kopφrovat soubory z jednoho file serveru na druh². Na pracovnφ stanici, kterß nßm tuto mo₧nost nabφzφ, si pak ale ji₧ nespustφme jin² program, kter² takΘ pou₧φvß sφ¥ov² protokol IP, a sßm si jej takΘ implementuje (nap°. NCSA Telnet, NCSA FTP, klient systΘmu Gopher, programy POPMail, Minuet apod.). Stßle vÜak mßme mo₧nost spustit si takov² program, kter² dokß₧e vyu₧φt ji₧ nainstalovanou implementaci protokolu IP (v naÜem konkrΘtnφm p°φpad∞ tu, kterß pat°φ programu NFS).

Kde paketov² ovladaΦ konΦφ, nastupuje PKTMUX!

P°esto ale existujφ takovΘ programy, kterΘ uvedenou "neschopnost" paketov²ch ovladaΦ∙ dodateΦn∞ kompenzujφ. Nejznßm∞jÜφm je program PKTMUX, vyvinut² ve v²zkumnΘm st°edisku Rutherford Appleton Laboratory (RAL) ve VelkΘ Britßnii. Tento voln∞ Üi°iteln² program (tj. freeware) funguje jako nadstavba nad paketov²m ovladaΦem (instaluje se a₧ po jeho zavedenφ), a chovß se v jistΘm smyslu jako v²hybka - od paketovΘho ovladaΦe p°ebφrß vÜechny p°ijatΘ IP pakety, a ty pak sßm rozd∞luje dßle.

Rozhranφ NDIS ovladaΦ∙

Standard NDIS byl p∙vodn∞ vypracovßn pro pot°eby sφ¥ovΘho operaΦnφho systΘmu LAN Manager firmy Microsoft, a byl zve°ejn∞n v kv∞tnu roku 1988. Mß formu voln∞ Üi°itelnΘho dokumentu (stejn∞ jako specifikace rozhranφ k paketov²m ovladaΦ∙m), a do dneÜnφ doby proÜel dalÜφmi dv∞ma v∞tÜφmi aktualizacemi (v souΦasnΘ dob∞ existuje verze 3.0). Stal se vÜeobecn∞ uznßvan²m a dodr₧ovan²m standardem, a jeho pou₧itφ rychle p°ekroΦilo rßmec jedinΘho produktu, pro kter² byl vytvo°en (LAN Manager-u). Dnes by si snad ₧ßdn² v²robce nedovolil uvΘst na trh sφ¥ovou kartu, ke kterΘ by neexistoval NDIS ovladaΦ. Na druhΘ stran∞ podporuje standard NDIS i velkß v∞tÜina sφ¥ov²ch program∙, kterΘ jsou schopny pracovat s nezbytn²m sφ¥ov²m hardwarem prost°ednictvφm NDIS ovladaΦ∙.

Jistou nev²hodou NDIS ovladaΦ∙ je jejich relativn∞ nßroΦnß instalace - z nßmi uva₧ovan²ch t°φ druh∙ ovladaΦ∙ z°ejm∞ nejnßroΦn∞jÜφ. Pro korektnφ instalaci a vlastnφ fungovßnφ NDIS ovladaΦe jsou zapot°ebφ jeÜt∞ dva dalÜφ systΘmovΘ programy (PROTMAN.SYS a NETBIND.EXE), a dßle konfiguraΦnφ soubor PROTOCOL.INI s popisem r∙zn²ch parametr∙ (kter² mß formu textovΘho souboru). V²robce sφ¥ovΘ karty ovÜem musφ napsat ke svΘmu produktu jen vlastnφ NDIS ovladaΦ, zatφmco programy PROGMAN.SYS a NETBIND.EXE jsou voln∞ Üi°itelnΘ (freeware) programy. P°esn² zp∙sob fungovßnφ NDIS ovladaΦ∙ popisuje nßsledujφcφ odstavec (nebo box: ..)

Jak funguje NDIS ovladaΦ

Pokud jde o stavebnicovΘ prvky, tyto se v rßmci standardu NDIS souhrnn∞ oznaΦujφ jako ovladaΦe (drivers), a jsou v zßsad∞ dvojφho druhu: tzv. protokolovΘ ovladaΦe (protocol drivers), kterΘ implementujφ jednotlivΘ sestavy protokol∙ (tj., p°enosovΘ protokoly vyÜÜφch vrstev, poΦφnaje sφ¥ovou), a dßle tzv. MAC ovladaΦe (MAC drivers), kterΘ pracujφ na ·rovni podvrstvy p°φstupu k p°enosovΘmu mΘdiu (podvrstvy MAC), a p°φmo ovlßdajφ p°φsluÜn² sφ¥ov² hardware. Neformßln∞ jsou pak prßv∞ tyto ovladaΦe oznaΦovßny jako NDIS ovladaΦe.

Obr. 2: P°edstava propojovßnφ ovladaΦ∙ standardu NDIS

Ka₧d² ovladaΦ p°itom mß dv∞ v²znaΦnß rozhranφ: hornφ a dolnφ. JednotlivΘ ovladaΦe se p°itom pomysln∞ "stavφ na sebe" (viz obr. 2), a dolnφ rozhranφ jednoho modulu se tak propojuje s hornφm rozhranφm druhΘho modulu. P°itom dolnφ rozhranφ MAC ovladaΦe (neboli: NDIS ovladaΦe) se takto propojuje p°φmo se sφ¥ovou kartou.

V prost°edφ MS DOSu majφ MAC ovladaΦe formu tzv. ovladaΦ∙ za°φzenφ (device drivers), zatφmco protokolovΘ ovladaΦe mohou mφt jak tuto formu, tak i formu b∞₧n²ch rezidentnφch program∙ v DOS-u, nebo formu aplikaΦnφch program∙. NejΦast∞ji vÜak i ony majφ formu ovladaΦ∙ za°φzenφ (device drivers), kterΘ se instalujφ p°i zavßd∞nφ systΘmu prost°ednictvφm souboru CONFIG.SYS.

Obr. 3: NDIS ovladaΦ a RM ISO/OSI

Praktickou realizaci propojovßnφ (anglicky: binding) jednotliv²ch ovladaΦ∙ mezi sebou mß na starosti tzv. sprßvce protokol∙ (protocol manager), kter² je sßm o sob∞ takΘ ovladaΦem (v prost°edφ MS DOSu ovladaΦem za°φzenφ). Tento sprßvce protokol∙ p°itom musφ b²t instalovßn jako prvnφ, resp. p°ed vÜemi ostatnφmi ovladaΦi, jejich₧ vzßjemnΘ propojovßnφ mß zajiÜ¥ovat (v rßmci souboru CONFIG.SYS tedy musφ b²t uveden jako prvnφ). VÜechny ostatnφ ovladaΦe se pak v okam₧iku svΘ instalace u tohoto sprßvce registrujφ, a p°itom mu p°edßvajφ r∙znΘ d∙le₧itΘ ·daje o sob∞. Sprßvce protokol∙ by vÜak nevystaΦil pouze s t∞mito informacemi - samotnΘ ovladaΦe mu nap°φklad nemohou °φci, jak majφ b²t mezi sebou vzßjemn∞ propojeny. Tyto (a mnohΘ dalÜφ) informace proto sprßvce protokol∙ Φerpß z konfiguraΦnφho souboru PROTOCOL.INI. V n∞m pak mohou b²t i ΦetnΘ dalÜφ informace, urΦenΘ ostatnφm ovladaΦ∙m - nap°φklad MAC ovladaΦ zde m∙₧e najφt informaci o tom, jakΘ p°eruÜenφ bude generovat jφm ovlßdanß sφ¥ovß karta apod. P°φklad konfiguraΦnφho souboru PROTOCOL.INI ukazuje obrßzek 3.

P°i instalaci jednotliv²ch ovladaΦ∙ (v rßmci "provßd∞nφ" souboru CONFIG.SYS) vÜak sprßvce protokol∙ pouze shroma₧∩uje pot°ebnΘ ·daje, kterΘ bude pot°ebovat pro vlastnφ propojenφ (binding) jednotliv²ch ovladaΦ∙, ale toto propojenφ zatφm fakticky nerealizuje. To d∞lß a₧ na explicitnφ p°φkaz. Ten mu m∙₧e vydat v principu kter²koli program, v praxi to ale b²vß jen program NETBIND.EXE, spouÜt∞n² a₧ p°i nab∞hnutφ celΘho operaΦnφho systΘmu (a¥ ji₧ ze souboru AUTOEXEC.BAT, z p°φkazovΘ °ßdky Φi jinak).

P°i vlastnφ prßci v sφti jsou pak data p°edßvßna mezi protokolov²mi ovladaΦi a MAC ovladaΦi takov²m zp∙sobem, aby bylo minimalizovßno jejich kopφrovßnφ z jednΘ vyrovnßvacφ pam∞ti (bufferu) do druhΘ. Pokud je to jen trochu mo₧nΘ, jsou p°edßvßny pouze ukazatele na p°φsluÜnΘ vyrovnßvacφ pam∞ti.

Sdφlenφ NDIS ovladaΦ∙

Standard NDIS poΦφtß s tφm, ₧e protokolov² ovladaΦ m∙₧e b²t sßm tvo°en z vφce Φßstφ (vφce dφlΦφch protokolov²ch ovladaΦ∙), kterΘ se budou sklßdat na sebe jako kostky pomyslnΘ stavebnice. Zatφm vÜak nedefinuje ₧ßdnΘ mechanismy pro vzßjemnΘ propojovßnφ (binding) t∞chto dφlΦφch Φßstφ.

DalÜφ variantou, na kterou standard pamatuje, je mo₧nost propojit jeden protokolov² ovladaΦ se dv∞ma MAC ovladaΦi, ka₧d²m pro jednu sφ¥ovou kartu (viz obrßzek 3). Tato situace vychßzφ vst°φc takov²m aplikacφm, jako jsou r∙znΘ mosty (bridges) a sm∞rovaΦe (routers).

Obr. 4: Sdφlenφ NDIS ovladaΦ∙

Nejzajφmav∞jÜφ je ale opaΦnß mo₧nost - sdφlenφ jednΘ sφ¥ovΘ karty a jednoho MAC ovladaΦe (resp. NDIS ovladaΦe) vφce protokolov²mi ovladaΦi. TakΘ na tuto mo₧nost souΦasnß verze standardu NDIS pamatuje (viz obr. 4): jeliko₧ MAC ovladaΦ m∙₧e b²t p°es svΘ hornφ rozhranφ propojen pouze s jednφm dalÜφm ovladaΦem, pou₧φvß se zde dalÜφ stavebnicov² prvek - ovladaΦ, naz²van² Vector. Ten je jedin²m p°φjemcem vÜech datov²ch paket∙ od MAC ovladaΦe, a starß se o jejich rozd∞lovßnφ mezi jednotlivΘ potencißlnφ p°φjemce. Velmi zajφmav² je p°itom jeho konkrΘtnφ postup: ka₧d² datov² paket postupn∞ nabφzφ jednotliv²m protokolov²m ovladaΦ∙m, dokud n∞kter² z nich neusoudφ, ₧e mu paket pat°φ, a neponechß si jej.

Prßv∞ naznaΦenΘ °eÜenφ je urΦit∞ velmi univerzßlnφ. Vector se nesna₧φ sßm rozhodovat o tom, komu datov² paket pat°φ, a toto rozhodnutφ ponechßvß na mnohem kompetentn∞jÜφch protokolov²ch ovladaΦφch. S realizacφ tohoto °eÜenφ je ale spojena nezanedbatelnß re₧ie, proto₧e postupnΘ nabφzenφ vÜech paket∙ jednotliv²m ovladaΦ∙m urΦitou dobu trvß. Po°adφ, ve kterΘm se Vector obracφ na jednotlivΘ protokolovΘ ovladaΦe, je p°itom dßno po°adφm jejich instalace v rßmci souboru CONFIG.SYS. Dφky tomu je pak mo₧nΘ fungovßnφ celΘho mechanismu v²razn∞ optimalizovat (instalovat jako prvnφ ty protokolovΘ ovladaΦe, kterΘ budou p°ijφmat nejvφce paket∙). Vy₧aduje to o ovÜem dosti hlubokou znalost fungovßnφ sφt∞, kterou lze jen t∞₧ko po₧adovat na b∞₧nΘm u₧ivateli.

Rozhranφ ODI ovladaΦ∙

Sφ¥ovΘ produkty firmy Novell zaΦaly p°echßzet z p∙vodnφ koncepce tzv. dedikovanΘho IPX (neboli sφ¥ovΘho protokolu IPX, kter² si sßm obsluhuje sφ¥ovou kartu) na pou₧φvßnφ nov²ch ODI ovladaΦ∙ postupn∞. V sφtφch NetWare verze 3.11 je mo₧nΘ pou₧φvat kter²koli z obou p°φstup∙, zatφmco v novΘ verzi 4.0 ji₧ jen ODI ovladaΦe.

Firma Novell p°itom zavedla zajφmavou praxi: po pat°iΦnΘm ov∞°enφ certifikuje ovladaΦe jednotliv²ch sφ¥ov²ch karet, a tφm vlastn∞ poskytuje svou vlastnφ zßruku na jejich korektnφ fungovßnφ (i kdy₧ je pφÜφ v²robci sφ¥ov²ch karet). ╚inila tak p∙vodn∞ i u tzv. dedikovan²ch IPX ovladaΦ∙, ale od Φervna 1992 ji₧ certifikuje pouze ODI ovladaΦe.

Zajφmav² je takΘ obvykl² zp∙sob, jak²m v²robci sφ¥ov²ch karet pφÜφ ODI ovladaΦe ke sv²m v²robk∙m. Vlastnφ standard rozhranφ ODI byl pln∞ zve°ejn∞n, a ka₧d² v²robce si tedy m∙₧e napsat pot°ebn² ovladaΦ zcela sßm. V praxi si ale za tφmto ·Φelem nejspφÜe zakoupφ od firmy Novell v²vojov² "kit" (LAN Driver Toolkit), se kter²m dostane n∞kterΘ Φßsti ODI ovladaΦe ve zdrojovΘm tvaru, a k nim pouze p°ipφÜe ty Φßsti, kterΘ se bezprost°edn∞ t²kajφ konkrΘtnφho hardwarovΘho °eÜenφ, a jsou pro n∞j specifickΘ. Podrobn∞ji je tato otßzka rozvßd∞na v nßsledujφcφm odstavci (resp. v boxu: ....)

Jak funguje ODI ovladaΦ

Obr. 5: ODI ovladaΦ a RM ISO/OSI

• ovladaΦ sφ¥ovΘ karty, oznaΦovan² jako MLID (Multiple Link Interface Driver). V u₧Üφm slova smyslu je jako ODI ovladaΦ oznaΦovßn prßv∞ tento programov² modul,
• modul LSL (Link Support Layer), fungujφcφ jako meziΦlßnek mezi ovladaΦem sφ¥ovΘ karty a protokoly vyÜφch vrstev
• sestava protokol∙ (tzv. protokol stack), implementujφcφ p°enosovΘ protokoly vyÜÜφch vrstev (sφ¥ovou vrstvou poΦφnaje).

Mo₧nosti vzßjemnΘho propojenφ vÜech t∞chto modul∙ ukazuje obrßzek 4. Z n∞j je takΘ mo₧nΘ vytuÜit, ₧e hlavnφm ·kolem ovladaΦ∙ sφ¥ov²ch karet (MLID) je bezprost°ednφ obsluha sφ¥ov²ch karet a zpracovßnφ rßmc∙ linkovΘ vrstvy, ze kter²ch p°i p°φjmu "vybalujφ" datovΘ pakety (kterΘ samy nijak neinterpretujφ), a p°edßvajφ je modulu LSL. Ten pak rozhoduje o tom, kterΘmu protokolu vyÜÜφch vrstev (resp. kterΘ sestav∞ protokol∙) bude ka₧d² jednotliv² paket p°edßn.

Samotn² ovladaΦ (MLID) je vesm∞s realizovßn jako jeden programov² modul (ve form∞ rezidentnφho programu, p°φpadn∞ i instalovatelnΘho ovladaΦe za°φzenφ, neboli tzv. device driveru). Intern∞ je ovÜem tvo°en ze t°φ Φßstφ (viz obr. 5):

Obr. 6: T°i Φßsti ovladaΦe MLID

• modulu MSM (Media Support Module), kter² °eÜφ to, co je pro vÜechny ovladaΦe spoleΦnΘ (p°edevÜφm pak vazbu na modul LSL a operaΦnφ systΘm, inicializaci atd.),
• modulu TSM (Topology Specific Module), kter² zajiÜ¥uje to, co je specifickΘ pro konkrΘtnφ p°enosovou technologii (nap°.: sΘriovou linku, sφ¥ typu Ethernet, Token Ring, FDDI apod.), tedy nap°φklad p°idßvßnφ Φi naopak odstra≥ovßnφ hlaviΦek linkov²ch rßmc∙ apod., a
• modul HSM (Hardware Specific Module), kter² zajiÜ¥uje bezprost°ednφ ovlßdßnφ sφ¥ovΘho hardwaru.

V²robce sφ¥ovΘ karty, kter² si od firmy Novell zakoupφ pot°ebn² v²vojov² "kit", vÜak musφ sßm napsat pouze modul HSM. Zdrojov² tvar ostatnφch dvou modul∙ toti₧ dostane v rßmci zakoupenΘho "kitu".

Jednou ze zajφmav²ch charakteristik celΘho rozhranφ ODI je jeho snaha o maximßlnφ univerzßlnost, spoΦφvajφcφ ve v∞domΘm zakr²vßnφ specifik pou₧φvanΘ p°enosovΘ cesty p°ed protokoly vyÜÜφch vrstev. Tyto sestavy protokol∙ (protocol stacks) tedy nevφ o tom, jak²m konkrΘtnφm zp∙sobem jsou data v sφti skuteΦn∞ p°enßÜenß, a dφky tomu pak mohou b²t stejnΘ pro r∙znΘ p°enosovΘ technologie (nap°. pro Ethernet, Token Ring, FDDI apod.). Potud je toto °eÜenφ jist∞ velmi v²hodnΘ. Na druhΘ stran∞ ale zastφrßnφ vÜech p°φpadn²ch odliÜnostφ a vytvß°enφ dojmu jednotnosti nem∙₧e b²t zadarmo, a jde tedy nutn∞ na ·kor efektivnosti p°enos∙ jako takov²ch.

Sdφlenφ ODI ovladaΦ∙

Obr. 7: P°edstava sdφlenφ ovladaΦ∙ ODI

Velmi zajφmav² je zp∙sob, jak²m jsou ve standardu ODI rozliÜovßny r∙znΘ druhy paket∙ (pro pot°eby jejich rozd∞lovßnφ mezi vφce potencißlnφch p°φjemc∙ z °ad sestav protokol∙ vyÜÜφch vrstev). Pakety jsou rozliÜovßny na zßklad∞ sφ¥ovΘho protokolu, podle kterΘho jsou sestaveny. Ka₧d² takov²to protokol mß p°i°azen Φφseln² identifikßtor (Protocol ID), ale konkrΘtnφ hodnota tohoto identifikßtoru je zßvislß i na druhu pou₧φvanΘ p°enosovΘ technologie (p°esn∞ji: na druhu rßmce, pou₧φvanΘho na ·rovni linkovΘ vrstvy). Nap°φklad u sφtφ typu Ethernet s linkov²m rßmcem Ethernet_II je tφmto identifikßtorem obsah 13. a 14. bytu rßmce (udßvajφcφ typ datovΘho paketu, viz minul² dφl tΘto sΘrie Φlßnk∙), zatφmco v p°φpad∞ rßmc∙ IEEE 802.3 s rßmci 802.2 je to obsah jednobytovΘho pole DSAP (Destination SAP, neboli p°echodov² bod p°φjemce).

Tφm, kdo p°ijatΘ rßmce podle jejich typu (identifikßtoru) skuteΦn∞ rozd∞luje mezi vφce r∙zn²ch sestav protokol∙, je modul LSL. V zßsad∞ tak Φinφ na zßklad∞ po₧adavk∙, kterΘ mu jednotlivΘ sestavy protokol∙ p°edajφ ve fßzi inicializace celΘho rozhranφ.

Po₧adavek konkrΘtnφ sestavy protokol∙ na p°φjem paket∙ m∙₧e b²t v zßsad∞ trojφho druhu:

• tzv. prescan re₧im (doslova: re₧im p°edb∞₧nΘ prohlφdky), p°i kterΘm danß sestava protokol∙ po₧aduje, aby jφ byl nabφdnut ka₧d² p°ijat² paket, ona jej "prohlΘdne", a pak si jej podle vlastnφho uvß₧enφ bu∩ nechß, nebo jej zase vrßtφ modulu LSL, kter² jej m∙₧e nabφdnou dalÜφm zßjemc∙m,
• tzv. bound re₧im (doslova: vßzan²), kdy se sestava protokol∙ p°ihlßsφ u modulu LSL s po₧adavkem na odb∞r paket∙ urΦitΘho konkrΘtnφho typu (vyjßd°enΘho p°φsluÜn²m identifikßtorem), nebo
• tzv. default (tj. implicitnφ) re₧im, p°i kterΘm sestava protokol∙ p°ijφmß vÜechny pakety, kterΘ zbydou.

Jedna sestava protokol∙ se m∙₧e p°ihlßsit k odb∞ru paket∙ od jednΘ Φi vφce sφ¥ov²ch karet (resp. ovladaΦ∙ MLID). Pro ka₧dou kartu vÜak smφ po₧adovat re₧im "prescan" nejv²Üe jedna sestava protokol∙, a stejn∞ tak i pro re₧im "default". K p°φjmu paket∙ r∙zn²ch typ∙ z jednΘ a tΘ₧e karty v tzv. vßzanΘm (bound) re₧imu se m∙₧e p°ihlßsit vφce sestav protokol∙.

Modul LSL pak p°i p°ijetφ ka₧dΘho paketu postupuje tak, ₧e jej nejprve nabφdne sestav∞ protokol∙, kterß se p°ihlßsila k odb∞ru v re₧imu "prescan". Pokud tato paket odmφtne (nebo v∙bec neexistuje), p°edß modul LSL datov² paket tΘ sestav∞ protokol∙, kterß se p°ihlßsila k odb∞ru p°φsluÜnΘho typu paket∙ v re₧imu bound. Pokud ₧ßdnß takovß sestava protokol∙ neexistuje, p°edß LSL paket implicitnφ sestav∞ protokol∙ (tj. tΘ, kterß se p°ihlßsila k odb∞ru v tzv. default re₧imu).

Zde se ovÜem nabφzφ zajφmavß otßzka: majφ-li b²t vÜechny sestavy protokol∙ zcela nezßvislΘ na konkrΘtnφ p°enosovΘ technologii, jak potom mohou znßt konkrΘtnφ ΦφselnΘ identifikßtory typ∙ paket∙, se kter²mi majφ pracovat, kdy₧ tyto jsou na p°enosovΘ technologii zßvislΘ? Nap°φklad pro IPX rßmce, p°enßÜenΘ v sφti Ethernet (s linkov²mi rßmci Ethernet_II) mß p°φsluÜn² identifikßtor (Protocol ID) hodnotu 8137 hexadecimßln∞, zatφmco v p°φpad∞ sφtφ Token Ring mß hodnotu EO (taktΘ₧ hexadecimßln∞)?

╪eÜenφ je vcelku jednoduchΘ: sestavy protokol∙ nemajφ v sob∞ p°φsluÜnΘ identifikßtory pevn∞ zabudovßny. Mφsto toho je zφskßvajφ a₧ prost°ednictvφm konfiguraΦnφho souboru (NET.CFG), kde je pro n∞ p°ipravujφ u₧ivatelΘ (resp. sprßvci sφt∞).

Zßv∞rem

Ka₧d² takov²to seznam ale v₧dy bude ne·pln² a neaktußlnφ ji₧ v okam₧iku jeho sestavovßnφ - situace se toti₧ m∞nφ skuteΦn∞ den ze dne, a zcela zßkonit∞ sm∞°uje k tomu, ₧e ka₧d² sφ¥ov² program bude podporovat ka₧d² druh sφ¥ovΘho ovladaΦe. OvÜem i v p°φpad∞, kdy urΦit² konkrΘtnφ sφ¥ov² program zatφm nepodporuje urΦit² konkrΘtnφ druh ovladaΦ∙, nenφ jeÜt∞ zdaleka nic ztraceno: existujφ toti₧ takovΘ programy, kterΘ p°evßdφ jedno rozhranφ k sφ¥ov²m ovladaΦ∙m na jinΘ. V angliΦtin∞ se jim °φkß p°φznaΦn∞ shims (doslova: podlo₧ky, vyrovnßvacφ meziΦlßnky).

P°edstavme si nap°φklad, ₧e provozujeme program, kter² je schopen pracovat jen s tzv. NDIS ovladaΦi, ale k naÜφ sφ¥ovΘ kart∞ mßme k dispozici pouze tzv. ODI ovladaΦ. Nevadφ - po instalaci tohoto ODI ovladaΦe si nainstalujeme jeÜt∞ p°evodnφk mezi ODI a NDIS ovladaΦi (konkrΘtn∞: program ODINSUP). V²sledn² efekt je pak v zßsad∞ takov², jako kdybychom pou₧ili skuteΦn² NDIS ovladaΦ.