EPOC32

V poslední době se na kapesních počítačích (handhelds, palmtops) rozmáhají Windows CE. Zkusil jsem s nimi chvíli pracovat, a dovolil bych si tu zkratku přeložit do češtiny jako "Celkově Eklhaft" -- ten systém je podle mého subjektivního názoru na hranici nepoužitelnosti. Přitom je pro kapesní počítače k dispozici daleko lepší operační systém, od výrobce nejlepších kapesních počítačů na světě, firmy PSION: jmenuje se EPOC/32, a na rozdíl od svého předchůdce, EPOCu/16, je možné získat jeho licenci a implementovat jej na libovolné vlastní zařízení; není tedy omezen jen na počítače PSION.

Je nutné si uvědomit, že kapesní počítače nejsou a nikdy nebudou to samé, jako desktopy -- nebo laptopy. Ať půjde vývoj kudykoliv, vždy bude kapesní počítač příliš malý na to, aby obsahoval sedmnáctipalcovou obrazovku; a i kdyby technologie umožnila vytvořit displej třeba skládací, pořád jej nebude možné pohodlně používat v typickém prostředí, kde pracujeme s palmtopem: při chůzi, v dopravním prostředku, při obědě apod. Podobně je tomu s klávesnicí, i s řadou dalších vlastností: má-li být palmtop rozumně použitelný, musí být schopen pracovat desítky hodin na pár obyčejných tužkových baterií, jeho váha musí být srovnatelná s váhou samotného akumulátoru dnešních laptopů, a musí se pohodlně vejít do kapsy...

EPOC32 je operační systém, navržený speciálně pro přenosná zařízení. Díky tomu počítá s relativně malou obrazovkou s poměrně špatným kontrastem, a nabízí její optimální využití; díky tomu počítá s tím, že operační systém a standardní aplikace leží v paměti ROM, a umožňuje je přímo z paměti ROM spouštět; díky tomu filosofie jeho ovládání vychází z kombinace klávesnice/pero, a ne z kombinace klávesnice/myš; díky tomu nabízí špičkové využití energie. Díky tomu také nabízí daleko vyšší spolehlivost, než jiné operační systémy: data z kapesního počítače jsou velmi důležitá, a jen málokdo je pravidelně zálohuje... Přenosná zařízení musejí být schopna zabezpečit spolehlivou komunikaci, a na to je zapotřebí real-time operační systém; EPOC32 proto dokáže zpracovat přerušení v několika desítkách mikrosekund (na procesoru ARM7100/18MHz).

V následujících odstavcích se podrobněji podíváme na strukturu a služby systému EPOC32, a zběžně si ukážeme jeho první implementaci, kapesní počítač PSION Series5.

1. Struktura EPOCu

EPOC32 je moderní operační systém, založený na mikrokernelu, který zajišťuje nejzákladnější úlohy (jako je správa paměti, správa procesů a threadů), a na řadě serverů -- často dynamicky zaveditelných -- které se starají o vše ostatní, od správy souborů až po vstup a výstup. Správa paměti samozřejmě chrání operační systém před ostatními procesy i procesy mezi sebou navzájem; díky tomu nemůže žádná aplikace ani chybou, ani zlým úmyslem ohrozit ostatní.

Pro velmi jednoduché aplikace (jako jsou např. mobilní telefony) je EPOC32 možné konfigurovat jako uzavřený jednoprocesový systém. V něm mezi jednotlivými thready není žádná ochrana; hardware proto nemusí obsahovat jednotku pro řízení paměti, nejsou zapotřebí stránkové tabulky, přepínání threadů bude extrémně rychlé. Vyšší vrstvy EPOCu -- speciálně jeho grafické uživatelské rozhraní -- mohou být snadno nahrazeny jednodušším software, šitým na míru konkrétní aplikaci. Taková instalace je ideální pro systémy, u kterých nepřipadají v úvahu uživatelské nebo 3rd party aplikace a drivery; kromě již zmíněných mobilních telefonů sem patří dlouhá řada ne nutně přenosných zařízení typu WebTV a podobně...

