Robert Carr - 2 (Programmers at Work)

12. 9. 2008 | Tomáš Znamenáček | Rozhovory | 1865×

Bob Carr v dokončení rozhovoru mluví o tom, jak vymyslel koncept aplikace Framework a jak programoval její první verzi. „Mezi nejdůležitější kvality, kterých by se člověk měl snažit dosáhnout, patří něco, čemu já říkám nenápadnost. Uživatelé by měli zapomenout na to, že je mezi nimi a jejich informacemi nějaký program.“

Programmers at Work je kniha 19 rozhovorů s významnými programátory, kteří svou prací a myšlenkami tvarovali podobu dnešních operačních systémů a mnoha dalších aplikací. Ačkoliv vyšla již v roce 1986, rozhovory jsou z velké míry nadčasové a stále velmi zajímavé. Susan Lammers se po více než 20 letech od prvního vydání knihy rozhodla zveřejnit rozhovory na Internetu a dala AbcLinuxu.cz souhlas k jejich překladu a vydání. Kvůli jejich délce bude většina rozhovorů rozdělena na dva díly. Každý rozhovor doplníme o krátký dodatek, ve kterém budou shrnuty další osudy jednotlivých programátorů.

---

Začátek rozhovoru: Robert Carr (Programmers at Work).

Podle všeho to vypadá, že vás baví spíš samotné programování než obchodní stránka věci.

To je pravda, programování mám rád. Důležitější ale je, abych se mohl soustředit jen na jednu věc. Neumím svůj čas rozdělit mezi čtyři různé projekty a dát do každého z nich všechno. Jde mi to líp, když věnuji všechen čas jednomu projektu. Když jsem se snažil dělat hlavního programátora a zároveň pomáhal s vedením firmy, můj čas se dělil padesát na padesát.

Kde jste se naučil techniky, které při práci používáte?

Část jsou zkušenosti, část úvahy. Jsem zvyklý věci zjednodušit až na nějaký základní… rámec, abych tak řekl, a ten pak rozšířit, aby se dal využít ve skutečném světě. A nejsem zbytečně přísný – nečekám, že ten rámec bude bez chyby. Spíš se s jeho pomocí snažím dané téma prozkoumat.

Jsem naprosto zoufalý v matematice, ale asi bych býval spokojený jako fyzik, protože podobně uvažujeme. Fyzici se snaží zjednodušit fyzickou realitu na poměrně malý počet tvrzení a pravidel, s jejichž pomocí se dá realita vykládat a předpovídat. Já dělám totéž se softwarem – hledám základní tvrzení, základní věty.

Myslíte si, že dodržování těchto pravidel dělá dobrého programátora a dobré programy?

Ano. Myslím si, že klíčem k programátorskému řemeslu – a mluvím záměrně o řemeslu, protože věda to ještě není – je najít ta správná pravidla. V informatice existuje jedna klasická disciplína, která se zabývá základními pravidly, které je potřeba najít. Nejlepší programátoři jsou si těchto pravidel obvykle dobře vědomi.

Zmínil jste programování jako řemeslo. Proč je podle vás programování řemeslo, a ne třeba umění nebo věda?

Ono je kombinací všech tří. To můžu říct s jistotou. Rozhodně existují nějaké vysoce vědecké, pevně zakotvené principy, které jsou pro vývoj softwaru obrovsky důležité, ale dobrý software potřebuje víc. Když se například podíváte na náčrtek rozhodovacího stromu, který vedl k návrhu Frameworku, uvidíte, že jsem strávil spoustu času přemýšlením, čmáráním. To je hodně podvědomé práce. A v té je umění. Protože v umění nemůžete u všeho jasně vysvětlit, jak jste k výsledku došli. Z uměleckého hlediska má nejlepší software na svědomí intuice.

Když pomineme intuici, přišel jste při návrhu softwaru na nějaká pevná pravidla?

Za prvé: ve všem, co děláte, je velice důležitá granularita, která by se navíc měla přizpůsobovat řešenému problému. Tohle pravidlo je ve světě vidět na každém kroku. V investování se například objevuje jako pravidlo rozložení rizik – neměli byste všechna svá vejce nosit v jednom košíku a stejně tak nechcete investice rozložit do tří tisíc různých oblastí, protože už byste je nemohli inteligentně řídit. Co se týká softwaru, uživatelé musí mít možnost rozdělit si svou práci a tím pádem i program do samostatných částí. Nemohou pracovat s jednou gigantickou entitou.

