BeOS
====
Unix is the worst operating system; except for all others.
-- Berry Kercheval
V roce 1990 Jean-Louis Gassée (známý dobroduh a spoluzakladatel
Apple) založil novou firmu jménem Be s cílem vyvinout nový
a nezkažený počítač hodný 90. let spolu s novým operačním systémem.
Tento romantický cíl se firmě podařilo splnit tuším v roce 1997.
BeBox (jak se ten ideální počítač jmenoval) byl vybaven dvěma
PowerPC procesory a jinak celkem standardním hardwarem (IDE).
Zajímavý byl zejména svou cenou.
Firma Be ale postupovala přibližně stejnou cestou jako její
předchůdkyně - NeXt, a tak do dvou let od náročné výroby svého
hardware upustila. Zůstal pouze operační systém BeOS, který
portovala na populárnější platformy - Power Mac a Intel. Právě díky
tomuto portu jsem si mohl BeOS ošahat i na svém počítači. Musím
říct, že jsem byl docela potěšen tím, co jsem viděl. BeOS nejenom
elegantně a user friendly vypadá, ale zejména programování v něm
je zajímavé a člověk má možnost si odzkoušet moderní technologie
a trendy v praxi. Je opravdu zajímavé opustit 70. léta UNIXu,
80. léta X oken, 60. léta DOSu (nevímjaká léta oken) a vydat se "do
budoucnosti".
Trocha firemní politiky.
========================
Pokud si přečtete firemní články o BeOS, zjistíte, že dokola
omílají následující vlastnosti svého výplodu:
A true Preemtive Multitasking, Pervasively Multithreaded Operating
System.
Co to je preemtivní multitásking či multithreading ví asi
každý z reklamní kampaně Windows95, které jej konečně alespoň
částečně implementují. Co to je Pervasively Multithreaded mi ale
vrtalo hlavou. Při pohledu do slovníku se dozvíte, že pervasion =
proniknutý, prostoupený.
BeOS je opravdu prostoupený thready (vlákny). V podstatě není
možné napsat program, který by nebyl multithreaded. Pokud například
otevřete okno, založí se automaticky speciální thread, který jej
obsluhuje. A proto se threadů v každém programu urodí celá hromada.
Například takový webowý browser má jeden hlavní thread, jeden thread
starající se o DNS dotazy, další thread od každého okna a u každé
zobrazované stránky jeden thread starající se o nahrávání a další
o zobrazování. Po nabootování v systému běží celkově asi 160 threadů
v 17 procesech (které se zde jmenují team)
Autoři BeOS tvrdí, že právě díky tomu jejich aplikace umí využít
více procesorů, a dokonce tvrdí, že thready pomáhají i na jednom
procesoru a zlepšují odezvu systému.
Právě k této vlastnosti jsem byl skeptický. Mé zkušenosti
s multithreadingem z jádra v Linuxu říkaly, že programování pro
thready je komplikované, že často vznikají race condition (kdy
se více threadů popere o jedno místo v paměti naráz a výsledky
jsou nepředpokládatelné) a dead locks (kdy thready na sebe vzájemně
čekají, až uvolní nějaký prostředek). Navíc thready přece jenom něco
stojí, a tak se mi to zdálo jako zbytečné mrhání prostředky a nervy
programátorů.
Po chvíli programování v BeOS ale mé obavy zmizely. U běžné BeOS
aplikace se jednotlivé prostředky příliš nesdílí a komunikují spolu
pomocí zpráv, které v threadech potíže nedělají. Pokud se už přece
jenom rozhodnou u něco prát (bežně tato situace vzniká u okna, kam
často kreslí více threadů a navíc na něj šahá systém), není problém
přidat velkorysé zámky od celého objektu, a pak už člověk musí dávat
pozor, aby prostředek zamkl, než s ním začne dělat a potom odemkl.
Protože se takto zamyká většiou jenom jeden prostředek, deadlocks
nevznikají.
I z uživatelského hlediska jsou thready příjemné. Můžete
se například hrabat v menu a dialogech, i když aplikace pracuje
(renderuje HTML, tiskne apod.) Například u file manageru i načítání
adresáře je zvláštní proces, a tak v případě, že je file systém
pomalý (například po síti), můžete pracovat se soubory ještě před
tím, než se celá adresář načte. Protože se využívá i čas, kdy jeden
thread čeká na periferie, běží občas aplikace opravdu svižněji.
Symetric multiprocesoring
BeOS podporuje více procesorů. Právě díky threadům i jedna
aplikace je dokáže využít.
Object Oriented Design.
Objekty jsou moderní, a tak pronikly i do návrhu operačního
systému. V terminologii BeOS znamenají zejména to, že standardní
knihovna je v C++ a téměř celé API je objektové. To je docela
příjemná vlastnost pro komplexnejší programy a uživatelské
interface. Mnoho objektů se používá znova a znova v nejrůznějších
situacích, a tak je vidět, že objekty mají něco do sebe. Jak to ale
u objektů bývá, nejsou nejšikovnější pro malé programy, a tak i
hello world není žádný drobeček. Navíc C++ je zrovna jazyk, který
příliš nemiluju.
Design for Real-Time Media and Communications.
Protože BeOS vznikal v době multimedií, je navrhován tak, aby se
v něm dobře psaly realtime aplikace. Navíc obsahuje velmi pěkný
systém pro prácí s videem a zvukem, o kterém se zmíním později, a
proto psaní multimediálních aplikací je v BeOS opravdu pěkné a výkon
více než slušný.
Zobrazování musí být také rychlé, a proto BeOS dovolí aplikaci
přistupovat přímo do videoram, a to i v okenním režimu (řekne
aplikaci, které části okna jsou vidět). Samozřejmě má také podporu
pro 3D accelerace.
Simplicity
BeOS není s ničím kompatibilní (I když to není úplně pravda,
protože podporuje POSIX), nemá v sobě žádně archaizmy, nepoužitelné
API překryté použitelnými a další bastly objevující se ve starších
systémech. Proto je programování v něm docela snadné. Podle mé
zkušenosti ale ne zas až tolik. Některé části BeOS jsou hezké, ale
jiné se moc nevydařily a přinášejí zbytečné komplikace. Navíc
některé vymoženosti jsou zbytečně omezené a daly by se zobecnit. Be
ale zatím má odvahu porušovat kompatibilitu jednotlivých verzí, a
tak autorům nic nebrání, aby je v dalších verzích předělali.
Multithreaded 64Bit file system
Multimedia potřebují velké soubory, a proto klasických 32 bitů
(4.2TB) přestává stačit, a tak je dobré podporovat i soubory větší.
64 bitů už bohatě stačí.
Filesystém v BeOS je také optimalizovaný proti fragmentaci,
používá logování, a proto je odolný vůči pádům systému (kterých si
alespoň ve verzi 4 užijete víc než dost).
Jednou z jeho velmi hezkých vlastností je podpora pro databáze.
Každý soubor je v podstatě adresářem atributů (atribut má jméno,
typ a hodnotu). Podobně jako u jména souboru lze pak vytvořit index
pro libovolý z atributů a pak podle něj velmi rychle vyhledávat.
Proto například program pro poštu může ukládat jednotlivé dopisy
do souborů a nastavit jim atribut From podle odesilatele. Vyhledání
dopisů od daného člověka je pak stejně snadné jako najít soubor
s daným jménem.
Tato vlastnost má mnoho využití a často zjednodušuje život.
Například sytém u každého souboru ukládá mime typ a aplikace zase
mají podporované mime typy v jiných atributech. Tak systém snadno
najde podle mime typu aplikaci, které patří, a aplikace není nutné
nikam registrovat.
MediaOS
Operační systém splňující výše zmíněné vlastnosti komerční
politika firmy nazývá MediaOS a tvrdí, že je to operační systém
vhodný pro dobu multimedií.
Jak to prakticky vypadá
=======================
Teď už víme, o co autorům šlo, a je čas ukázat, jak se jim to
povedlo.
O jádře BeOS toho příliš nevím, vyjma toho, že používá message
passing microkernel, a proto se hned podíváme, jak se BeOS tváří k
aplikacím.
Zprvávy
Nejprve je nutné pochopit, jak se posílají zprávy. Ty jsou pro
celý BeOS nesmírně důležité a jsou velmi praktické, a proto se o
nich zmíním podrobněji:
Zpráva se vytváří pomocí třídy BMessage. Ta obsahuje typ, což je
32 bitová unsigned hodnota, podle které se určuje, co zpráva znamená.
Některé typy jsou vyhrazené pro systém a jiné si může definovat
uživatel. Docela zajímavý nápad je použítí multibyte stringu. Pokud
v GNU C napíšete 'ahoj', znamená to integerovou hodnotu odpovídající
stringu ahoj. Lze tedy na typy nahlížet jako na 4 písmenné stringy.
Načež platí konvence, že systémové typy obsahují velká písmena,
číslice a podtržítka. Pokud tedy ve svých typech použijete malá
písmena, kolize nevznikne.
Do BMessage pak lze vkládat snadno jednotlivé hodnoty. Ty
se zkládájí z identifikátoru, což je string, typu, což je integer
a hodnoty (to je cokoliv). BMessage umí příjemně vkládat základní
typy jako integer, pointer a lze přidávat vkládače pro další. Proto
například zprávu o souřadnicích myši můžete vytvořit takto:
BMessage m('_mys');
m.AddInt("x",x);
m.AddInt("y",y);
Pokud zprávu potřebujete poslat, zavoláte metodu Flatten,
která ji převede na pole bajtů nezávislé na endianitě stroje. Zprávu
lze pak odeslat a zase složit zpátky. Navíc se v BeOS bežně zprávy
používají pro ukládání dat na disk a nejrůznější další účely.
Do zprávy lze položky postupně nabalovat, a tak si každá část
může uložit co potřebuje a jedna zpráva pak obsahuje data od více
modulů. Naopak při adresaci se často používají položky, které
program po doručení odřízne a pošle dál podle následující.
O odesílání zpráv se stará třída BMessenger, která dokáže poslat
zprávy jak uvnitř aplikace, tak ven. Přijímá je třída BLooper, která
si v konstruktoru zakládá zvláštní thread, který prochází postupně
frontu přišlých zpráv a předává je cílovým objektům typu BHandler,
které zprávy filtrují a volají obslužné rutiny.
Celý systém vypadá komplikovaně, ale člověk si na něj rychle
zvykne a pracuje se s ním pěkně.
Start aplikace
Život aplikace v BeOS není žádná legrace. Každá aplikace
obsahuje malou funkci main, kde vytvoří potomka třídy BApplication.
Ta zprostředkuje spojení s application serverem, což je server
starající se o zobrazování (jakési X Window :), pomocí třídy BRoster
zaregistruje aplikaci mezi živé programy a založí nový thread, kde
přijímá zprávy.
Aplikace je nejdříve ve startovacím stavu. Když je vše
zinicializováno, odešle zprávu B_READY_TO_RUN svému BLooperu. Když
se objeví na obrazovce, posílá zprávu B_APP_ACTIVATED.
Dále aplikace ovládá zprávu B_QUIT_REQUESTED, po které se celá
ukončí a zprávu B_ABOUT_REQUESTED, kdy zobrazí okno s informací
o aplikaci.
Po svém startu také aplikace může očekávat zprávu
B_ARGV_RECEIVED, kde ji přijdou parametry z příkazové řádky.
Zajímavé je, že aplikaci lze také nakonfigurovat do režimu,
kdy se spustí pouze jednou. Pokud uživatel znova chce spustit
takovou aplikaci, odešle se pouze další zpráva B_ARGV_RECEIVED.
Trochu nepříjemné ale je, že když spustíte aplkaci v jednom adresáři
a potom v jinem adresáři s parametrem souboru, dostane sice jméno
souboru, ale nedostane adresář, a tak jej nenajde.
Na podobném principu funguje B_REFS_RECEIVED, kde aplikace
obdrží odkazy na soubory, které byly dropnuty na její ikonu.
Pro úplnost ještě uvedu B_PULSE, což je časovač a aplikace si
může objednat, aby jí pulsy chodily v daném intevalu.
Zprávy jsou zpracovávány podobně pojmenovanými handlery v
BApplication, které můžete předefinovat (jsou to virtuální
metody), a tak například zpracovat ARGV apod.
Vypadá to komplikovaně, komplikované to je, ale naštěstí
jednodušší programy nemusí většinu handlerů přepisovat. Jednoduchý
program, co vytvoří okno s tlačítkem, pak vypadá takto:
#include <Application.h>
#include <Application.h>
#include <stdio.h>
#define BUTTON_APP_SIG "application/x-vnd.Be-BasicButton"
// Toto je mime typ aplikace - v BeOS má každá aplikace svůj typ podle kterého
// se identifikuje
// Okno pro button. Sice jsem zatím okna nepopisoval, ale princip je
// jednoduchý. Všichna okna jsou potomkem třídy BWindow. Te se chová tak nějak
// jako BAplikace (zaloři si svůj thread a volá handlery). Ovládá ale navíc
// nekteré nové zprávy a konečně umí do sebe přidat BView object, do kterého
// lze kreslit.
class BTSButtonWindow : public BWindow
{
public:
BTSButtonWindow();
virtual bool QuitRequested();
virtual void MessageReceived(BMessage* message);
private:
BButton* fButton;
};
#define BUTTON_MSG 'PRES'
// Typ zprávy, kterou button po zmáčnutí posílá
// Tady bych čekal malá písmena aby se zabránilo kolizím. Psali to ale velcí
// mistři z Be a tak jim do toho šahat nebudu :)
class BTSButtonApp: public BApplication
{
public:
BTSButtonApp();
virtual void ReadyToRun();
private:
BTSButtonWindow* fWindow;
};
// Starý dobrý main startující aplikaci
main()
{
BTSButtonApp* app = new BTSButtonApp();
// vytvoříme aplikaci
app->Run();
// a odstartujeme to
return(0);
}
// vytvoř aplikaci s danou signaturou
BTSButtonApp::BTSButtonApp():BApplication(BUTTON_APP_SIG)
{
}
// Toto se zavolá, až aplikace dostane zprávu ReadyToRun. Tuto zprávu pošle
// nový BLooper, který se založí po zavolání Run z mainu. Zde se aplikace
// odstartuje
void
BTSButtonApp::ReadyToRun()
{
// Až se aplikace zinicializuje, vytvoř okno
fWindow = new BTSButtonWindow();
// A ukaž ho
fWindow->Show();
}
// Pozice a velikost okna (left, top, right, bottom) a tlačítka v něm
const BRect kWindowFrame (100,100,300,300);
const BRect kButtonFrame (80, 90, 120, 110);
const char* kWindowName = "ButtonWindow";
const char* kButtonName = "Press";
BTSButtonWindow::BTSButtonWindow() :
// vytvoří okno na dané pozici s daným názvem.
BWindow(kWindowFrame, kWindowName, B_TITLED_WINDOW,
B_WILL_DRAW)
{
// Vytvoří tlačítko a nastaví mu prázdnou zprávu typu BUTTON_MSG,
// kterou má poslat až
fButton = new BButton(kButtonFrame, kButtonName, kButtonName,
new BMessage(BUTTON_MSG));
// Umístí jej do okna
AddChild(fButton);
}
// Pokud uživatel zmáčkne zavírací čudlík, okno dostane zprávu
// B_QUIT_REQUESTED. Ta se předá tomuto handleru. Ten chce uzavřít
// celou aplikaci a proto ji pošle ukončovací zprávu. Defaultní
// handler z BApplication ji konečně dorazí
bool
BTSButtonWindow::QuitRequested()
{
be_app->PostMessage(B_QUIT_REQUESTED);
// Defaultní handler z BWindow okno uzavře
return BWindow::QuitRequested();
}
// Do tohoto filteru nerozpoznané zprávy.
void
BTSButtonWindow::MessageReceived(BMessage* message)
{
static int numPresses = 0;
switch(message->what)
{
// Button posíla BUTTON_MSG zprávu.
case BUTTON_MSG:
char title[100];
sprintf(title, "Presses: %d", ++numPresses);
SetTitle(title);
break;
default:
// Ostatní zprávy se pošlou dalšímu filteru
BWindow::MessageReceived(message);
}
}
Jak vidíte aplikace, je přímočará ale krátká není. To je ale
u objektů běžné. U větších aplikací pak tato práce navíc přinese své
ovoce (někdy).
Zajímavosti API
===============
API BeOS je rozděleno do následujících častí:
The Application Kit
zde jsou již zmíněné třídy BApplication, BMessage, BLooper,
BMessenger, BHandler a některé další (BClipboard apod.). Zajímavá
vymoženost je scriptování, pomocí kterého může jedna aplikace řídit
druhou standardním protokolem. Nepodařilo se mi jej ale pořádně
prozkoumat a zjistit k čemu se používá, a tak netuším do jaké míry
je použitelné.
The Device Kit
Api pro práci se seriovými porty, joystickem apod. Není přiliš
zajímavé.
The Game kit
Jakýsi ekvivalent DirectX z Windows. Jsou zde dvě základní
třídy BDirectWindow a BWindowScreen.
BDirectWindow (potomek BWindow), zpřístupní přímý přístup do
videoram v okně (lze také použít ve fullscreen režimu). Použití je
docela jednoduché. Vytvoření je shodné s BWindow, a také lze použít
jako normální okno. Navíc ale má handler zprávy DirectConnected, kde
obdrží ukazatel do videoram, seznam čtverců, které jsou z okna vidět
a pár dalších informací. Potom už může vesele kreslit. Jediná
komplikace je, že DirectConnected může přijít uprostřed kreslení
(pokud se okno pohnulo apod.) a samozřejmě je nutné se domluvit na
tom, kdy už aplikace vzala tento fakt na vědomí. Mně ze zcela
nepochopitelného důvodu se toto potvrzení provádí po ukončení
handleru. Proto je nutné vytvořit zámek pro informace o bufferu a
zamknout jej v handleru a kreslící rutině. Pak ale může vzniknout
deadlock (když se handler vyvolá uprostřed kreslení). Na kreslení je
tedy nutné založit nový thread.
BWindowScreen má také větší část funkcí z BWindow. Po své
inicializaci ale obejde application server a přistupuje přímo
na driver videokarty. Může tedy měnit grafické módy a používat
accelerace. Jinak je ale použití téměř shodné s BDirectWindow.
The Interface Kit
User interface má sice silné stránky - multithreading,
antialiasované fonty, ale je podle mého názoru nejslabší částí
BeOS, a proto se o něm zmíním jenom povrchně.
Narozdíl od XWindow, kde lze zakládat okna v okně, u BeOS se
zakládá pouze hlavní okno. Okna v okně supluje třída BView a hlavní
okno (obrazovku) BScreen. Dlouho jsem přemýšlel nad důvodem této
komplikace a myslím, že to je kvůli threadům. Hlavní okno si zakládá
automaticky thread s BLooperem. Nebylo by ale asi únosné, aby si
takový thread založil každý čudlík (okno v okně).
Opět narozdíl od XWindow se BWindow se zakládá na pevně daných
souřadnicích a pevně daných rozměrech a nikdo mu do toho nemůže
mluvit. Díky tomu se v malých rozlišeních zakládají okna tak, že se
na obrazovku nevejdou a nelze si volit umísťování nových oken.
Do okna se vkládají BView objekty, do kterých lze kreslit.
Ty tvoří stromovou strukturu. Opět ale narozdíl od XWindow BView
na stejné úrovní musí být disjunktní, jinak kreslení a doručování
zpráv do nich má náhodné výsledky (jednou je na vrchu to, jindy
ono).
Zajímavá je implementace resize okna v BeOS. BeOS mění velikost
"živě", tedy okno se rovnou vykresluje v jednotlivých velikostech
(jako v OS/2). Díky tomu je nutné implementovat BView tak, aby po
resize neblikala. Navíc se u BView nastavují flagy, které strany
okna má sledovat. A tak se levý scrollbar nastaví tak, aby se držel
pravého, horního a dolního okraje a po resize se posune přesně tak
jak má.
Nejslabší částí je implementace dialogů. Jednotlivé prvky
(checkboxy apod.) jsou implementovány jako potomci BView. Jejich
umístění se ale udává přímo pomocí souřadnic. To komplikuje život,
protože člověk jednak musí udávat souřadnice přímo v programu, a
také nelze změnit velikost fontů (fonty v BeOS jsou tak malé, že je
v rozlišení 1024x768 a vyšších dost nepoužitelný), nebo délku
stringů (třeba při překladu).
Rozumné toolkity v XWindow fungují tak, že člověk napřed vytvoří
jednotlivé prvky dialogy a potom dodá informace stylu "tuhle skupinu
chci mít nad sebou, tyhle dvě skupiny vedle sebe a pod tím vším dole
skupinu s tlačítkem OK a cancel". Při vytváření dialogu se napřed
vytvoří jednotlivé prvky a potom se jich packer zeptá na doporučené
rozměry, určí podle toho jejich umístění a velikost okna a vše se
vykreslí.
To se snad zlepší v příštích verzích.
The Kernel Kit
Tato část obsahuje standardní sadu funkcí pro práci s thready,
low level posílání zpráv, syncrhonizaci a přístup na hradware.
The Mail Kit
Obsahuje BMailMessage, což je potomek BMessage a slouží
k odesílání zpráv poštou.
The Media Kit
Media kit je opravdu povedený. Jeho úkolem je práce s videem
a zvukem (ale i jinými medii). Základním prvkem je BNode. Speciální
BNode objety (BufferProducer) data produkují (například nahrávají
ze zvukovky) a další BNode (BufferConsumer) je přijímají (například
výstup na zvukovku). Doprostřed lze ale vkládat i další Nody. Nody
lze nahrávat z disku pomocí Add-onů a třída BMediaRoster se stará
k nalezení add-onu pro dané fomráty.
Pokud tedy aplikace chce například přerát zvuk a ukázat
equalizer, vytvoří jednoduchou frontu, kde na začátek dá převáděcí
node ze souboru do zvuku (správný konvertor najde BMediaRosterem),
pak zařadí equalizer a na konec zvukovku. Pak to vše odstartuje a
data potečou do equalizeru a z něj do zvukovky. Data se ukládají do
BBufferu, který je ve sdílené paměti, a proto všechno jde velmi
rychle. Navíc každý BBuffer má hlavičku s časem, a tak je zaručeno,
že equalizer ukazuje práve ty data, co se zrovna přehrávají a nemá
náskok. Až všechny Nody buffer uvolní, je recyklován.
Časování celé produkce je řízeno pomocí objektu BTimeSource,
který se může lišit od systémového času (například u zvukovky je
dobré použít její čas), a proto lze vše provozovat i v dávkovém
režimu (kde consumer například encoduje MPEG) a čas pak plyne tak
rychle, jak to počítač stíhá. Navíc se určuje latence (zpoždění)
celé fronty, a proto se buffery neprodukují zbytečně dopředu.
Rozlišuje se také čas produkce od času aktuálního. Producent vytváří
buffery a nastavuje jim čas produkce (první buffer má čas 0,
druhý čas zvětšený o 1000000/framerated atd.). Produkční čas se pak
posune na čas normální, ve kterém se přehrává. Pomocí času produkce
lze producenta požádat o seekovaní. Také lze vytvořit jiné prepočty
a hrát zrychleně, zpomaleně nebo pozadu (U MP3 je to opravdu
legrace).
Zvuková karta je implemntována pomocí dvou nod - audio mixeru,
kam lze připojit libovolný počet producerů a mixer je smixuje
a přehraje a audio input (exkluzivní) sloužící pro nahrávání.
Další zajímavou vymožeností je možnost přidat kontrolovatelné
parametry k nodám. Audio mixer pak exportuje kontrolovatelné
parametry pro hlasitost apod. BeOS umí pro ně vyrobit standardní
dialogy a změny hodnot ukládat a opět přehrávat, a tak to
pravděpodobně lze použít i pro nahrávání produkce.
Midi Kit
Tato knihovna obsahuje funkce pro čtení, zápis a zpracování midi
a docela kvalitní syntetizér.
Network Kit
Tato část se mi zdá dost nepovedená. Knihovna obsahuje v
podstatě normální BSD socket API pro TCP/IP. Implementace není
kompletní a není tu žádná návaznost na ostatní objekty v systému,
messagovací systém a další věci.
OpenGL Kit
Implementace OpenGL (standard pro 3D grafické knihovny). Umí
kreslit jak do okna, tak na obrazovku pomocí WindowScreen.
Support Kit
Tato knihovna obsahuje třídu BArchivable pro ukládání objektů
na disk, BAutoLock BLocker pro zámky, BBlockCache pro implementaci
jednoduché userland cache (nejenom pro soubory), BList pro seznamy,
BPossitionIO pro obecné streamy (soubory co mohou být kdekoliv)
a třídy jako BMemoryIO pro soubory v paměti a BStopWatch pro měření
času
Storage Kit
Práce s filesystémem. Implmentuje BPossitionIO node pro obecné
streamy. Jako svého potomka má potom BFile pro práci se souborem.
Odkazy na soubory se většinou neudávají jako string, ale jako
entry_ref struktura obsahující jméno, inode adresáře a podobné
informace. Zdá se mi to dost nepříjemné.
Dále knihovna obsahuje třídy pro práci s atributy, symlinky
apod.
Translation Kit
Další zajímavá knihovna sloužící pro převod formátů. Umožňuje
psaní add-onů pro převody, a tak existuje například add-on pro
převod tiffu do BeOSácké bitmapy a zpět. Díky tomu všechny grafické
programy v BeOS mohou snadno pracovat s tify. Po přidání translátoru
pro soubory z mého XaoS teď můžu prohlížet fraktály webovým
browserem, nahrávat do kreslícího programu apod. Knihovna také
implementuje standard pro nastavování parametrů převodu, a tak lze
například volit kvalitu u jpeg obrázků.
Data se translatorům předávají jako BPossitionIO stream, a proto
lze převádět téměř cokoliv.
Celkově
=======
Celkově je BeOS zajímavý, ale má i dost problémů. Programování
v C++ mě docela rozčiluje a kód je v něm dost dlouhý. Také některé
věci jsou v BeOS dost nepříjemné (například práce se soubory přes
reference, nebo user interface). Na některých částech je podle mě
vidět, že je navrhovali různí lidé, nebo že je přidali později,
a tak chybí návaznost (MediaKit by mohl být obecnější a nahradit
část StorageKitu a celý TranlsationKit). Také stabilita systému
není nejlepší a při programování jsou rebooty docela časté. Přesto
ale celkově stojí za to a je opravdu zajímavá zkušenost si v něm
zaprogramovat.
výheň