Celkovou strukturu EPOCu/32 vidíme na obrázku. Základní komponenty, včetně vrstvy ukrývající specifika konkrétního hardware, jsou soustředěny v bloku Base. Jeho služby pak využívají další moduly: větev driverů, zajišťujících komunikaci (a mimochodem také transparentní přenos souborů mezi EPOCem a Windoze bez problémů s českými znaky), a hlavní sestavu knihoven a služeb vlastního EPOCu.

Tento článek není určen pro programátory, a proto se nebudeme strukturou a obsahem knihoven zabývat podrobně; seznámíme se jen s několika nejzajímavějšími údaji.

Předně, knihovny jsou samozřejmě dnamicky zaváděné, a jedná se o native knihovny C++, ve kterém je celý EPOC32 napsán, a ve kterém se také standardně vytvářejí aplikace (alternativou je Java nebo proprietary jazyk OPL). Sám o sobě jazyk C++ není nejšťastnější volba; návrháři PSIONu jej patrně vybrali proto, že výkon dnešních palmtopů je stále relativně omezen, takže by pro skutečně objektový systém, jaký nabízí např. Objective C, nestačil. Pro statické pseudoobjekty C++ však stačí pohodlně, a proti plain C je C++ rozhodně daleko příjemnější. Knihovny sestavené ze tříd -- byť se nejedná o plnohodnotné třídy dynamických objektových systémů -- také nabízejí programátorovi větší flexibilitu a zároveň lepší ochranu proti chybám, než klasické knihovny funkcí. Knihovny nabízejí skutečně mnoho velmi pohodlných služeb; ačkoliv jejich množství (a díky C++ ani pohodlí programátora) nedosahuje úrovně dnešních špičkových systémů pro desktopy, nabízejí rozhodně daleko víc nesrovnatelně pohodlnějších služeb než např. Win32 API.

Základní vrstva Base zajišťuje především správu systému, obsahuje drivery pro jednotlivá zařízení, souborový server (schopný samozřejmě pracovat s dynamicky zaváděnými systémy souborů, takže pro něj není problém rozumět si např. s DOSovskými nebo Macovskými disky), komunikační služby (bohužel, EPOC32 neobsahuje distribuované objekty; namísto toho má programátor k dispozici BSD sockety), rychlé předávání zpráv pro architekturu klient/server (v real-time systému) a podobně. Již jsme se zmínili o vrstvě 'HAL' -- to není reminiscence na Vesmírnou odysseu, ale "Hardware Abstraction Layer", který skrývá specifika libovolné konkrétní architektury, na které může být EPOC32 implementován (dnes pracuje bez problémů na procesorech Intel 80x86 a ARM).

EPOC32 je, na rozdíl od naprosté většiny ostatních systémů, navržen pro neustálou práci: palmtop přeci koupíme, zapneme, a od té doby běží; jeho "vypnutí" je ve skutečnosti jen vypnutím displeje a pozastavením procesoru. žádný restart nepřipadá v úvahu. Proto má programátor k dispozici velmi silné prostředky pro ošetření výjimek a chybových stavů, implementované již na úrovni základní vrstvy: jedná se o standardní systém výjimek, rozšířený o automatické uvolnění objektů a zdrojů. Pokud je mi známo, žádný jiný systém (s jedinou výjimkou OpenStepu, tam je to však samozřejmý důsledek plně objektové implementace garbage collectoru) podobnou podporu nenabízí.