Za druhé, granularita se týká dalšího z mých pravidel: homogenity. Architektura by měla být homogenní, neměla by mít moc výjimek a zvláštních případů. Když navrhnete systém, který se efektivně zvládne vypořádat s megabajtovými objekty a stejně dobře s objekty v řádu bajtů, nejspíš bude hrozně složitý. Je lepší se věnovat výhradně těm objektům, nebo těm. Tomu já říkám homogenita.

Další pravidlo se týká rekurze. Rekurze patří mezi ty nejlepší nástroje, které informatika softwaru dala. Nejsilnější software většinou s rekurzí někde uvnitř pracuje a často nabízí i nějaké rekurzivní funkce uživatelům.

Z pohledu vnitřní architektury programu je nejdůležitější práce s pamětí. Jedno z pravidel pro práci s pamětí zní nekopírovat nikdy jedna data dvakrát. U některých programů – mezi které patří i Context MBA – se jedna data objevují na několika různých místech. Moduly, které s nimi chtějí pracovat, si je kopírují k sobě do bufferu. Data tím pádem skončí v různých částech paměti, což je zlo, a to hned z několika důvodů. Máte vyšší spotřebu paměti, protože potřebujete řadu pomocných bufferů. Ale to je to nejmenší. Navíc vám naskočí náklady na vývoj a doba vývoje, protože takový kód se déle píše a ladí. Nejhorší ale je, že když data stěhujete z jednoho bufferu do druhého, ztrácíte pružnost a funkčnost. V každém bufferu s nimi můžete udělat jen jednu jedinou věc – pokud jde například o buffer textového procesoru, můžete pouze zpracovávat text. Naproti tomu když máte data jen v jednom formátu a na jednom místě, program je okamžitě mnohem pružnější.

Máte nějaká pravidla, kterých se držíte při návrhu uživatelského rozhraní?

Mezi nejdůležitější kvality, kterých by se člověk měl snažit dosáhnout, patří něco, čemu já říkám nenápadnost. Uživatelé by měli zapomenout na to, že mezi nimi a jejich informacemi je nějaký program. Až si na program zvyknou, měli by se věnovat už jen svým úkolům – nemělo by se stávat, že se musí zarazit a hledat nějaký příkaz. Nenápadné rozhraní potřebuje především jednotné a předvídatelné příkazy.

Jak se vám u Frameworku podařilo dosáhnout jednoduchého uživatelského rozhraní a zároveň zachovat bohatou funkčnost a vysoký výkon?

Psali jsme naše menu ukázněně a s disciplínou. Každý ví, že přemíra smyslových požitků je spíš prokletí než požehnání. S menu je to stejné. Menu potřebuje disciplínu.

Menu je ideální způsob, jak uživateli nabídnout řadu příkazů. Ale některá menu se větví do absurdních rozměrů. Jsou systémy, které si kvůli příliš rozvětveným menu vysloužily pověst složitých a špatně ovladatelných programů.

U Frameworku jsme se s menu drželi zpátky, takže jsme skončili jen s devíti menu a čtyřmi podmenu. Použili jsme rozbalovací menu, aby bylo vždycky naprosto jasné, kde zrovna jste. Chtěl jsem použít rozbalovací menu místo menu à la Lotus 1–2–3, protože v 1–2–3 nepoznáte, odkud menu vyskočilo – nové menu přepisuje řádek, na kterém bylo to staré. Rozbalovací menu zabírají místo na obrazovce, ale uživatel vždycky ví, kde zrovna je. Ve všech menu máme dohromady pouhých sto příkazů. Wordstar jich má přes 130, Lotus 1–2–3 kolem tří set a Symphony 600.

Museli jste kvůli takové jednoduchosti obětovat nějaké funkce?

Všechna odvětví designu od architektury až po nábytkový design se ustálila na některých principech, které uznávají minimalismus jako skutečnou výhodu a přednost. V několika málo konkrétních případech jsme funkce obětovali, celkově vzato ale ne. Framework nabízí v rámci jednoho příkazu několik funkcí, které se navzájem překrývají. Přišel jsem se zhruba deseti příkazy, které jsou pro většinu aplikací základní – třeba kopírování, přesun, mazání, vytvoření nebo hledání. Rozhodl jsem se například, že textový i tabulkový procesor by měly nabízet stejný příkaz pro kopírování.

