Hlavní navigace

.NET aneb cesta tam a zase zpátky

12. 12. 2011 12:23 zboj

Windows vznikaly od počátku v jazyce C, je proto logické, že i rozhraní pro psaní aplikací bylo (a dodnes je) v céčku. Toto Windows API, později nazývané Win16, nebylo nijak extra dobře navržené, ale protože Microsoft vždy kladl důraz na zpětnou kompatibilitu, vydrželo (v rozšířené formě nazývané Win32) až do dnešních Windows 7 (a jeho podmnožinu najdeme i v Metru).

COM, DCOM, COM+

S rozmachem objektově orientovaného programování začaly vznikat různé nadstavby i nad WinAPI, vesměs v C++. V 90. letech navíc začaly vznikat rozsáhlé objektové systémy založené na komunikaci mezi nezávislými komponentami, v podstatě každá důležitá IT firma měla svůj: Sun měl NEO (přejmenované DOE=Distributed Objects Everywhere), v IBM měli SOM (System Object Model), NeXTStep vytvořil PDO (Portable Distributed Objects) atd. Odpovědí Microsoftu na tento trend byl Component Object Model (COM).

Stejně jako se zkušení vývojáři smáli složitosti kódu pro „hello world“ ve WinAPI, dělali nyní to samé při porovnání COM a PDO, protože v prvně jmenovaném byl kód se stejnou funkčností cca. 10× větší. Dělat s COM bylo vskutku složité a i když později to usnadňovaly některé vývojové nástroje, nikomu tato technologie asi k srdci nepřirostla.

Variantou COM byl DCOM (distribuovaný COM) a nakonec COM+ spojující obě sesterské technologie.

.NET

Když soud zatrhnul Microsoftu upravit si Javu, pustili se v Redmondu do vývoje vlastního virtuálního stroje a jazyka nad ním. V roce 2002 představený .NET s novým C# a knihovnou BCL byly ve své první verzi jen obyčejnou kopií Javy, nicméně v následujících deseti letech byl vývoj značně dynamičtější než u Javy a dnes je Java minimálně o generaci pozadu.

Na přelomu tisíciletí se obecně predpokládalo, že .NET ve Windows nahradí WinAPI a jednoho krásného dne bude i jádro Windows běžet v řízeném kódu (takový experimentální systém v MS skutečně existuje). Bohužel (nebo bohudík) i Windows 7 jsou založené na WinAPI a od MS téměř žádné aplikace v .NET dodnes nemáme. Jiní vývojáři sice občas s něčím v .NET přijdou, ale problémy s instalací runtimu spolehlivě odrazují od .NET, má-li být výslednou aplikaci schopen nainstalovat každý běžný uživatel (o jejichž inteligenci se tu asi rozepisovat nemusím).

Azure a Windows Phone 7

Postavit Azure nad .NET bylo jistě velmi snadné rozhodnutí, Ballmer teď může tvrdit, že .NET je úspěšným projektem, protože na něm jede v rámci Azure spousta aplikací.Povolil tak tlak na WinDiv, jež vždy tíhla k nativnímu kódu, aby více využívala .NET, a zároveň má DevDiv (jež vyvíjí .NET a věci kolem) záminku k existenci.

Proti Flashi se snažil MS bojovat také pomocí .NET a vyvinul Silverlight. Ten se sice na webu neujal, ale našel uplatnění alespoň jako runtime pro Windows Phone 7. Relativní úspěch Azure se ale asi opakovat nebude, neboť ve Windows Phone 8 bude .NET nahrazenen novým WinRT.

WinRT a „nové“ C++

S trochou nadsázky se dá říci, že .NET měl být jednodušší a modernější náhradou za COM. Svým způsobem i byl a v serverovém prostředí bychom těžko hledali lepší konkurenci k Javě. Jenže dnešním trendem jsou mobilní technologie a jak v MS veřejně připouští, .NET se na relativně pomalá zařízení s omezeným množstvím paměti nehodí.

Nástupcem zastaralého WinAPI má být WinRT (jak jsem už zmínil, před několika lety to měl být .NET). WinRT je zbrusu nové jádro s API postaveným na, a teď pozor, staré dobré technologii COM. Největší nevýhodu COM, složitost pro vývojáře, má odstranit „nové“ C++ (píšu v uvozovkách, protože skutečné nové C++ je pro mě C++11), označované dříve WinC++ a nyní C++/CX. Jde o C++ s rozšířenou syntaxí pro COM komponenty (teď se ovšem nazývají WinRT komponenty). Z .NET se do WinRT dostal pouze formát metadat popisující rozhraní komponent. Existuje sice tzv. projekce nového WinRT do C# a VB, jenže jejich knihovna (BCL) je natolik omezená, že existující kód pro .NET bez úprav nepřeložíte.

Microsoft tak během deseti let udělal zajímavé kolečko. Opustil COM, vyvinul .NET a věci kolem, uplatnil jej v serverových produktech a, paradoxně, v operačním systému pro mobily, aby se nakonec pokorně vrátil k nativnímu a jen mírně modernizovanému COM. Nabízí se srovnání s Applem, který šel místo několika veletočů cestou evoluce a od koupě OpenStepu v roce 1996 pracuje stále se stejnou technologií, již postupně modernizuje. Místo bajtkódu se používají „tlusté“ binárky (fat binary), takže lze jeden soubor spustit na různých procesorech (dříve PowerPC a Intel, dnes to samé používají pro ARMv6 a ARMv7), runtime sice nezpracovává bajtkód, ale nemá žádnou nevýhodu oproti VM s JIT, správa paměti je pro programátora stejně nenáročná jako v .NET atd. Buďme rádi, že je Microsoft (nebo aspoň jeho akcionáři) schopen sebereflexe a vrací se k osvědčené technologii.