Služby vrstvy 'Engine' zajišťují vše, co programátor potřebuje pro běh aplikace bez grafického uživatelského rozhraní (tj. engine): je zde velmi luxusní databázový systém, obsahující mj. i omezenou implementaci SQL, velmi důležitá podpora pro práci s persistentními objekty (tzv. "stream stores"; až na naprosté výjimky je v EPOCu cokoli, co se ukládá na disk, právě stream store -- z hlediska programu tedy síť objektů), práce s textem a podobně. Podpora pro práci s textovými řetězci dokáže pracovat jak s osmibitovým kódováním, tak i s kódováním UNICODE; potenciálně tedy dokáže snadno obsloužit jak češtinu, tak i mnohem exotičtější jazyky (konkrétní implementace v počítači Series5 však bohužel UNICODE nevyužívá, takže tam je nutné češtinu zajistit "standardní" cestou změny kódové tabulky).

Grafický subsystém EPOCu se nijak zvlášť nevymyká z obecných grafických systémů typu Apple QuickDraw, WIN32 nebo XWin, s jejich ad hoc sestavenou sadou grafických primitiv. Na rozdíl od nejjednodušších z nich je ale sestaven ze samostatného window serveru, který vlastní a obsluhuje potřebné zdroje (obrazovku, klávesnici, pero...), a na který se obracejí jednotliví klienti; tento model je mnohem praktičtější a flexibilnější, než jednoduchá sada knihovních služeb, jakou disponuje např. QuicDraw. Grafický subsystém EPOCu je navíc optimalizován pro poměrně malou obrazovku, schopnou zobrazit jen málo barev nebo dokonce jen několik stupňů šedi, k tomu typicky s dost špatným kontrastem; díky tomu jsou jeho služby pro kapesní systémy velmi praktické. Příkladem může být u grafických systémů dost vyjímečná podpora pro změnu velikosti písma: v EPOCu je naprosto běžné, že uživatel může pohodlně přepínat velikost písma v právě aktuální aplikaci, aniž by měnil skutečně použitý font. Zároveň grafický systém nezapomíná na malou obrazovku, takže po zvětšení se text automaticky přeláme a stále jej můžeme pohodlně číst. Samozřejmostí je podpora tisku, tiskového náhledu (preview) a faxování.

Úroveň uživatelského rozhraní je v EPOCu jasně rozdělena do dvou knihoven: zatímco CONE (CONtrol Environment) obsahuje abstraktní ovládací a zobrazovací primitiva (jako je okno, menu, dialog, tlačítko...), teprve další úroveň, EIKON, je odívá do konkrétního vzhledu a vybavuje je konkrétním způsobem ovládání. Díky tomu je poměrně snadné v případě potřeby změnit grafické uživatelské rozhraní EPOCu, aniž by bylo nutné měnit aplikace, které pod ním pracují.

Nejvyšší, aplikační vrstva je také zajímavá. Nakolik je mi známo, EPOC32 ze všech komerčně dostupných operačních systémů došel nejblíž k objektovému pohledu, kdy namísto "spouštění aplikací" spíše "zpracováváme dokumenty": samy aplikace EPOCu jsou daleko spíše knihovnami služeb pro práci s dokumenty určitého typu, než aplikacemi v klasickém smyslu slova. I když to přináší některé okrajové problémy (např. otevření libovolného souboru v hexadecimálním editoru není pro tuto filosofii právě přirozenou akcí), je celkový systém zvlášť pro nepočítačově zaměřeného uživatele daleko přehlednější a srozumitelnější, než systémy klasické.

2. Tvorba aplikací

Vzhledem k tomu, že EPOC32 je operační systém pro malé kapesní přístroje, je samozřejmé, že prostředí pro tvorbu aplikací bude převážně křížové, a poběží na desktopech. Přesto ale EPOC32 obsahuje podporu pro interpretovaný programovací jazyk OPL (který je vzdáleným potomkem BASICu), a díky ní je možné vytvářet aplikace přímo v EPOCu; ani uživatelé, kteří mají pouze kapesní počítač, tak nepřijdou zkrátka.

EPOC32 celkem disponuje dvěma vývojovými prostředími; i když se jejich služby do jisté míry překrývají, je každé z nich zaměřeno na jiný okruh problémů:

- Základní vývojové prostředí pro EPOC32 je samozřejmě postaveno kolem jazyka C++ (ve kterém je až na několik málo rutin v assembleru napsán i celý EPOC). Pro tvorbu a ladění aplikací se využívá překladač Visual C++ ve spolupráci s EPOCem, který běží v samostatném procesu v hostitelském systému Windows NT (případně v parodii na proces, dostupné ve Windows 95). Cílová aplikace se pak vytvoří pomocí křížového překladače GNU C++. Součástí prostředí je řada pomocných programů pro tvorbu fontů, pro překlad resourců z textového tvaru do cílové podoby (sic! vývojové prostředí alespoň zatím bohužel opravdu využívá textové zdrojové tvary, namísto grafického editoru) a podobně.

- Druhou a poslední (necháme-li stranou 3rd party řešení) možností je OPL. Interpretovaný jazyk OPL je někde mezi C++ a Visual BASICem: je rychlejší než BASIC, ale samozřejmě pomalejší než C++; nabízí větší flexibilitu než BASIC, ale zdaleka ne takovou, jako C++. Zcela mu chybějí prostředky pro visuální programování -- nenamyšujeme nic, všechny formuláře (stejně jako ostatní prvky GUI) musíme naprogramovat. Naproti tomu ale nepotřebuje hostitelský počítač s Windoze; namísto toho v něm můžeme programovat přímo na kapesním počítači s EPOCem.

Podle firmy PSION by ve velmi blízké budoucnosti měl EPOC32 plně podporovat Javu. Ta by se tak stala dalším standardním vývojovým prostředím; protože zatím tak tomu ale není, nebudeme se zde touto možností dále zabývat.

Podpora pro tvorbu aplikací vyvolává smíšené pocity: ačkoliv se bezpochyby jedná o dosud nejpohodlnější a nejluxusnější "palmtopové" prostředí, struktura EPOCu by umožňovala sestavit prostředí ještě o mnoho řádů lepší, srovnatelné s OpenStepem -- jen trochu chtít... Omezení na Windoze je pak nedomyšlenost přímo kapitální, a důsledky -- jako např. nutnost psát a ladit programy s využitím jiného překladače, než který se použije pro vytvoření finální verse -- ji už jen podtrhují. Ačkoli jednám s firmou PSION o možnosti vytvořit křížové vývojové prostředí v OpenStepu (což by nabídlo nejen daleko lepší služby uživatelům Windoze díky OpenStepu/NT a OpenStepu/W95, ale také by to umožnilo vyvíjet aplikace pro EPOC uživatelům NEXTSTEPu, Solarisu, Macintoshe, a díky GNUStepu nakonec vlastně libovolného systému, včetně velmi rozšířeného Linuxu), v současnosti to bohužel moc nadějně nevypadá.

3. Sdílení dat s jinými počítači

Last, but not least: přenos datových souborů do jiného prostředí a převod jejich formátů, aby tam byly přímo použitelné, je pro kapesní počítač nesmírně důležitý. To je také jedním z hlavních argumentů těch, kdo prosazují Windows CE: "jsou to windows, takže se soubory není problém"... Bohužel, ten argument je hluboce mylný, a to ze dvou důvodů.

Předně, ačkoli to jsou windows, se soubory problém je: kapesní verse jednotlivých aplikací nevyužívají stejné souborové formáty jako plné verse, sloužící na desktopech a laptopech; řada důležitých informací se při přenosu ztrácí. Ačkoli to na první pohled zní paradoxně, je -- alespoň podle informací z druhé ruky, které mám k dispozici, protože sám Windoze samozřejmě nepoužívám -- EPOC32 ve skutečnosti s Windows kompatibilnější, než WindowsCE.

Druhý nedostatek zmíněného argumentu je mnohem závažnější: windoze nejsou žádný standard; naopak, jejich datové formáty se od standardu často zásadně liší. Uživatelům jakéhokoli rozumného operačního systému tedy není nic platné, jestli palmtop dokáže nebo nedokáže importovat/exportovat data v proprietary formátu windoze; potřebují standard (kterému se, na rozdíl od windoze, operační systémy obvykle bez problémů podřizují).