Ukradl jsem pro Framework jednu fantastickou myšlenku, na kterou původně přišli v Xeroxu: Všechny příkazy by měly operovat nad daty, která už jsou uživatelem vybraná nebo vyznačená. Říká se tomu „object–verb design“, tedy „nejdřív předmět, potom sloveso“. Kdybyste to vzali naopak (v pořadí sloveso–předmět), vyvolali byste například příkaz pro kopírování a program by se vás zeptal, co chcete kopírovat. Vy byste vybrali nějaký text a program by se zeptal, kam ho chcete zkopírovat. A vy byste tam vyrazili. Neustále byste reagovali na výzvy programu, což je do určité míry příjemné, zvlášť pro nováčky.

Naproti tomu naše příkazy navrhované stylem předmět–sloveso často vydají za deset příkazů z jiné aplikace. Tradiční textové procesory mívají samostatné příkazy pro kopírování slova, věty nebo znaku. My máme jen jeden, protože Framework má velice dobrou funkci pro výběr textu, která efektivně používá kurzorové klávesy.

Které další obory se podle vás mohou hodit při návrhu softwaru? Psychologie, grafický design?

Jazykověda, řekl bych, i když to není na první pohled zjevné. Když dnešní produkty uživatelům předkládají nějaký koncept, informaci nebo zkrátka řekněme nějakou informační ceduli, spoléhají na značně nesrozumitelná slova a ikony. Potřebujeme studovat vědu, která se zabývá komunikací, ať už je to cokoliv. Snažili jsme se tenhle problém ve Forefrontu postihnout. Máme několik neprogramátorů, kteří mají psychologické vzdělání nebo školitelské zkušenosti, a ti náš návrh ohromně obohatili.

Dalo by se na programu pracovat donekonečna, neustále přepisovat, pilovat, měnit?

My bychom nemohli, i když variací na každý program samozřejmě existuje nespočet. V určitém okamžiku se původní struktura nebo vnitřní architektura programu kvůli neustálým změnám uzavře, zkomplikuje. Pak už je další práce na programu příliš složitá, přepisování programu už není moc efektivní.

Abych pravdu řekl, u Frameworku II bychom udělali nejlépe, kdybychom se pouštěli jen do nových implementací a nechali stávající kód na pokoji, protože už je to hodně velký program. Za dva roky zažil přepisování až až. Příště by bylo efektivnější začít znovu, poučit se z nabytých zkušeností a přijít s novou architekturou.

Už několikrát jste se zmínil o vnitřní a vnější architektuře. Mohl byste to rozvést?

Vnější uživatelské rozhraní každého produktu má určitou architekturu, strukturu; své cestičky a zvyklosti. A jako architektura se dá brát i vnitřní struktura programu. Tyto dvě architektury jsou na každém programu ze všeho nejdůležitější. Pohledem na jejich vzájemný vztah a soulad se dá dobře odhadnout definitivní úspěch nebo neúspěch programu.

U nejlepších programů je vnější architektura věrným obrazem té vnitřní. Nejlepším příkladem jsou tabulkové procesory. Ty jsou v paměti obvykle uložené jako síť buněk a s podobnou sítí buněk pracuje i uživatel, takže obě architektury si navzájem bezvadně odpovídají. Jsou „kongruentní“. Tabulkové procesory jsou díky této výhodě velice efektivní, rychlé a přirozené, takže měly na trhu veliký úspěch.

Ale co se stane, když zkusíte nad tabulkovým procesorem implementovat textový procesor? Uvnitř máte jednu architekturu, jenže zvenčí se snažíte o něco diametrálně odlišného, konkrétně o dlouhou, posuvnou roličku papíru. Skončíte s nevalným výkonem a nepraktickým uživatelským rozhraním. Proto neexistuje jediný úspěšný textový procesor, který by byl implementovaný nad tabulkovým procesorem.

A proto jsem při návrhu Frameworku přišel se základním pravidlem, že vnitřní struktura programu musí přesně odpovídat té vnější. Samotný nápad rámců uvnitř rámců asi každému programátorovi připomene stromovou strukturu. Framework je prostě stromová datová struktura, ve které každý rámec ukazuje na své potomky. Jednoduchá, přímočará architektura.

