Warum Microsoft bei Windows 8 auf HTML setzt?

Die Ankündigung von Microsoft auf der AllThings D 2011 und auf der Computext, dass Windows 8 Apps mit HTML5, CSS und JavaScript entwickelt würden [1, 2], hat ja zu einigen Diskussionen im Internet geführt [5]. Viele .NET- und Silverlight-Entwickler sahen bereits ihre Felle wegschwimmen [3, 4]. Aber je länger ich mich mit der Frage beschäftige, umso genialer finde ich den gewählten Ansatz. In diesem Beitrag möchte ich ein paar Gedanken zusammenflicken, die mir so im Web noch nicht untergekommen sind. Könnte sein, dass wir noch eine gewaltige Überraschung erleben.


Werbung


Die kachelbasierende Benutzeroberfläche von Windows 8 spaltet je etwas die Geister. Aber wie es scheint, bewegen sich alle neuen Betriebssysteme, also auch Windows 8, in Richtung Unterstützung für Touchbedienung. Mag man mögen oder nicht.

Wie es ausschaut, lässt sich der StartScreen per Gruppenrichtlinien abschalten. So dass Administratoren vorgeben können, ob der Benutzer die alte Windows 7-Oberfläche oder den neuen Start Screen nach der Benutzeranmeldung sieht. Und Microsoft hat da bezüglich Tochbedienung durchaus einige Erfahrung und noch einiges im Petto [9].

Dass dieser Start Screen für Microsoft Vorteile hat und zur Vereinheitlichung in der Produktoberfläche diverser Microsoft Produkte hat, führt Paul Thurrots in einem Anfang Juli geposteten Blog-Beitrag aus [6]. Auch der Beitrag unter [18] rutscht auf diesen Ansätzen herum. Unter [8] wird berichtet, dass bei Bing eventuell Live Tiles Einzug halten. Da ist es naheliegend, dass man auf HTML5 setzt. Unter [8] hatte ich noch auf einen Artikel bei heise.de verwiesen (hat mir etwas Kritik eingebracht), der u. U. auch zur Beruhigung der .NET-Fraktion beitragen könnte.

Aber ist das alles?

Gut, kann man zur Kenntnis nehmen und zur Tagesordnung übergehen. Aber irgendwie nagt es an mir, dass Microsoft die Ausführungen zu HTML5, CSS und JavaScript auf der AllThings D 2011 trotz der Diskussionen im Internet unkommentiert stehen lässt. Man hätte ja sagen können “App-Entwicklung für den Start Screen erfolgt bevorzugt mit HTML5 und JavaScript, aber .NET und Silverlight sind dank XAML möglich”. Hat man aber nicht gemacht.

Irgendwann habe ich mir die Frage gestellt, könnte da nicht noch was anderes dahinter stecken. Wo kneift es Microsoft denn mit den alten Windows-Ansätzen? Der Hinweise auf MinWin und Hyper-V [10, 16] haben mich in eine gänzlich andere Richtung gedreht und mich bewogen, nochmals meine älteren Blog-Beiträge anzusehen. In meinem ersten Beitrag [11] im Windows 8-Channel gehe ich auch auf die Thematik “MinWin & Virtualisierung” ein und zeige einige Folien aus Präsentationen, die von Microsoft Mitarbeitern gehalten wurden. Es kreist alles um die Frage, wie viel Virtualisierung ein zukünftiges Betriebssystem haben sollte.

Zeit, also mal einen kurzen Blick auf zwei Knackpunkte zu richten, die Windows 8 massiv beeinflussen und auf die die Entwickler wohl eine Antwort haben sollten.

Kompatibilität mit Altanwendungen

Der große Vorteil von Windows ist seine Installationsbasis. Die Altlast, die man mitschleppt, sind aber die Altanwendungen, die speziell im Firmenumfeld gefahren werden müssen. Bisher waren der Kompatibilitätsmodus und Windows XP-Mode die Antwort von Microsoft auf Probleme mit Altanwendungen. Aber dieser Ansatz trägt nicht mehr lange. Wenn Windows 8 2012 auf den Markt kommt, wird in Firmen nicht vor 2013/2014 über eine Migration nachgedacht.

