[devPortal] Tegnap egy nagyon érdekes cikket olvastam az Arstechnica weboldalán a Windows 8-al kapcsolatosan. Annyira jónak találtam, hogy elhatároztam, lefordítom. Szerintem nagyon ott van a szeren, és rendkívül fontos hiányt pótol. Remélem, ti is sok hasznos információt találtok benne. A cikk szerzője Peter Bright.
Június elején a Microsoft egyfajta bombát hajított a Windows fejlesztők közé: az új Windows 8 érintésre működő, a felületbe ágyazott alkalmazásstílusa nem a .NET platformra épül, annak ellenére, hogy az elmúlt tíz évben a Microsoft ezt a platformot evangelizálta. Ehelyett ezek az alkalmazások HTML5-öt és JavaScriptet fognak használni. Azóta az óriáscég folyamatosan elzárkózik attól, hogy további megjegyzéseket fűzzön ehhez a témához. Az egyik legfontosabb kérdés, amely a Windows fejlesztők legnagyobb aggodalmát fejezi ki – “hogyan is fogom ezután a meglévő tudásomat és képességeimet ezeknek az új alkalmazásoknak a kifejlesztésére használni?” – továbbra is megválaszolatlan maradt, a cég nem tervezi hogy bármilyen további részletet felfedne ehhez kapcsolódóan a szeptemberi BUILD konferencia előtt.
A helyzet valószínűleg nem olyan vészes mind amennyire sok fejlesztő annak tartja. A Windows 8 korai változatai kiszivárogtak az internetre, és rengetegen foglalkoztak azzal, hogy ezekből kitalálják a Windows 8 működésének lényegét. Bár hivatalosan hallgatnak róla, sok apró információmorzsa hagyta el a redmondi falakat. Mindezidáig úgy tűnik, hogy a Windows 8 nemcsak hogy nem néz ki rosszul, arra utaló jelek vannak, hogy tulajdonképpen sok régóta jelenlévő apró bosszúságot fog megoldani a Windows szoftverek készítése kapcsán. Ha a Microsoft mindent sikeresen végigvisz, amit a platformmal szeretne elérni, a Windows 8 megjelenése olyan jelentős változást hoz, mint amilyent a Windows Loghorn változatának kellett volna.
Mielőtt rátérnénk arra, hogy mit is csinál a Microsoft a Windows 8-cal, szükségünk van egy kis háttérinformációra. Ahhoz, hogy megértsük a víziót és annak eltávolodását a múlttól, szükséges a jelenlegi helyzet megértésére.
A .NET 2002-es bemutatkozása előtt a Windows alkalmazások két módon készültek. A “nagy” alkalmazások – gondoljunk csak az Office-ra, Photoshopra, vagy a Netscape Navigatorra – alapvetően a Win32 API és C++ használatával íródtak. A Win32 egy nagyméretű API, amely az alapfunkciók jeletős részét biztosítja. Rengeteg “nyilvánvaló” dolgot tartalmaz, mint például a grafikát és a felhasználói felület létrehozását, a hálózati kommunikációt, hozzáférést a fájlrendszerhez, és egyéb ezoterikus dolgokat is, mint például a biztonsági mentés készítését, a hálózati beállításokat, vagy a biztonság kezelését.
Az API nagy, rengeteg mindent csinál, de sok olyan fontos dolog van, amit nem csinál jól, és sok olyan, amit meg egyáltalán nem. Például, annak ellenére, hogy a Win32 tartalmaz az adatbázisok elérésére API-t (igazából többet is), igencsak babramunka egyszerű Win32-t használni olyan alkalmazások megírására, amelyek sok adatbázisműveletet végeznek. Sokkal problémásabb az, hogy bár tartalmazza az alapeszközöket amelyekre a grafikus felhasználói felület elkészítése miatt van szükségünk, azt mégsem teszi egyszerűvé. Például, semmilyen támogatást nem ad a felület elrendezésére. Minden egyes nyomógombot, szövegdobozt a fejlesztőnek kell elhelyeznie a felületen. Ha szeretnénk azok pozícióját megváltoztatni az ablak átméretezésével, hát akkor azt bizony saját magunknak kell megtennünk. Sok olyan könyvtárat fejlesztettek ki, amely beáll az operációs rendszer és a fejlesztő közé, hogy ezt a feladatot egyszerűbbé tegye, köztük a Microsoft saját MFC-je (Microsoft Foundation Classes) is, de túl gyakran még mindig túl mélyre kell merülni a Win32-be ahhoz, hogy a dolgok úgy működjenek, ahogyan azt szeretnénk.
A másik fő módja a Windows alkalmazások készítésének a Visual Basic volt. A Visual Basic néhány feladatot nagyon egyszerűvé tett, különösen az adatbázis eléréséhez és a felhasználói felület kialakításához kapcsolódóakat, és az üzleti világ egyik fontos jellegzetességévé vált. Rettenetes mennyiségű üzleti alkalmazás kering a világban, amelyek nem csinálnak sokkal többet annál, minthogy előrántják az adatot az adatbázisból, megmutatják a felhasználónak és űrlapokat biztosítanak az adatok szerkesztéséhez. Ezekre a feladatokra a Visual Basic kiválóan alkalmas volt. Ennél többet egyetlen fontos dolog kapcsán sem nyújtott. Némi támogatást kínált a Win32 szintű függvények hívásához, alapvetően azokhoz, amelyek a Win32 működésével összefüggő konstrukciókat használtak.
A Visual Basic-ből szintén hiányzott a népszerű objektum-orientált paradigma támogatása, amit megvalósított, az csupán “objektum-alapú” paradigmának nevezhető.
.NET megjelenése mindent megváltoztatott. A .NET a Visual Basic felhasználásának egyszerűségét biztosította, de mindezt a Visual Basic által teremtett kompromisszumok nélkül. A Visual Basic-hez hasonlóan jó eszközöket kínált a felhasználó felületekhez és az adatkapcsolat megvalósításához, és messzemenően alkalmas volt üzleti alkalmazások készítésére. A Visual Basic-kel szemben, a .NET a Win32 elérését – még akkor is, ha ez egy kissé félszeg opció –, sokkal egyszerűbbé tette. A platform gyorsan magához vonzotta az üzleti fejlesztőket és néhány új kereskedelmi célú projekt is szintén használatba vette azt.
A Windows XP, amely egy évvel a .NET előtt jelent meg, meglepő módon nem használta ezt a technológiát. De ahogyan azt a Microsoft a 2003-as PDC-n bejelentette, ezt a helyzetet a majdan megjelenő Windows Longhorn kívánta megváltoztatni. A Loghorn integrálta volna a .NET-et a Windows platform magjába. A .NET keretrendszer, amint az a Microsoftos körökben ismert volt, a WinFX, vagyis a Windows hasonló technológián alapuló keretrendszere felé mutatott volna. Egyebek között a Longhorn egy vadonatúj utat kínált volna a felhasználói felület tervezésére – ez Avalon kódnéven futott, amely modern, vektoralapú és hardveresen gyorsított lett volna. A Windows saját maga úgy lett volna megírva, hogy a felhasználók által látható programjaihoz – az Intéző, a Számológép, stb. – a WinFX technológiát használta volna, és a .NET lett volna “a” módja a Windows alkalmazások készítésének. A Win32 továbbra is létezett volna a visszamenőleges kompatibilitás megőrzése végett, de annak állapotát befagyasztották volna.
A Longhorn lehetett volna a vége a Windows alkalmazások régi módon való írását jellemző korszaknak, és a hajnala a modern Windows fejlesztés egy új korszakának, egy olyan platform, amelyet nem bénítottak volna meg a tíz vagy tizenöt évvel korábban hozott tervezői döntések.
Amint azt mindannyian tudjuk, a Longhorn soha nem készült el. A projekt áttekinthetetlenül nagyra nőtt, kezelhetetlenné vált. Nagyjából abban az időben a Windows XP, amelyre egyébként a Longhorn épült, hekkerek támadásának a célponja lett. A Microsoft ráöntötte az erőforrásait a Windows XP és a Windows Server 2003 elfogadható biztonságúvá alakítására – ezek a Windows XP Service Pack 2-ben és a Windows Server 2003 Service Pack 1-ben tetőztek, majd megint mindent előről kezdve hozzáfogott a következő operációs rendszerének fejlesztéséhez, amely végül is a Windows Vista lett.
Ennek az újrakezdett fejlesztének a legnagyobb vesztese a .NET volt. A Windows Vista, bár radikálisan új dolgokat hozott néhány tekintetben, szakított a teljes WinFX koncepcióval. Az Avalon elkészült – ez ma Windows Presentation Foundationként (WPF) ismert, de ez csak egy kiegészítő komponense volt az operációs rendszernek, nem pedig annak magjához tartozott. A Windows Vista és Windows 7 egyetlen jelentős .NET kódja a Media Center (amely még a WPF-et sem használja). Minden más a jó öreg Win32-re épül. Még sokkal fontosabb, hogy a Win32 API-t módosították és kiterjesztették. Számtalan alacsony szintű képességet adtak a Win32-höz, és a megváltozott grafikus felhasználói felület támogatásához, mint például a Windows tálca az Aero Glass téma. A felhasználói felület egyetlen újdonsága sem működött jól együtt a WPF-fel.
Néhány tényező vezetett ehhez a döntéshez. Egy része a kapkodás volt, nem volt idő arra, hogy mindent újraírjanak a .NET használatára. De talán sokkal fontosabb tényező volt a Microsoft belső divízióinak szerkezete. A Windows-ért a Windows divízió (WinDiv) a felelős. A .NET a fejlesztői divízió (DevDiv) gyermeke, és ez a divízió a Szerverek és eszközök üzletág része. Bár az ember azt hihetné, hogy ezeknek a csoportoknak a kitűzött céljai egy irányba mutatnak, ez nem így volt. Nem feltétlenül rosszindulatból, az egyes csoportoknak egyszerűen különböző prioritásaik voltak.
Néhány prioritásnak volt értelme abban az időben. Például, a WPF-et csak a .NET programok tudják használni, és csak azokkal működik jól együtt, amelyek C#-ban vagy Visual Basic-ben íródtak. A teljes API a tetejétől az aljáig nem érhető el a natív C++ programokból, és így jelentős erőfeszítéseket igényel a natív programok WPF-re migrálása. Ennek volt értelme, ha az összes jövőbeli fejlesztést az ember a .NET-tel szándékozott végigcsinálni. Azonban, ha a tervek megváltoztak és újra a natív kódot használó fejlesztői környezethez kellett visszatérni, ez komoly problémát jelentett. A Microsoft nem tudta felhasználni a vektoralapú, felbontásfüggetlen és hardveresen gyorsított WPF könyvtárat egyetlen alapvető operációs rendszer alkalmazás készítésére sem.
Más prioritások egyszerűen más irányokba terelték a csoportokat. Így például, a fejlesztői divízió prioritása az volt, hogy a .NET platformot hitelessé tegye a fejlesztők között. Ez azt jelentette, hogy alapvető funkcionalitást, fejlesztői könyvtárakat és eszközöket hoztak létre – mint például, a Silverlight. A Windows divízió prioritásai a már korábban is említett C++ kompatibilitás, a robusztusság, és bizonyos technikai hibák kijavítása volt. Mindegyik célnak volt értelme, de mivel a fejlesztői divízió céljai nem illeszkedtek a Windows divízió céljaival, a Windows divízió céljai nem kaptak elegendő hangsúlyt. Az eredmény az lett, hogy a Windows divízió menedzsmentje nem igazán örült a .NET-nek és boldog volt, hogy átléphet rajta.
A .NET soronkövetkező változatai javítottak ezen a helyzeten, a C++ kérdés kivételével gyakorlatilag minden kérdést megoldottak. De a korábbi sebek már ott voltak, a Windows divízió – miután elégedetlen volt a fejlesztői divízióval –, figyelmen kívül hagyta annak eredményeit, és a Windows 7, csakúgy, mint az elődjei, a .NET-et csak a Media Centerben használja. A Windows 7 új API-jai egytől-egyig mind natív C++ API-k, nem fogyaszthatók közvetlenül a .NET programokból, és a natív C++ programok még mindig nem férnek hozzá a felbontásfüggetlen, vektoralapú, hardveresen gyorsított keretrendszerhez, hogy azzal készítsék el a felhasználói felületet. A Windows 8 ennek véget vet.
A Windows 8 két futásidejű környezettel együtt érkezik: Egy új .NET-tel (ez jelenleg a 4.5-ös verziószámot viseli) és egy natív kódú C++ környezettel (technikailag ez COM, illetve annak leszármazottja), amelyet WinRT-nek neveznek. Lesz benne egy teljesen új felhasználói felület könyvtár, a DirectUI, amely a natív Direct2D és DirectWrite API-k tetejére épül, ezeket a Windows 7 vezette be. A Silverlight egy új változata, amely jelenleg a Jupiter kódnévre hallgat, a Direct2D felett fog futni. A WinRT és a DirectUI közvetlenül elérhetők lesznek a .NET-ből a beépített csatolókon keresztül.
A WinRT egy letisztult és modern API-t ad sok dologra azok közül, amelyeket a Win32 jelenleg is megvalósít. Sok szempontból, ez egy új, modern Win32 lesz. Az API-t úgy tervezték, hogy azt könnyen lehessen használni “modern” C++ nyelvből (kontraszként a Win32 API 25 éves, erőteljesen C-súlypontú tervezésével szemben). A WinRT szintén letisztult módon vetíthető le a .NET koncepcióira is. A Windows 8-ban valószínűleg a WinRT nem for mindent lefedni, amit a Win32 biztosít – a Win32 olyan kiterjedt, hogy azt modernizálni rengeteg energiát igényel –, de nekem azt mondták, hogy ez a végső, hosszútávú cél. És a WinRT minden egyes Redmondból kiszivárgó változatában egyre és egyre kiterjedtebbé válik.
A WinRT nemcsak egy kissé szebb változata a létező Win32 API-nak! A Microsoft megragadja a lehetőséget, hogy az API funkcionalitását is továbbfejlessze. A vágólap API (Clipboard API) például könnyebben kezelhetővé és rugalmasabbá válik. Szintén meggyőző támogatást kapnak benne az aszinkron műveletek, letisztult és konzisztens módon kezelve a hosszan futó háttérfolyamatokat.
A DirectUI a jelenlegi WPF/Silverlight technológiák magja köré épül. Tartalmazza a XAML-t – az XML nyelvet, amely a felhasználói felületek elrendezésének leírására szolgál – és olyan gazdag felületi elrendezéseket támogat, amelyek a Win32-ben soha nem léteztek. Ez a mag jelenti a C++ programok számára a modern felhasználói felület eszközkészletét, és a szívében ugyanaz az eszközkészlet lesz, amelyet a .NET fejlesztők is használhatnak. (A DirectUI egy olyan név, amelyet a Microsoft korábban már használt a cégen belül, a Windows Live Messenger grafikus könyvtárának neveként. Az új DirectUI-nak, úgy tűnik, ehhez a régihez nincs köze.)
A Jupiter lényegében a Silverlight 6. Minden képességgel rendelkező rugalmas eszközkészlet alkalmazások készítésére. A pontos kapcsolat a DirectUI és a Jupiter között ebben a pillanatban még nem teljesen tiszta. Lehetséges, hogy ez egyetlen és ugyanaz – és a DirectUI funkcionalitása egészen addig nő, amíg mindenre képes nem lesz, amit a Sliverlight is tud. Szintén lehetséges az is, hogy a DirectUI csak az alapvető funkcionalitást valósítja meg és a tetejére egy sokkal teljesebb keretrendszer ül. Egy másik lehetőség az, hogy a Jupiter konkrétan a felületbe beülő teljes képernyős érintés-vezérelt alkalmazások motorja lesz.
A XAML és a WPF-szerű, illetve Silverlight-szerű grafikus felhasználói felület fejlesztés abszolút központi eleme lesz a jövőbeli Windows fejlesztéseknek. Ezek újszerű fontosságának testamentuma az átszervezés, amely a hét elején történt. Ahelyett, hogy a fejlesztői divízió alatt működne tovább, a XAML csapatot három részre vágták. Az a csoport, amely a XAML és a csatlakozó technológiák Windows-beli használatán dolgozott, a Windows divízió alá került át. A Windows Phone-on, az Xbox-on és a böngésző plug-inen dolgozó csoport a Windows Phone alá került. Csak az a csoport maradt a fejlesztői divízió alatt, amelyik a fejlesztői eszközökkel – beleértve a Visual Studiót és az Expression Blendet – foglalkozik. A belső Microsoft email, amely a változásokat jelenti be megjegyzi, hogy a XAML csapat a Windows csapattal dolgozik a Windows 8 fejlesztésének időszakában; vagyis ez a változás formálisan a felhasználói felülettel foglalkozó csapat részéve teszi őket.
Mire is szolgál ez az egész? Ez egyenrangúságot biztosít a C++ és a felügyelt .NET kód számára. Ahelyett, hogy azok egymástól szétválasztva külön, képességeiknek és erősségeiknek megfelelően fejlődnének, társak lesznek. Amennyiben a Microsoft új API-t ad a Windows magjához, a WinRT rendszer biztosítja, hogy azok egyszerre elérhetőek legyenek felügyelt kódból, biztosítva, hogy a .NET fejlesztők ne legyenek hátrányban a natív kóddal dolgozókkal szemben. Hasonlóan, a létező natív alkalmazások átalakíthatók az új felhasználói felület használatára anélkül, hogy azokat lényegében újra kellene írni .NET-ben. Ugyanez a rugalmasság a Microsoftot is érinti: a natív és a .NET kódot egyenrangúvá téve megnyitja az ajtót az előtt, hogy a kibocsátott operációs rendszer .NET alkalmazásokat is tartalmazzon.
Ezzel a képességgel felruházva akár az Office 15-öt is úgy láthatjuk – először az elmúlt tíz, vagy talán annál is több évben –, hogy az a szabványos Windows felhasználói felületet használja azon sajátosan testreszabott front-end-ek helyett, amelyeket az elmúlt években megismerhettünk.
Kevésbé nyilvánvaló az, hogy mi is fog történni a WPF-fel. A WPF és a Silverlight gazdája ugyanaz a csoport a Microsofton belül, de a Silverlight nagyobb piaci sikert ért el, mint a teljesebb WPF. A WPF olyan képességekkel is rendekezik, amelyekkel a Silverlight nem, így szégyen volna, ha ez a bővebb képességhalmaz nem kapna helyet a Windows 8 szép és új világában. A WPF és a Silverlight egy folyamatosan konvergáló útvonal mentén fejlődtek, és lehetséges, hogy a Jupiter megszünteti a két technológia között még megmaradt különbségeket.
A WPF karcsúsításának és a Silverlight szerepének bővítése ésszerűnek tűnik a Microsoft széles fejlesztői ökoszisztémájának ismeretében. A Silverlight egy változatát használják a Windows Phone fejlesztésre, és bizonyíték van arra is, hogy a Silverlight egyfajta Xbox-os változatán is dolgoznak. A Silverlight támogatása a Windows-on, a Windows Phone-on és az Xboxon hosszú távon alátámaszthatná a Microsoft “három képernyő (számítógép, tévé, telefon) és a felhő” ambícióját, amely a szoftvereket és a felhasználói élményt a három környezet közötti zavartalan együttműködésre képesnek látja.
Az a kérdés, hogy ennek a három képernyőtípusnak a támogatása mennyire kiegyensúlyozott, egyike a sok megválaszolatlan kérdésnek. A Windows Phone fejlesztők hosszú ideje aggódnak, hogy a Windows tablet, az iOS és az Androidos versenytársakkal szemben nem fogja közvetlenül támogatni a Windows Phone alkalmazásokat. Mind a Windows, mind a Windows Phone a Silverlight-ot használja, de a telefon egy jó adag telefon-specifikus funkcionalitást ad, amelyeknek jelenleg nincs megfelelőjük a Silverlight asztali környezetében.
Az igazán nagy aggodalmat a Windows 8 kezdeti bemutatásának pár héttel ezelőtti eredménye okozta, amely azt vetítette előre, hogy az új stílusú, a Windows felületébe beülő alkalmazások csak a HTML5 és JavaScript fejlesztők számára lesz elérhető. A bemutatón használt nyelvezet alapján az új fejlesztői környezet a HTML5-re és a JavaScriptre “épül”, és ez nagy hullámokat vert a teljes Silverlight fejlesztői közösségben. Egyedi vitaszálak indultak a kérdés kapcsán a fórumokon, amelyek válaszok százait fogadták és tízmilliós találatokat produkáltak – ezek nagyobb forgalmat generáltak, mint amennyit a fórum többi része az egész hónap alatt. A Windows fejlesztők beépülő alkalmazásokat akarnak építeni, de nem akarják, hogy a HTML5 és a JavaScript használatára legyen szükségük ehhez.
Nem is kell ezeket használniuk! Szeretnél egy beépülő alkalmazást írni natív C++ kódban? Ez nagyszerű! C#-ot és Silverlightot szeretnél használni? Ez szintén nagyszerű! Mindkettőt támogatva lesz! Anélkül, hogy magunkra maradnánk az ősrégi asztali alkalmazásokkal – mert sokakban ezt a benyomást keltette a prezentáció – a C++ és a felügyelt C# egyaránt elsőrendű lehetőségek lesznek a beépülő alkalmazások fejlesztésére, érintés-támogatással, tablet-barát Windows 8 stílusú alkalmazások fejlesztésére.
Mi a helyzet a HTML5-tel és a JavaScripttel? Ezek szintén a lehetőségek közé tartoznak. A Microsoft már korábban a HTML alkalmazások ösvényére merészkedett a HTA technológiájával. A HTA-k (HTML alkalmazások) olyan HTML, JavaScipt, CSS és egyéb erőforrásokat tartalmazó csomagok, amelyek egy speciális “trusted” módban futnak. Azok a normál korlátozások, amelyek a megszokott HTML weblapok múködését irányítják – például, a helyi erőforrások használatának a hiánya – nem érvényesek a HTA-kra: egy HTA írhat a fájlrendszerbe, hozzáférhet tetszőleges hálózati erőforrásokhoz, és egyebekhez is. Más szavakkal, a HTA-k olyan weblapok, amelyekből kikerültek azok a limitációk, amelyek a weblapokat képtelenné teszik arra, hogy az asztali környezeteket felváltsák.
Az új stílusú HTML5 beépülő alkalmazások nem HTA-ként kerülnek fel az eszközökre, de a HTA elvekből sokminden valószínűleg alkalmazásra kerül. Amint a HTA-k korábban, a HTML5 alkalmazások is nagyobb hozzáféréssel fognak rendelkezni az operációs rendszer funkcionalitása kapcsán, mint a szokványos weboldalak – és így képesek lesznek a Windows API-k használatára. A felhasználói felületük kevésbé lesz webapnak érezhető, annál inkább egy natív alkalmazásnak. A képességeiket tekintve azon a szinten lesznek, mint a .NET-ben készült és a natív programok. Egyszerűen csak HTML5-öt és JavaScriptet fognak programozási modellként használni. Az eredmény valami olyasmi lesz, amit a webfejlesztők már megszoktak, de azon funkcionális hiányosságok nélkül, amitől egyébként a legtöbb webalkalmazás szenved.
Távolról sem lesz a Windows 8 fejlesztői szemmel katasztrófa, hanem inkább egy nagy előrelépés: egy olyan változat lesz, amely azzal fenyeget, hogy a fejlesztés gyönyörét kínálja a natív, felügyelt kódot és webes technológiákat használó fejlesztőknek egyaránt. A .NET és a natív világ egyesítése; a hardveres gyorsítás elérhetősége; letisztult és modern API-k, Az Avalon, mint elsődleges megoldás a Windows felhasználói felület létrehozására – mindaz, amit a Loghorn WinFX-e már korábban megígért, de ezúttal úgy látszik, hogy mindez meg is történik.
Hogy mindez miért vezet Microsoftos “adásszünethez”, igen nehezen érthető. A cég tisztában van azzal, hogy HTML5 és JavaScript üzenetét a közösség vette, de az a hozzáállása, hogy nincs is igazi probléma; a megrázó, horrorisztikus reakció csupán a bloggerektől érkező túlfűtött dolog. Azt a döntést, hogy nem mondanak semmi mást, mint azt, hogy “várjatok a BUILD konferenciára szeptember közepéig” már többször megvitatta és újratárgyalta a cég, a legfelsőbb szinteken is, de jelenleg a korábbi döntés érvényben marad: nem mondanak semmit, a fejlesztőket bizonytalanságban tartják.
Úgy vélem, ez a hozzáállás már másfél hete bűzlik, és még ma is büdös. Az a több tízmillió találat, amelyet a Silverlight fórumok értek el, nem nevezhetők felfújt blogőrületnek. A Windows Phone fejlesztők ma is azt mondják, hogy a Microsoft árokba fordítja a platformot a jövőjének bizonytalansága miatt, és ez nem nevezhető túlfűtött blogger üzenetnek! Amikor egy korábbi Microsoftos projektmenedzser – aki a WPF-en és a Silverlighton egyaránt dolgozott – azt mondta, hogy az Adobe hasonló Flex/Flash eszközkészletére fog váltani, mert az Adobe legalább elkötelezte magát abban az irányban, nos ez egyáltalán nem afféle blogolós dolog.
Érthető, hogy a Microsoft nem akar mindent most azonnal ránk önteni. A Windows 8 előtt még mindig hosszú út áll, mire befejezik, és rengeteg dolog változik mostantól a BUILD konferenciáig is. De a fejlesztők nem azt mondják, hogy mindent most azonnal hallani akarnak, csupán néhány szembetűnő részletről szeretnének egy kicsit többet tudni. Két kérdés megválaszolása valószínűleg kezelné a helyzetet. Lehetséges lesz beépülő alkalmazásokat készíteni C++ vagy .NET használatával? Lehetséges lesz ilyen alkalmazásokat írni XAML-ben?
Mindaddig, amíg a jelnelegi irányvonal nem változik meg radikálisan a BUILD után – bár ez még csak egy előzetes szoftverváltozat, szóval, ha nem is lehetetlen, de valószínűtlen, hogy ez történik – a válasz mindkét kérdésre az “igen”, és az, hogy a Windows 8 fejlesztői élmény minden idők legnagyobb előrelépése lesz a 32-bites Windows API 1993-as megjelenése óta. Ez egy izgalmas kilátás, de a Microsoft semmit nem nyer vele, ha a kétségeket továbbra is lebegni hagyja.
Egy kis történelem
Mielőtt rátérnénk arra, hogy mit is csinál a Microsoft a Windows 8-cal, szükségünk van egy kis háttérinformációra. Ahhoz, hogy megértsük a víziót és annak eltávolodását a múlttól, szükséges a jelenlegi helyzet megértésére.
A .NET 2002-es bemutatkozása előtt a Windows alkalmazások két módon készültek. A “nagy” alkalmazások – gondoljunk csak az Office-ra, Photoshopra, vagy a Netscape Navigatorra – alapvetően a Win32 API és C++ használatával íródtak. A Win32 egy nagyméretű API, amely az alapfunkciók jeletős részét biztosítja. Rengeteg “nyilvánvaló” dolgot tartalmaz, mint például a grafikát és a felhasználói felület létrehozását, a hálózati kommunikációt, hozzáférést a fájlrendszerhez, és egyéb ezoterikus dolgokat is, mint például a biztonsági mentés készítését, a hálózati beállításokat, vagy a biztonság kezelését.
Az API nagy, rengeteg mindent csinál, de sok olyan fontos dolog van, amit nem csinál jól, és sok olyan, amit meg egyáltalán nem. Például, annak ellenére, hogy a Win32 tartalmaz az adatbázisok elérésére API-t (igazából többet is), igencsak babramunka egyszerű Win32-t használni olyan alkalmazások megírására, amelyek sok adatbázisműveletet végeznek. Sokkal problémásabb az, hogy bár tartalmazza az alapeszközöket amelyekre a grafikus felhasználói felület elkészítése miatt van szükségünk, azt mégsem teszi egyszerűvé. Például, semmilyen támogatást nem ad a felület elrendezésére. Minden egyes nyomógombot, szövegdobozt a fejlesztőnek kell elhelyeznie a felületen. Ha szeretnénk azok pozícióját megváltoztatni az ablak átméretezésével, hát akkor azt bizony saját magunknak kell megtennünk. Sok olyan könyvtárat fejlesztettek ki, amely beáll az operációs rendszer és a fejlesztő közé, hogy ezt a feladatot egyszerűbbé tegye, köztük a Microsoft saját MFC-je (Microsoft Foundation Classes) is, de túl gyakran még mindig túl mélyre kell merülni a Win32-be ahhoz, hogy a dolgok úgy működjenek, ahogyan azt szeretnénk.
A másik fő módja a Windows alkalmazások készítésének a Visual Basic volt. A Visual Basic néhány feladatot nagyon egyszerűvé tett, különösen az adatbázis eléréséhez és a felhasználói felület kialakításához kapcsolódóakat, és az üzleti világ egyik fontos jellegzetességévé vált. Rettenetes mennyiségű üzleti alkalmazás kering a világban, amelyek nem csinálnak sokkal többet annál, minthogy előrántják az adatot az adatbázisból, megmutatják a felhasználónak és űrlapokat biztosítanak az adatok szerkesztéséhez. Ezekre a feladatokra a Visual Basic kiválóan alkalmas volt. Ennél többet egyetlen fontos dolog kapcsán sem nyújtott. Némi támogatást kínált a Win32 szintű függvények hívásához, alapvetően azokhoz, amelyek a Win32 működésével összefüggő konstrukciókat használtak.
A Visual Basic-ből szintén hiányzott a népszerű objektum-orientált paradigma támogatása, amit megvalósított, az csupán “objektum-alapú” paradigmának nevezhető.
.NET megjelenése mindent megváltoztatott. A .NET a Visual Basic felhasználásának egyszerűségét biztosította, de mindezt a Visual Basic által teremtett kompromisszumok nélkül. A Visual Basic-hez hasonlóan jó eszközöket kínált a felhasználó felületekhez és az adatkapcsolat megvalósításához, és messzemenően alkalmas volt üzleti alkalmazások készítésére. A Visual Basic-kel szemben, a .NET a Win32 elérését – még akkor is, ha ez egy kissé félszeg opció –, sokkal egyszerűbbé tette. A platform gyorsan magához vonzotta az üzleti fejlesztőket és néhány új kereskedelmi célú projekt is szintén használatba vette azt.
A Longhorn álom
A Windows XP, amely egy évvel a .NET előtt jelent meg, meglepő módon nem használta ezt a technológiát. De ahogyan azt a Microsoft a 2003-as PDC-n bejelentette, ezt a helyzetet a majdan megjelenő Windows Longhorn kívánta megváltoztatni. A Loghorn integrálta volna a .NET-et a Windows platform magjába. A .NET keretrendszer, amint az a Microsoftos körökben ismert volt, a WinFX, vagyis a Windows hasonló technológián alapuló keretrendszere felé mutatott volna. Egyebek között a Longhorn egy vadonatúj utat kínált volna a felhasználói felület tervezésére – ez Avalon kódnéven futott, amely modern, vektoralapú és hardveresen gyorsított lett volna. A Windows saját maga úgy lett volna megírva, hogy a felhasználók által látható programjaihoz – az Intéző, a Számológép, stb. – a WinFX technológiát használta volna, és a .NET lett volna “a” módja a Windows alkalmazások készítésének. A Win32 továbbra is létezett volna a visszamenőleges kompatibilitás megőrzése végett, de annak állapotát befagyasztották volna.
A Longhorn lehetett volna a vége a Windows alkalmazások régi módon való írását jellemző korszaknak, és a hajnala a modern Windows fejlesztés egy új korszakának, egy olyan platform, amelyet nem bénítottak volna meg a tíz vagy tizenöt évvel korábban hozott tervezői döntések.
Amint azt mindannyian tudjuk, a Longhorn soha nem készült el. A projekt áttekinthetetlenül nagyra nőtt, kezelhetetlenné vált. Nagyjából abban az időben a Windows XP, amelyre egyébként a Longhorn épült, hekkerek támadásának a célponja lett. A Microsoft ráöntötte az erőforrásait a Windows XP és a Windows Server 2003 elfogadható biztonságúvá alakítására – ezek a Windows XP Service Pack 2-ben és a Windows Server 2003 Service Pack 1-ben tetőztek, majd megint mindent előről kezdve hozzáfogott a következő operációs rendszerének fejlesztéséhez, amely végül is a Windows Vista lett.
Ennek az újrakezdett fejlesztének a legnagyobb vesztese a .NET volt. A Windows Vista, bár radikálisan új dolgokat hozott néhány tekintetben, szakított a teljes WinFX koncepcióval. Az Avalon elkészült – ez ma Windows Presentation Foundationként (WPF) ismert, de ez csak egy kiegészítő komponense volt az operációs rendszernek, nem pedig annak magjához tartozott. A Windows Vista és Windows 7 egyetlen jelentős .NET kódja a Media Center (amely még a WPF-et sem használja). Minden más a jó öreg Win32-re épül. Még sokkal fontosabb, hogy a Win32 API-t módosították és kiterjesztették. Számtalan alacsony szintű képességet adtak a Win32-höz, és a megváltozott grafikus felhasználói felület támogatásához, mint például a Windows tálca az Aero Glass téma. A felhasználói felület egyetlen újdonsága sem működött jól együtt a WPF-fel.
Néhány tényező vezetett ehhez a döntéshez. Egy része a kapkodás volt, nem volt idő arra, hogy mindent újraírjanak a .NET használatára. De talán sokkal fontosabb tényező volt a Microsoft belső divízióinak szerkezete. A Windows-ért a Windows divízió (WinDiv) a felelős. A .NET a fejlesztői divízió (DevDiv) gyermeke, és ez a divízió a Szerverek és eszközök üzletág része. Bár az ember azt hihetné, hogy ezeknek a csoportoknak a kitűzött céljai egy irányba mutatnak, ez nem így volt. Nem feltétlenül rosszindulatból, az egyes csoportoknak egyszerűen különböző prioritásaik voltak.
"Darabos" fejlesztés
Néhány prioritásnak volt értelme abban az időben. Például, a WPF-et csak a .NET programok tudják használni, és csak azokkal működik jól együtt, amelyek C#-ban vagy Visual Basic-ben íródtak. A teljes API a tetejétől az aljáig nem érhető el a natív C++ programokból, és így jelentős erőfeszítéseket igényel a natív programok WPF-re migrálása. Ennek volt értelme, ha az összes jövőbeli fejlesztést az ember a .NET-tel szándékozott végigcsinálni. Azonban, ha a tervek megváltoztak és újra a natív kódot használó fejlesztői környezethez kellett visszatérni, ez komoly problémát jelentett. A Microsoft nem tudta felhasználni a vektoralapú, felbontásfüggetlen és hardveresen gyorsított WPF könyvtárat egyetlen alapvető operációs rendszer alkalmazás készítésére sem.
Más prioritások egyszerűen más irányokba terelték a csoportokat. Így például, a fejlesztői divízió prioritása az volt, hogy a .NET platformot hitelessé tegye a fejlesztők között. Ez azt jelentette, hogy alapvető funkcionalitást, fejlesztői könyvtárakat és eszközöket hoztak létre – mint például, a Silverlight. A Windows divízió prioritásai a már korábban is említett C++ kompatibilitás, a robusztusság, és bizonyos technikai hibák kijavítása volt. Mindegyik célnak volt értelme, de mivel a fejlesztői divízió céljai nem illeszkedtek a Windows divízió céljaival, a Windows divízió céljai nem kaptak elegendő hangsúlyt. Az eredmény az lett, hogy a Windows divízió menedzsmentje nem igazán örült a .NET-nek és boldog volt, hogy átléphet rajta.
A .NET soronkövetkező változatai javítottak ezen a helyzeten, a C++ kérdés kivételével gyakorlatilag minden kérdést megoldottak. De a korábbi sebek már ott voltak, a Windows divízió – miután elégedetlen volt a fejlesztői divízióval –, figyelmen kívül hagyta annak eredményeit, és a Windows 7, csakúgy, mint az elődjei, a .NET-et csak a Media Centerben használja. A Windows 7 új API-jai egytől-egyig mind natív C++ API-k, nem fogyaszthatók közvetlenül a .NET programokból, és a natív C++ programok még mindig nem férnek hozzá a felbontásfüggetlen, vektoralapú, hardveresen gyorsított keretrendszerhez, hogy azzal készítsék el a felhasználói felületet. A Windows 8 ennek véget vet.
Egy szép, új világ
A Windows 8 két futásidejű környezettel együtt érkezik: Egy új .NET-tel (ez jelenleg a 4.5-ös verziószámot viseli) és egy natív kódú C++ környezettel (technikailag ez COM, illetve annak leszármazottja), amelyet WinRT-nek neveznek. Lesz benne egy teljesen új felhasználói felület könyvtár, a DirectUI, amely a natív Direct2D és DirectWrite API-k tetejére épül, ezeket a Windows 7 vezette be. A Silverlight egy új változata, amely jelenleg a Jupiter kódnévre hallgat, a Direct2D felett fog futni. A WinRT és a DirectUI közvetlenül elérhetők lesznek a .NET-ből a beépített csatolókon keresztül.
A WinRT egy letisztult és modern API-t ad sok dologra azok közül, amelyeket a Win32 jelenleg is megvalósít. Sok szempontból, ez egy új, modern Win32 lesz. Az API-t úgy tervezték, hogy azt könnyen lehessen használni “modern” C++ nyelvből (kontraszként a Win32 API 25 éves, erőteljesen C-súlypontú tervezésével szemben). A WinRT szintén letisztult módon vetíthető le a .NET koncepcióira is. A Windows 8-ban valószínűleg a WinRT nem for mindent lefedni, amit a Win32 biztosít – a Win32 olyan kiterjedt, hogy azt modernizálni rengeteg energiát igényel –, de nekem azt mondták, hogy ez a végső, hosszútávú cél. És a WinRT minden egyes Redmondból kiszivárgó változatában egyre és egyre kiterjedtebbé válik.
A WinRT nemcsak egy kissé szebb változata a létező Win32 API-nak! A Microsoft megragadja a lehetőséget, hogy az API funkcionalitását is továbbfejlessze. A vágólap API (Clipboard API) például könnyebben kezelhetővé és rugalmasabbá válik. Szintén meggyőző támogatást kapnak benne az aszinkron műveletek, letisztult és konzisztens módon kezelve a hosszan futó háttérfolyamatokat.
A DirectUI a jelenlegi WPF/Silverlight technológiák magja köré épül. Tartalmazza a XAML-t – az XML nyelvet, amely a felhasználói felületek elrendezésének leírására szolgál – és olyan gazdag felületi elrendezéseket támogat, amelyek a Win32-ben soha nem léteztek. Ez a mag jelenti a C++ programok számára a modern felhasználói felület eszközkészletét, és a szívében ugyanaz az eszközkészlet lesz, amelyet a .NET fejlesztők is használhatnak. (A DirectUI egy olyan név, amelyet a Microsoft korábban már használt a cégen belül, a Windows Live Messenger grafikus könyvtárának neveként. Az új DirectUI-nak, úgy tűnik, ehhez a régihez nincs köze.)
A Jupiter lényegében a Silverlight 6. Minden képességgel rendelkező rugalmas eszközkészlet alkalmazások készítésére. A pontos kapcsolat a DirectUI és a Jupiter között ebben a pillanatban még nem teljesen tiszta. Lehetséges, hogy ez egyetlen és ugyanaz – és a DirectUI funkcionalitása egészen addig nő, amíg mindenre képes nem lesz, amit a Sliverlight is tud. Szintén lehetséges az is, hogy a DirectUI csak az alapvető funkcionalitást valósítja meg és a tetejére egy sokkal teljesebb keretrendszer ül. Egy másik lehetőség az, hogy a Jupiter konkrétan a felületbe beülő teljes képernyős érintés-vezérelt alkalmazások motorja lesz.
A XAML és a WPF-szerű, illetve Silverlight-szerű grafikus felhasználói felület fejlesztés abszolút központi eleme lesz a jövőbeli Windows fejlesztéseknek. Ezek újszerű fontosságának testamentuma az átszervezés, amely a hét elején történt. Ahelyett, hogy a fejlesztői divízió alatt működne tovább, a XAML csapatot három részre vágták. Az a csoport, amely a XAML és a csatlakozó technológiák Windows-beli használatán dolgozott, a Windows divízió alá került át. A Windows Phone-on, az Xbox-on és a böngésző plug-inen dolgozó csoport a Windows Phone alá került. Csak az a csoport maradt a fejlesztői divízió alatt, amelyik a fejlesztői eszközökkel – beleértve a Visual Studiót és az Expression Blendet – foglalkozik. A belső Microsoft email, amely a változásokat jelenti be megjegyzi, hogy a XAML csapat a Windows csapattal dolgozik a Windows 8 fejlesztésének időszakában; vagyis ez a változás formálisan a felhasználói felülettel foglalkozó csapat részéve teszi őket.
Végre: egyetlen, modern és egységes Windows API
Mire is szolgál ez az egész? Ez egyenrangúságot biztosít a C++ és a felügyelt .NET kód számára. Ahelyett, hogy azok egymástól szétválasztva külön, képességeiknek és erősségeiknek megfelelően fejlődnének, társak lesznek. Amennyiben a Microsoft új API-t ad a Windows magjához, a WinRT rendszer biztosítja, hogy azok egyszerre elérhetőek legyenek felügyelt kódból, biztosítva, hogy a .NET fejlesztők ne legyenek hátrányban a natív kóddal dolgozókkal szemben. Hasonlóan, a létező natív alkalmazások átalakíthatók az új felhasználói felület használatára anélkül, hogy azokat lényegében újra kellene írni .NET-ben. Ugyanez a rugalmasság a Microsoftot is érinti: a natív és a .NET kódot egyenrangúvá téve megnyitja az ajtót az előtt, hogy a kibocsátott operációs rendszer .NET alkalmazásokat is tartalmazzon.
Ezzel a képességgel felruházva akár az Office 15-öt is úgy láthatjuk – először az elmúlt tíz, vagy talán annál is több évben –, hogy az a szabványos Windows felhasználói felületet használja azon sajátosan testreszabott front-end-ek helyett, amelyeket az elmúlt években megismerhettünk.
Kevésbé nyilvánvaló az, hogy mi is fog történni a WPF-fel. A WPF és a Silverlight gazdája ugyanaz a csoport a Microsofton belül, de a Silverlight nagyobb piaci sikert ért el, mint a teljesebb WPF. A WPF olyan képességekkel is rendekezik, amelyekkel a Silverlight nem, így szégyen volna, ha ez a bővebb képességhalmaz nem kapna helyet a Windows 8 szép és új világában. A WPF és a Silverlight egy folyamatosan konvergáló útvonal mentén fejlődtek, és lehetséges, hogy a Jupiter megszünteti a két technológia között még megmaradt különbségeket.
A WPF karcsúsításának és a Silverlight szerepének bővítése ésszerűnek tűnik a Microsoft széles fejlesztői ökoszisztémájának ismeretében. A Silverlight egy változatát használják a Windows Phone fejlesztésre, és bizonyíték van arra is, hogy a Silverlight egyfajta Xbox-os változatán is dolgoznak. A Silverlight támogatása a Windows-on, a Windows Phone-on és az Xboxon hosszú távon alátámaszthatná a Microsoft “három képernyő (számítógép, tévé, telefon) és a felhő” ambícióját, amely a szoftvereket és a felhasználói élményt a három környezet közötti zavartalan együttműködésre képesnek látja.
Az a kérdés, hogy ennek a három képernyőtípusnak a támogatása mennyire kiegyensúlyozott, egyike a sok megválaszolatlan kérdésnek. A Windows Phone fejlesztők hosszú ideje aggódnak, hogy a Windows tablet, az iOS és az Androidos versenytársakkal szemben nem fogja közvetlenül támogatni a Windows Phone alkalmazásokat. Mind a Windows, mind a Windows Phone a Silverlight-ot használja, de a telefon egy jó adag telefon-specifikus funkcionalitást ad, amelyeknek jelenleg nincs megfelelőjük a Silverlight asztali környezetében.
Nem kell félni a jövőtől
Az igazán nagy aggodalmat a Windows 8 kezdeti bemutatásának pár héttel ezelőtti eredménye okozta, amely azt vetítette előre, hogy az új stílusú, a Windows felületébe beülő alkalmazások csak a HTML5 és JavaScript fejlesztők számára lesz elérhető. A bemutatón használt nyelvezet alapján az új fejlesztői környezet a HTML5-re és a JavaScriptre “épül”, és ez nagy hullámokat vert a teljes Silverlight fejlesztői közösségben. Egyedi vitaszálak indultak a kérdés kapcsán a fórumokon, amelyek válaszok százait fogadták és tízmilliós találatokat produkáltak – ezek nagyobb forgalmat generáltak, mint amennyit a fórum többi része az egész hónap alatt. A Windows fejlesztők beépülő alkalmazásokat akarnak építeni, de nem akarják, hogy a HTML5 és a JavaScript használatára legyen szükségük ehhez.
Nem is kell ezeket használniuk! Szeretnél egy beépülő alkalmazást írni natív C++ kódban? Ez nagyszerű! C#-ot és Silverlightot szeretnél használni? Ez szintén nagyszerű! Mindkettőt támogatva lesz! Anélkül, hogy magunkra maradnánk az ősrégi asztali alkalmazásokkal – mert sokakban ezt a benyomást keltette a prezentáció – a C++ és a felügyelt C# egyaránt elsőrendű lehetőségek lesznek a beépülő alkalmazások fejlesztésére, érintés-támogatással, tablet-barát Windows 8 stílusú alkalmazások fejlesztésére.
Mi a helyzet a HTML5-tel és a JavaScripttel? Ezek szintén a lehetőségek közé tartoznak. A Microsoft már korábban a HTML alkalmazások ösvényére merészkedett a HTA technológiájával. A HTA-k (HTML alkalmazások) olyan HTML, JavaScipt, CSS és egyéb erőforrásokat tartalmazó csomagok, amelyek egy speciális “trusted” módban futnak. Azok a normál korlátozások, amelyek a megszokott HTML weblapok múködését irányítják – például, a helyi erőforrások használatának a hiánya – nem érvényesek a HTA-kra: egy HTA írhat a fájlrendszerbe, hozzáférhet tetszőleges hálózati erőforrásokhoz, és egyebekhez is. Más szavakkal, a HTA-k olyan weblapok, amelyekből kikerültek azok a limitációk, amelyek a weblapokat képtelenné teszik arra, hogy az asztali környezeteket felváltsák.
Az új stílusú HTML5 beépülő alkalmazások nem HTA-ként kerülnek fel az eszközökre, de a HTA elvekből sokminden valószínűleg alkalmazásra kerül. Amint a HTA-k korábban, a HTML5 alkalmazások is nagyobb hozzáféréssel fognak rendelkezni az operációs rendszer funkcionalitása kapcsán, mint a szokványos weboldalak – és így képesek lesznek a Windows API-k használatára. A felhasználói felületük kevésbé lesz webapnak érezhető, annál inkább egy natív alkalmazásnak. A képességeiket tekintve azon a szinten lesznek, mint a .NET-ben készült és a natív programok. Egyszerűen csak HTML5-öt és JavaScriptet fognak programozási modellként használni. Az eredmény valami olyasmi lesz, amit a webfejlesztők már megszoktak, de azon funkcionális hiányosságok nélkül, amitől egyébként a legtöbb webalkalmazás szenved.
Távolról sem lesz a Windows 8 fejlesztői szemmel katasztrófa, hanem inkább egy nagy előrelépés: egy olyan változat lesz, amely azzal fenyeget, hogy a fejlesztés gyönyörét kínálja a natív, felügyelt kódot és webes technológiákat használó fejlesztőknek egyaránt. A .NET és a natív világ egyesítése; a hardveres gyorsítás elérhetősége; letisztult és modern API-k, Az Avalon, mint elsődleges megoldás a Windows felhasználói felület létrehozására – mindaz, amit a Loghorn WinFX-e már korábban megígért, de ezúttal úgy látszik, hogy mindez meg is történik.
Megtévesztő hallgatás
Hogy mindez miért vezet Microsoftos “adásszünethez”, igen nehezen érthető. A cég tisztában van azzal, hogy HTML5 és JavaScript üzenetét a közösség vette, de az a hozzáállása, hogy nincs is igazi probléma; a megrázó, horrorisztikus reakció csupán a bloggerektől érkező túlfűtött dolog. Azt a döntést, hogy nem mondanak semmi mást, mint azt, hogy “várjatok a BUILD konferenciára szeptember közepéig” már többször megvitatta és újratárgyalta a cég, a legfelsőbb szinteken is, de jelenleg a korábbi döntés érvényben marad: nem mondanak semmit, a fejlesztőket bizonytalanságban tartják.
Úgy vélem, ez a hozzáállás már másfél hete bűzlik, és még ma is büdös. Az a több tízmillió találat, amelyet a Silverlight fórumok értek el, nem nevezhetők felfújt blogőrületnek. A Windows Phone fejlesztők ma is azt mondják, hogy a Microsoft árokba fordítja a platformot a jövőjének bizonytalansága miatt, és ez nem nevezhető túlfűtött blogger üzenetnek! Amikor egy korábbi Microsoftos projektmenedzser – aki a WPF-en és a Silverlighton egyaránt dolgozott – azt mondta, hogy az Adobe hasonló Flex/Flash eszközkészletére fog váltani, mert az Adobe legalább elkötelezte magát abban az irányban, nos ez egyáltalán nem afféle blogolós dolog.
Érthető, hogy a Microsoft nem akar mindent most azonnal ránk önteni. A Windows 8 előtt még mindig hosszú út áll, mire befejezik, és rengeteg dolog változik mostantól a BUILD konferenciáig is. De a fejlesztők nem azt mondják, hogy mindent most azonnal hallani akarnak, csupán néhány szembetűnő részletről szeretnének egy kicsit többet tudni. Két kérdés megválaszolása valószínűleg kezelné a helyzetet. Lehetséges lesz beépülő alkalmazásokat készíteni C++ vagy .NET használatával? Lehetséges lesz ilyen alkalmazásokat írni XAML-ben?
Mindaddig, amíg a jelnelegi irányvonal nem változik meg radikálisan a BUILD után – bár ez még csak egy előzetes szoftverváltozat, szóval, ha nem is lehetetlen, de valószínűtlen, hogy ez történik – a válasz mindkét kérdésre az “igen”, és az, hogy a Windows 8 fejlesztői élmény minden idők legnagyobb előrelépése lesz a 32-bites Windows API 1993-as megjelenése óta. Ez egy izgalmas kilátás, de a Microsoft semmit nem nyer vele, ha a kétségeket továbbra is lebegni hagyja.
Bejegyzések
0 megjegyzés :
Megjegyzés küldése