Jaký je váš názor na integrované aplikace obecně?

To je výborné téma. O integrovaných aplikacích se dá uvažovat na mnoha úrovních. Z jednoho pohledu – právě toho, který napadne většinu lidí – jsou integrované aplikace prostě víceúčelový software, který zastane několik samostatných balíků, například tabulkový procesor, grafický editor a textový procesor. Kdyby ale integrovaný software nabízel jen víc funkcí najednou, neměl by oproti integrovanému prostředí (například Microsoft Windows) žádnou podstatnou výhodu. Potřebujete něco navíc. Potřebujete například sdílet data mezi jednotlivými funkcemi a potřebujete snadno přecházet mezi jednotlivými aplikacemi. Říká se tomu přenositelnost zkušeností, což je totéž co jednotnost příkazů.

Přinejmenším dnes mají integrované aplikace oproti integrovaným prostředím výhodu. Lépe se používají a lépe se učí, což plyne z přirozeného rozdělení každého uživatelského rozhraní na dvě úrovně.

Tyto dvě úrovně jsou syntaxe a sémantika. Každé uživatelské rozhraní má svou syntax neboli pravidla, kterými se řídí práce se samotnými příkazy – jak se příkazy uživateli předkládají, jak se vyvolávají a podobně. Jednotnou syntax příkazů dnes umí bezvadně zařídit řada produktů: Macintosh s Toolboxem v ROM, Windows od Microsoftu nebo Gem. Všechny jejich příkazy se vyvolávají podobně, určitou klávesou nebo kliknutím. Funkce jsou různé, syntax jednotná.

Ale pro jednoduché používání je důležitá ještě druhá vrstva, sémantická, která se týká významu příkazu – toho, co s příkaz informacemi vlastně udělá. A jednotnou sémantikou příkazů se většina prostředí nezabývá. Macintosh má dnes řadu databází, z nichž většina funguje úplně jinak než ty zbývající. Jednotná sémantika chybí. Jeden databázový produkt vkládá záznam před kurzor myši, jiný ho přidá až za kurzor. Další myš nepoužívá vůbec a příslušný příkaz má v menu. Jejich sémantika se výrazně liší, takže zkušenosti s jedním databázovým produktem jsou špatně přenositelné jinam, přestože syntax jejich příkazů do velké míry jednotná je.

A dá se vůbec jednotná sémantika při větším počtu funkcí zařídit?

Jsem přesvědčený o tom, že technické řešení dnes neexistuje. Nemáme žádné překladače, vhodně strukturovaná objektově orientovaná rozhraní, knihovní moduly, a dokonce ani obyčejná papírová pravidla, která by se o jednotnou sémantiku postarala. Jednotné sémantiky se podle mě dá dosáhnout jedině tím, čemu já bych asi říkal organizační řešení – úzkou spoluprácí dobrých designérů a programátorů.

Tak jsme to dělali s Frameworkem. Podle recenzentů je Framework jednička v použitelnosti a jednoduchosti učení. To proto, že jsme pracovali společně, jako jeden muž.

V budoucnosti možná zažijeme příklon k softwaru, kterému já říkám komponentový. Budoucí operační systémy budou podporovat modulárnější software, aby se moduly mohly navzájem různě spojovat. Moduly se budou na trh dostávat samostatně, uživatelé si je budou kupovat po jednom a výsledek bude do velké míry sémanticky jednotný. Ale ještě několik let budou moduly muset pocházet od jednoho výrobce, jedné organizace.

Bude nějakou dobu trvat, než si budete moci koupit integrované prostředí, k němu tabulkový procesor od jednoho výrobce, textový procesor od dalšího výrobce, databázi od třetího a přenášet své zkušenosti od jednoho k druhému.

Co standardizace? Nevyřešila by problém jednotné sémantiky standardizace?

Za prvé neexistuje žádný nejlepší způsob, jak vyřešit jednotlivé funkce – ať už jde o tabulkový procesor nebo databázi. A když se snažíte přijít na jednotný návrh příkazů v celé databázi, textovém procesoru nebo tabulkovém procesoru, je to ještě horší. Každá z těch oblastí má své vlastní potřeby a priority. Vy musíte přijít na systém příkazů a navrhnout rozhraní, které vyhoví všem najednou.