2014 läuft aber der extended Support für Windows XP SP3 aus, der “End of Live”-Cyle ist erreicht. Also wäre man ab diesem Zeitpunkt von Altanwendungen abgeschnitten oder müsste mit einem unsupporteten Windows XP arbeiten. Kaum vorstellbar.

An anderer Stelle hatte ich bereits die Frage aufgeworfen, warum man unbedingt ein vollständiges Windows XP mit Notepad, Paint, Windows Media Player, Internet Explorer 6 etc. mitschleppen muss, wenn man eine Anwendung virtualisieren will. Ein minimales Windows XP, reduziert auf den Kern bzw. die Unterstützung der API-Aufrufe (wie bei WINE) wären eigentlich ausreichend, um ein Altanwendung wieder zum Leben zu erwecken. Diese läuft virtualisiert als Task. App-V [17] ist der von Microsoft seit einiger Zeit verfolgte Ansatz zur Anwendungsvirtualisierung. Also deutet sich hier ein Weg an.

Kompatibilität mit Altanwendungen auf ARM-Systemen

Da Windows 8 die ARM-Plattformen abdecken wird, kommt Microsoft ein weiteres Problem in die Quere: Auf ARM-Plattformen läuft typischerweise die alte x86-Software nicht mehr. Microsoft wird zwar eigene Produkte für ARM compilieren, so dass Office und weitere Produkte beim Marktstart bereitstehen. Aber die Millionen an Altanwendungen für x86-Plattformen bleiben außen vor …

Etwas stutzig wurde ich beim Bloggen über die Intel Investorenkonferenz [12], wo ein Intel Mitarbeiter Renée James ausführte, dass die ARM-Varianten von Windows 8 keine “alten Anwendungen” ausführen können (ergo auch keinen “Windows 7 Mode” aufweise). Klang für mich in diesem Kontext logisch. Aufgemerkt habe ich, als dem kurzfristig nach der Konferenz von Microsoft widersprochen wurde (habe ich hier nachgetragen). Wie allerdings alte x86-Anwendungen, die nur als .exe-Datei vorliegen, nativ in einer ARM-Umgebung ausgeführt werden, blieb mir damals schleierhaft.

Und wie kommt HTML und JavaScript nun ins Spiel?

Erinnert mich jetzt an meine Schulaufsätze, wo der Lehrer sagte “Born kommt mal wieder vom ‘Hölzchen auf’s Stöckchen’” – aber der obige Schlenker muss schon sein. Denn bei der Betrachtung dieser Problematik fiel mir ein Hinweis von Jo Mary Foley auf Technologien ein, die Microsoft in seinen Labors ausprobiert [12]. Und dann habe ich mal angefangen etwas zu graben. Das Stichwort XAX-Technologie führte mich dann zu einem Artikel, den einige Mitarbeiter aus der Microsoft Forschungsabteilung 2008 publiziert haben [13].

Beim Lesen dieses Artikels sind mit die Augen übergegangen. Es ging um die Frage, wie man Anwendungen ins Web heben und ggf. virtualisieren kann. In dem Beitrag zeigen die Forscher, dass man zur Virtualisierung nur ein Syscall-Interface bereitstellen muss, welches die API-Aufrufe der Anwendungen entgegennimmt. Alle anderen Geschichten, die heute von Supervisoren in Virtualisierungslösungen gestemmt werden sowie das Hosten ganzer Betriebsysteme sind überflüssig. Die Leute sprechen von sogenannten Picoprozessoren, die einen Core abstrahieren und als “abgespeckte” virtuelle Maschine gesehen werden können. Diese führen eine Anwendung aus und virtualisieren diese in einer Sandbox gegenüber dem Betriebssystem. In einem Forschungsprojekt konnte gezeigt werden, dass binnen 2 Wochen mehrere Millionen Zeilen Code bestehender Anwendungen unter Windows und Linux virtualisierbar war.