EPOC32 pro přenos datových souborů využívá unikátní přístup, který přináší zhruba stejné množství výhod jako nevýhod. Namísto konverze do standardního tvaru nebo alespoň detailní dokumentace vlastního formátu totiž EPOC nabízí kompletní engine aplikací; ten se celý přenese do systému, do/ze kterého má přenos probíhat, a překlad formátu zajistí. Engine aplikace samozřejmě zná svůj vlastní formát; stačí jej tedy doplnit možností vstupu a výstupu ve formátu cílového prostředí -- takže např. engine textového editoru ve Windoze bude umět načítat a zapisovat texty ve formátu M$ Word -- a vše bude bez problémů fungovat: uložíme-li dokument z textového editoru PSIONu na Windozeovský disk, bude ve formátu Word; stejně dobře můžeme Wordovský dokument v textovém editoru EPOCu otevřít... Totéž platí samozřejmě i pro ostatní datové formáty.

Výhody jsou zřejmé, ovšem nevýhody také: pro každý systém je nutné vytvořit odpovídající překladové rutiny, spojit je se zdrojovými kódy engine všech aplikací (a ty samozřejmě má PSION, a nedá), a vše přeložit do nového přenosového modulu. Praktickým důsledkem nakonec je to, že sice pro každý systém, pro který existuje patřičný modul, je přenos dat nesmírně pohodlný a v podstatě "neviditelný"; zato ale je takových systémů po čertech málo: přesně řečeno, jediný -- Windoze (podle zpráv by měl být k mání další modul pro MacOS, zatím jsem jej ale neviděl). Pro žádný rozumný systém, počínaje levným Linuxem přes oblíbený (byť tak trochu umírající) OS/2 až po luxusní OpenStep, zatím přenosový modul není k dispozici.

4. Suma sumárum

EPOC32 je moderní operační systém, obsahující vše, co se od moderního systému dá čekat: správu paměti se vzájemnou ochranou procesů, preemptivní multitásking a multithreading, (víceméně) objektové a dost luxusní standardní knihovny, podporu rychlých komunikací a architektury klient/server, špičkové grafické uživatelské rozhraní a tak dále. Přitom je navržen a optimalizován právě pro přenosné systémy, takže dokáže optimálně využít jejich omezené zdroje -- od displeje, který i při té nejlepší technologii má daleko k 21" monitoru s grafickou kartou umožňující 1600x1200 pixelů v truecoloru, přes omezenou klávesnici doplněnou perem namísto myši, až po omezené zdroje energie. Z pohledu uživatele moderního objektového systému (ale kolik nás zatím je?) je snad trochu nepříjemným omezením pouze jeho struktura, založená na statických objektech C++; to je ale celkem pochopitelný a nutný kompromis, vynucený relativně nízkým výpočetním výkonem procesorů v kapesních počítačích, relativně malým rozsahem paměti atd.

Jeho jedinou vážnější chybou je nedomyšleně úzká vazba na Windoze, jak v přenosu souborů, tak i ve vývojovém prostředí. Kromě samozřejmých problémů, které to přináší všem uživatelům rozumných operačních systémů, to s sebou nese řadu zbytečných kompromisů i pro uživatele samotných Windoze: např. využití jiného překladače pro ladění a jiného pro finální versi aplikace, nebo to, že při programování v C++ nejsou k dispozici visuální prostředky pro práci s objekty (dokonce ani s objekty GUI, což už dnes dávno umí každé Delphi). Je to velká škoda; na druhou stranu si musíme uvědomit, že alternativní řešení, která dnes trh nabízí (od Windows CE až po Newtona -- jehož systém je navíc šitý na míru a neumožňuje licenční šíření) jsou na tom v tomto směru ještě hůř.

(ostatní články)