Další oblast, ve které mají integrované aplikace nad integrovanými prostředími navrch, je integrace dat. Ta má dvě části. První z nich je vystřihování a vkládání, neboli přesun informací z jednoho modulu do druhého. Tady podle mě odvádí integrovaná prostředí docela dobrou práci – většinou předepisují nějaký způsob, jak se má cut’n’paste dělat, a pokud na něj autor modulu myslel, můžete vzít čísla z tabulkového procesoru a vložit je do textového nebo grafického editoru. Integrovaný software už to nějakou dobu dělá.

Druhou podstatnou stránkou integrace dat je soužití různých typů dat. Můžete mít v jednom dokumentu živou tabulku, po obou jejích stranách živý text a živý graf nakonec? My lidé pracujeme s logickými entitami. Je nám jedno, jestli dokument míchá tabulky, grafiku a text. Pro nás je to jedna logická entita – zpráva o ziskovosti tržního segmentu prostě potřebuje různé datové typy, aby mohla své informace podat přesně.

Jak vidíte budoucnost počítačů? Kam míří, kde budou za pět nebo deset let? Myslíte si, že budeme pracovat se stejnými nástroji, stejnými jazyky?

Dnešní kancelářské programy s námi zůstanou ještě dlouho. Fungují dobře, a proto tu jsou. Když děláme nový systém, ještě pořád vždycky začínáme od nuly. Jedním z našich budoucích úkolů proto bude přijít na nějaký lepší způsob, jak kombinovat samostatné moduly a vytvořit zásobu flexibilních stavebních bloků. Krok tímhle směrem představují operační prostředí, díky kterým už není nutné v každém produktu znovu a znovu implementovat většinu syntaxe uživatelského rozhraní. Z toho důvodu si myslím, že tu s námi zůstanou i operační systémy.

Doufám, že se posuneme směrem ke komponentovému softwaru. Pak si uživatel bude moct nahradit kus programu pluginem od softwarové firmy, která umí lépe dělat třeba textové procesory nebo matematiku v plovoucí desetinné čárce. To bude podle mě trend v příštích deseti letech. Ale je to obtížný úkol, protože tu mluvíme o rozhraních mezi softwarovými moduly – o jedné z nejméně prozkoumaných oblastí návrhu softwaru. Málokdo z nás dokáže napsat opravdu dobré, čisté rozhraní.

Také se těším na den, nejspíš ještě léta vzdálený, kdy se zbavíme prokletí segmentované architektury Intelu 8086. Možná 80386 by to mohla zvládnout. 8086 má své výhody, ale já jsem se většinou potkal jen s nevýhodami. Při vývoji Frameworku nám náklady na vývoj a doba vývoje stouply doslova o 30 procent jen kvůli tomu, že jsme bojovali s rozdělením paměti na různé segmenty (místo abychom mohli pracovat s jedním nepřerušovaným blokem).

Myslíte si, že u programování zůstanete navždycky?

Ne. Doufám, že se mi podaří nějak radikálně změnit obor. Programování umí být návykové. Framework jsem tolik chtěl dostat na trh zčásti kvůli tomu, že se ze mě poprvé v životě stal workoholik. Chtěl jsem být workoholik. Chtěl jsem dosáhnout nějakého cíle, který jsem si určil, a jako workoholik, který práci podřídí svůj život a vztahy, jsem měl větší šanci toho cíle dosáhnout. Ale nechci být workoholik napořád.

Po dokončení původního Frameworku jsem zvolnil, ale doufám, že mě programování nebo nějaká další práce zase pohltí. Mám v oboru ještě dost času, je mi teprve devětadvacet. Teprve za pět nebo deset let bude čas udělat zásadní změnu. Nemusím se omezovat na programování. Umím mluvit, jsem slušně gramotný, mám dobré komunikační schopnosti – mnohem lepší než většina ostatních programátorů. To je velké plus nejen v managementu, ale i v prodeji.

S tak novátorským nápadem, jaký byl Framework, jsem musel od prvního dne prodávat. Nemyslím doslova, ale prodávat svou myšlenku, jasně a stručně ji dokola vysvětlovat. Každý člověk, kterému jsem program ukázal, musel dostat vysvětlení, v čem je program jiný a lepší. Framework zčásti uspěl kvůli tomu, že jsme s mým společníkem a spoluzakladatelem firmy Marty Maznerem – který je spíš obchodník – dokázali spojit technický pokrok s jeho přesvědčivou prezentací.