So, what’s the beef? Gänzlich elektisiert haben ich zwei Aussagen in dem Paper der Microsoft Forscher. Einmal war es ja das Ziel, Desktop-Apps ins Web zu heben. Die Implementierung fand daher als Browser-Add-On statt. Ups, ein Browser? Das ist doch dat Dingens, wat HTML-Code versteht und JavaScript kann! Und da schließt sich der erste Kreis. Mit XAX hat Microsoft eine Technologie in den Forschungslabors, mit dem sich in einer Rendering Engine als Browser-Add-On Anwendungen über Picoprozessoren virtualisieren lassen. Die im Paper vorgestellten Performance-Messungen sehen auch gar nicht mal so übel aus. Geht man das Paper durch, stößt man auf einen Abschnitt “Binary rewriting”, der sich damit beschäftigt, wie ggf. Code von RISC-Prozessoren, der ja nicht x86-kompatibel ist, durch verändern des Binärcodes virtualisiert werden kann. Und damit schließt sich der zweite Kreis – ein entsprechender Picoprozess könnte auf einem ARM-System durchaus x86-Code verarbeiten und damit Anwendungen ausführen. So gesehen macht das oben erwähnte Microsoft Dementi, dass noch keine Entscheidung gefallen sei, ob Windows 8 for ARM keinen “Windows 7-Mode” bekommt, sehr viel Sinn.

Gräbt man dann noch etwas weiter, stößt man auf zwei weitere interessante Artikel [14, 15].  Der erste Artikel befasst sich mit Sicherheitsaspekten bei Browser-Erweiterungen. Und der zweite Artikel wurde gerade erst veröffentlich und geht auf HTML-basierende Anwendungen (Apps) ein. Übersetzt man das Wort “immersive” in “immersive apps” als “eingetaucht” oder “eingebettet”, heißt das: Die neuen Windows 8-Apps werden in irgend etwas eingebettet. Und das könnten ja durchaus alte x86-Anwendungen oder aktuelle x86-Anwendungen sein, die dann in einem Picprozessor virtualisiert werden.

Es mag sein, dass ich mit meinen Spekulationen am Ende des Tages total daneben liege. Aber bei näherer Betrachtung tun sich sehr viele interessante Möglichkeiten auf. Früher oder später werden wir auf dieser Baustelle ankommen – schätze ich mal.

Links:
1: Windows 8 Preview auf Computex & AllThings D
2: Windows 8 Video(-analyse) von der D9
3: Stirbt Silverlight mit Windows 8?
4: ‘Windows 8’: Erster Blick auf “Jupiter”?
5: Windows 8: Netter Beitrag zum Jupiter-Fiasko
6: Celebrating Microsoft’s Cohesive New User Experience Strategy
7: Netter Artikel zur .NET-Zukunft unter Win 8
8: Arbeitet Microsoft an Bing Live Tiles?
9: Interessante MS-Patente für Touchbedienung
10: MinWin, Hyper-V und Windows 8
11: Blick in die Glaskugel: so wird Windows 8
12: “Windows 7 Mode” für Windows 8?
13: Leveraging legacy code to deploy desktop applications on the Web
14: Verified Security for Browser Extensions
15: C3: An Experimental, Extensible, Reconfigurable Platform for HTML …
16: Windows 8: MinWin and what it means for virtualization
17: Application Virtualization
18: Why Windows® 8 Chooses HTML 5 over Visual Basic and Java® Script?


Werbung

Über Günter Born

IT-Autor, Blogger borncity.de
Dieser Beitrag wurde unter Virtualisierung, Windows 8 Beta abgelegt und mit , , , , , verschlagwortet. Setze ein Lesezeichen auf den Permalink.

Eine Antwort auf Warum Microsoft bei Windows 8 auf HTML setzt?

  1. Pingback: Why MS choose HTML5 for Windows 8 Apps « Borns IT- und Windows-Blog

Hinterlasse eine Antwort

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *

Du kannst folgende HTML-Tags benutzen: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Current ye@r *