¶

© Susan Lammers 1986–2008, přeloženo s laskavým dovolením autorky.

¶

Framework byl dokončen v roce 1984 a na několik let kraloval žebříčkům prodejnosti softwaru pro osobní počítače. Byl prvním kancelářským balíkem pro PC s DOSem.

V roce 1987 založil Robert Carr s několika společníky novou firmu jménem Go, která se zabývala vývojem softwaru pro přenosné počítače a PDA. Firma příliš předběhla svou dobu, protože musela veřejnost o užitečnosti přenosných počítačů namáhavě přesvědčovat a musela dokonce přijít s vlastním hardwarem. Její hardwarová divize se osamostatnila a záhy ji spolkla firma AT&T, pro jejíž hardware nakonec firma Go napsala operační systém PenPoint (screenshot GUI). Na přelomu osmdesátých a devadesátých let opadl zájem o přenosné počítače a tablety definitivně, a tak firma Go i přes proinvestovaných 75 miliónů dolarů v roce 1994 zavřela.

V letech 1997–2003 Carr pracoval pro investiční firmu Sofinnova Venture, ve které společně se svými čtyřmi partnery spravoval přes půl miliardy dolarů rizikového kapitálu. V roce 2003 založil startup Keep and Share, který nabízí sdílení dat po Internetu.

       

Komentáře

[deda.jabko]

Říká se tomu „object–verb design“, tedy „nejdřív předmět, potom sloveso“.

zajimave... z tohoto pohledu konstrukce: "cat foo | grep bar", dava docela smysl... at si pocitaci zbytecnych ,,catu'' rikaji, co chcou...

Framework je prostě stromová datová struktura, ve které každý rámec ukazuje na své potomky. Jednoduchá, přímočará architektura.

skoda, ze tomu panovi nikde neukazal LISP, asi by mu udelal velkou radost.

Podle recenzentů je Framework jednička v použitelnosti a obtížnosti učení.

to je hodne nestasne formulovana veta... nicmene, do jiste miry mne to pripomina skupinku *fasistu, kteri testovali pouzitelnost tak dlouho, az se jejich programy staly nepouzitelne (teda aspon imho) ;-]

[zoul]

to je hodne nestasne formulovana veta...

Jé, pravda, pardon. Podle recenzentů se Framework dá snadno naučit i používat, takový byl význam původní věty.

[Hynek (Pichi) Vychodil]

cat je verb! Takže opět špatně, cat je zlo!

<foo grep bar

Když už, tak pořádně.

[Hynek (Pichi) Vychodil]

A vůbec, ta věta anglicky zní pčíkaz: 'grep bar in foo', zapisovat to jako 'in foo grep bar' mi přijde pěkně matoucí. Když už, tak 'Co dělat?' 'bar grep in foo' a to už vůbec nejde. Takže já si budu dál zapisovat pěkně anglicky:

grep bar foo

Zbytečný cat je zlo!

[zoul]

cat je verb!

cat je totéž co výběr textu, o kterém se mluví v rozhovoru. Sloveso říká, co se má stát s vybranými daty, to je grep.

[Jary]

Jenže ono ne. cat znamená "spojit". Concatenate.

[Mazarik]

"cat foo" je v tomto pripade ako oznacenie textu v textovom procesore.

"grep bar" je vykonanie nejakej akcie nad oznacenym textom.

 

Podla mna ide tiez o to, ze v nasej kulture piseme a citame zlava doprava, takze je prirodzenejsie (urcite pre mna) napisat "cat foo | grep bar" resp. "grep bar foo" ako vselijake pazlozeniny s "<".

[TM]

Na Framework si velmi dobře pamatuji. Myslím, že šlo o verzi IV. Na samém počátku 90.let jej používal jeden velký český strojírenský podnik(bylo to samozřejmě normálně licencované, žádná ušmudlaná kopie bůhvíodkud, jak bylo tehdy u nás zvykem). Na některých PC tam tehdy běžel OS/2 a s Frameworkem v něm byly problémy, takže v těchto případech nezbývalo nic jiného než dualboot a pouštět Framework v DOSu, což byla škoda....
Jinak byl Framework zajímavý software a fungoval velmi dobře. Udělal tam tenkrát během pár let spoustu práce.