Longhorn ist der Codename für den Nachfolger von Windows XP, der nach aktuellem Zeitplan irgendwann 2006 erscheinen soll, wobei niemand besonders überrascht wäre, wenn sich dieser Termin noch um ein oder zwei weitere Jahre verschiebt.
Trotzdem sind Microsofts Visionen in einer ersten Vorabversion von Longhorn schon teilweise zu erkennen - da es sich dabei noch nicht einmal um eine Alpha- geschweige denn um eine Betaversion handelt, sind andere Teile der Visionen nicht einmal ansatzweise zu erkennen. Dieser Beitrag erläutert den aktuellen Stand der Dinge bei Microsofts zukünftigem Client-Betriebssystem.
Bevor man sich mit Longhorn näher beschäftigt, muss eines unbedingt klar sein: Longhorn wird sich von Windows XP dramatisch unterscheiden - genau so dramatisch, wie sich Windows 95 von Windows 3.1 unterschied. Von diesen Unterschieden sind natürlich nur "neue" Anwendungen betroffen: Programme für Windows 3.1 und Windows 95 bis Windows XP werden auch unter Longhorn weiterhin brav ihren Dienst tun. - Nur das Betriebssystem selbst wird radikal neue Features haben: Und eben solche Anwendungen, die diese Features nutzen.
Zwar ist Longhorn noch lange nicht fertig, dennoch kann man sich optisch zumindest einen ersten Eindruck verschaffen. Dafür haben wir Ihnen einige Screenshots in einer Bildergalerie zusammengestellt.
Neues für Anwender und Programmierer
Nicht nur für den Anwender des Betriebssystems ändert sich einiges, sondern auch für Entwickler. Natürlich kann man auch weiterhin mit dem Win32-SDK arbeiten - neue "Longhorn" Anwendungen kommen dabei aber nicht heraus. Um solche Anwendungen zu programmieren, muss man die neue API benutzen: WinFX. Dieses Kürzel ist nicht mit WinFS zu verwechseln, das etwas später im Beitrag erläutert wird.
WinFX ist die neue Bezeichnung für die Windows-API und WinFX unterscheidet sich vom bisherigen Platform-SDK in erster Linie durch folgende Eigenschaften:
Bei WinFX handelt es sich um managed Code und ein managed Framework:
Im Gegensatz zum Platform SDK ist WinFX ein objektorientiertes Modell, das letzten Endes auf dem bereits seit einiger Zeit verfügbaren .NET aufbaut.
Allerdings: Das momentan verfügbare .NET-Framework stellt nur einen extrem kleinen Teil von WinFX dar, denn WinFX kapselt wirklich das komplette System. Und zwar einschließlich aller Objekte, die bei XP in Form von Add-on-Bibliotheken zu haben sind. Mit anderen Worten: WinFX ist geradezu riesig.
Angesichts des momentanen Zustands von Longhorn kann man noch relativ wenig über den Funktionsumfang des fertigen Systems sagen: Die erste einigermaßen breit zugängliche Version von Longhorn ist gerade seit wenigen Wochen verfügbar und steht MSDN-Abonnenten zum Download bereit. Parallel dazu stellt Microsoft aber auch öffentlich verfügbare Informationen zur Verfügung, die größtenteils für Entwickler, teilweise aber auch für Anwender von Interesse sind und einzelne Teile des kommenden Systems beleuchten: Alle diese Informationen sind im Longhorn Developer Center zu finden.
Microsoft teilt Longhorn in drei relevante Bereiche auf, die die schönen Namen "Avalon", "WinFS" und "Indigo" tragen. Bei Avalon handelt es sich um den Bestandteil, der sich um das User-Interface kümmert, WinFS ist das neue Dateisystem und Indigo die dienstorientierte Kommunikationsschicht.
Präsentation mit Avalon
Momentan stehen unter .NET zwei User-Interface-Schichten zur Verfügung. Die eine ist in ASP.NET angesiedelt und bedient Webanwendungen, die andere gehört zum Windows.Forms-Namespace und kann für Windows-Clients verwendet werden. Beide Bibliotheken werden weiterentwickelt - keine davon dient aber als Grundlage für die UI-Schicht in Longhorn: Der native UI-Teil von Longhorn trägt den Namen Avalon.
Bei Avalon handelt es sich um ein deklaratives, vektorbasiertes UI-Modell, mit dem Benutzerschnittstellen zusammengesetzt werden können. Im Kern kann man sich das als eine Weiterntwicklung von DHTML vorstellen: Ähnlich wie bei HTML kann das Benutzerinterface deklarativ beschrieben werden, den Rendering-Teil übernimmt bei Avalon aber das Betriebssystem und nicht wie bei HTML der Browser. Genau wie bei DHTML besitzt das UI aber auch ein Objektmodell, auf das der Programmierer Einfluss nehmen kann.
Völlig anders als bei (D)HTML ist dabei die Tatsache zu werten, dass Avalon vektorbasiert ist. Hier werden also keine statischen Bitmaps manipuliert, sondern man arbeitet in der Mehrzahl der Fälle mit frei skalierbaren Objekten. Im Wesentlichen hat das den Vorteil, dass das UI von Größe und Auflösung des verwendeten Ausgabegeräts (meist dem Monitor und der Grafikkarte) unabhängig ist.
Der deklarative Code wird dabei in einem XML-Dialekt geschrieben, der tatsächlich sehr große Ähnlichkeit mit HTML plus CSS hat, Event-Handler und anderer Code wird dabei so ähnlich angebunden, wie es bei DHTML plus DOM der Fall ist.
Deklarative Events
Zusätzlich zu einem Code-Behind-File, wie man es von ASP.NET schon kennt, bietet Avalon aber auch die Möglichkeit, Events rein deklarativ zu behandeln. Dazu gibt es so genannte Property-Trigger, die an Eigenschaften gebunden werden. Möchte man mit einem solchen Property-Trigger beispielsweise darauf reagieren, dass sich die Maus über einem Objekt befindet, und das Objekt in diesem Zusammenhang umfärben, sieht der Code etwa wie folgt aus:
<PropertyTrigger Property="IsMouseOver" Value="True">
<Set PropertyPath="Fill" Value="Red" />
</PropertyTrigger>
Mit anderen Worten: In Avalon ist es durchaus möglich, die Event-Behandlung rein deklarativ durchzuführen. Wie praxistauglich so ein Vorgehen tatsächlich ist, wenn das User-Interface komplexer wird und sich aus mehr als einem Objekt zusammensetzt, muss die Praxis allerdings erst noch erweisen.
Eines ist dabei auf jeden Fall schon klar: Avalon ist ein extrem mächtiges Werkzeug für die UI-Gestaltung: Unabhängig von den vielfältigen Möglichkeiten der Anwendung von Styles, der Nutzung von Multimedia-Elementen wie früher Buttons und der freien Skalierbarkeit aller Elemente, verwendet Avalon zum ersten Mal in Windows die GPU moderner Grafikkarten: Dadurch werden die visuellen Möglichkeiten dramatisch verbessert und es steht dadurch schließlich unendlich viel mehr an Rechenleistung fürs UI zur Verfügung, als das bisher der Fall war.
Der rein deklarative Teil des Codes wird dabei in einer Datei mit der Endung .xaml abgelegt, die dann entweder übersetzt wird, was in einem richtigem Windows-Programm resultiert, oder direkt in den Internet Explorer von Longhorn geladen wird: Der kann XAML nämlich auch direkt anzeigen. Der folgende XAML-Quellcode ist beispielsweise ein vollständiges Programm, das den Text "Hello World" anzeigt:
<TextPanel xmlns="http://schemas.microsoft.com/2003/xaml"
Background="BlanchedAlmond"
FontFamily="Comic sans MS"
FontSize="36pt"
HorizontalAlignment="Center">
Hello World
</TextPanel>
3D mit Avalon
Avalon ist aber kein reines 2D-Interface, sondern bietet auch echte 3D-Elemente für die UI-Gestaltung. Die 3D-Funktionalität in Avalon baut direkt auf DirectX auf und hat dementsprechend auch praktisch alle Möglichkeiten von DirectX zu bieten: Nur eben nicht für Spiele, sondern für das ganz normale Gestalten von Fenstern und Fensterinhalten.
So ist es mit Avalon beispielsweise leicht möglich, echte 3D-Szenen innerhalb eines normalen Fensters zu verwenden und zu animieren - also auch in einem Fenster, das normale 2D-Inhalte enthält. Interessanterweise kann man die 3D-Objekte in Avalon problemlos auch per Remote Desktop benutzen - und ausdrucken - was mit "echten" DirectX-Lösungen und auch bei OpenGL relativ große Probleme bereitet.
Kommunikation mit Indigo
Bei Indigo handelt es sich um einen neuen Kommunikations-Stack in Windows. Indigo stellt einen dienstorientierten Kommunikations-Mechanismus zur Verfügung. Entwickler sind damit in der Lage, Programme zu verknüpfen, die auf unterschiedlichen Rechnern laufen. Das eine Programm kann dabei Funktionen (Dienste) eines anderen Programms benutzen. Einzige Voraussetzung: Das andere Programm muss irgendwie über ein Netzwerk erreichbar sein.
Letzten Endes handelt es sich bei Indigo um eine Weiterentwicklung von Com+ und den Message Queues beziehungsweise den Web-Services. Microsoft sieht offenbar großen Handlungsbedarf darin, Entwicklern die Entwicklung von verteilten Anwendungen möglichst zu vereinfachen. An welchen Stellen solche Anwendungen tatsächlich sinnvoll und notwendig sind, bleibt allerdings offen. Schon bei Web-Services haben sich die Entwickler von selbigen nicht gerade mit Angeboten überschlagen.
Microsoft nimmt Indigo allerdings sehr ernst und sieht darin eine bahnbrechende neue Kommunikationsinfrastruktur. Aus diesem Grund wird es auch einen Backport von Indigo für Windows XP und Windows Server 2003 geben. Von Microsoft gibt es bereits einen umfangreichen Satz an Veröffentlichungen rund um Indigo.
WinFS - das neue Dateisystem
Das Windows File System ist der dritte neue Pfeiler, auf dem Longhorn ruht. Die Idee von WinFS ist dabei die, dass man beliebige Daten im Dateisystem ablegen kann, und das Dateisystem dann anhand von Metadaten Informationen über diese Datei sammelt. So kann WinFS beispielsweise Metadaten aus Musikstücken verwenden, um dann einen Anzeigemodus im Explorer zu erlauben, der die Daten nach Künstler oder Album sortiert.
Die Metadaten selbst liegen dabei in einer Datenbank, die auch mit einem T-SQL-ähnlichen Verfahren abgefragt werden kann. Die Metadaten sollen größtenteils automatisch aus vorhandenen Dateien extrahiert werden, können aber gleichzeitig vom Anwender Dateien zugeordnet werden. Das passiert dabei entweder implizit oder explizit.
Eine implizite Versorgung mit Metadaten erfolgt beispielsweise dadurch, dass WinFS als Speicher für alle Daten dienen soll: So werden auch E-Mails nicht länger in einem separaten E-Mail-Speicher des Mail-Programms abgelegt, sondern einfach als Daten im WinFS: Dadurch ist WinFS natürlich in der Lage, Inhalt und Kontext dieser E-Mails zu benutzen. Ebenso werden die "Kontaktdaten" des Anwenders nicht länger in einem separaten Adressbuch gespeichert, sondern einfach im WinFS abgelegt. Dadurch kann das WinFS einen Zusammenhang zwischen Mails, deren Inhalten, Absendern und Empfängern herstellen.
WinFS soll mitdenken
Schließlich soll WinFS auch noch in der Lage sein, selbst Schlüsse aus vorliegenden Daten zu ziehen und daraus Metadaten zu produzieren. In einem Interview auf Channel9 wurde dazu folgendes Beispiel aufgeführt: Ein Anwender kommuniziert per E-Mail mit einem Reisebüro, bei der Kommunikation geht es im Wesentlichen um die Planung einer Reise.
Dann ist der Anwender eine Zeitlang nicht im Büro, schließt aber nach seiner Rückkehr seine Digitalkamera an und transferiert eine Menge Bilder auf den PC. Die Bilder sind wiederum mit Datum und Uhrzeit versehen, die genau im Urlaubszeitraum des Anwenders liegen. Jetzt schlägt die "Magie" von WinFS zu: Der Anwender kann ab sofort nach "Bilder vom Urlaub" suchen - und das Resultat der neuen WinFS-basierten Windows-Suche liefert genau die gewünschten Bilder. Der Anwender muss dabei keinerlei zusätzliche Arbeitsschritte durchführen.
Das ist aber alles bestenfalls auf Computern in Redmond nachvollziehbar. Bei der momentan vorliegenden Longhorn-Version zeichnet sich die Suche in erster Linie dadurch aus, dass Sie deutlich unerträglicher und langsamer ist als die von Windows XP. Anders als bei XP bekommt man eher gar keine Suchresultate - und zwar deshalb, weil man vor dem Ende der Suche das Ganze entnervt abbricht.
Das ist aber kein Wunder: Die verfügbare Version von Longhorn enthält bisher keine nennenswerten Teile von WinFS: Wer damit herumspielen will, wird auf kommende Versionen von Longhorn warten müssen. Nur Entwickler können schon ein wenig Hand anlegen - die Dokumentation von WinFS ist zwar weit davon entfernt komplett zu sein, aber erste Versuche lassen sich durchaus unternehmen. Weitergehende Informationen zum WinFS finden Sie bei MSDN und im MSDN-Magazin.
Longhorn - so sieht es aus
Die Fertigstellung von Longhorn liegt noch in ferner Zukunft - und daher ist es auch schwer, einigermaßen haltbare Aussagen über das tatsächlich kommende UI zu machen. Ein nicht ganz unwichtiger Grund dafür ist die Tatsache, dass das Benutzerinterface von Avalon nach aktuellem Plan von den Möglichkeiten des Grafikprozessors auf dem Zielsystem abhängig sein wird.
Insgesamt soll es drei unterschiedliche Schnittstellen geben - je besser die Grafikkarte, umso besser - oder zumindest: grafisch ausgefeilter - wird auch das Benutzer-Interface sein.
Die beiden besseren Schnittstellen hören auf die Namen "Aero Glass" und "Aero", das normale Low-Level-Interface firmiert momentan noch unter "Classic". "Aero Glass" wird dabei teilweise durchsichtige Elemente und 3D-Shading aufweisen, außerdem sollen auch echte 3D-Elemente Einzug halten: So ist wohl auch geplant, im Raum "stapelbare" Fenster zuzulassen, wie man anhand einiger auf der WinHec gezeigter Bilder sehen konnte. Für "Aero Glass" wird eine Grafikkarte mit mindestens 64 MByte vorausgesetzt: zumindest nach dem aktuellen Stand der Gerüchte.
"Aero" soll eine abgespeckte Version von "Aero Glass" werden, mit weniger Video-RAM auskommen und auch weniger echte 3D-Features bieten. Das "klassische" UI wird eher Windows XP ähnlich sehen - wobei natürlich grundlegend neue Elemente wie die "Sidebar" auch dabei enthalten sein werden.
3D mit Aero und Aero Glass
Um "Aero" und "Aero Glass" zu betreiben, reicht der Videospeicher allein aber nicht aus: Die verwendete Grafikkarte muss auch DirectX 9 unterstützen und logischerweise einen Longhorn-Video-Treiber haben.
Vom 3D-Interface ist momentan jedoch praktisch noch nichts zu sehen. Zwar sollen im aktuell verfügbaren Code bereits kleine Teile davon enthalten sein - auf unseren Rechnern waren Longhorn diese Elemente bisher aber nicht zu entlocken. Die allgemein knappe Verfügbarkeit von Bildern, die die 3D-Elemente zeigen und nicht von Microsoft-eigenen Demos entstammen, spricht dabei Bände: Auch sonst ist bisher praktisch niemand in der Lage, das 3D-Interface bereits tatsächlich zu begutachten.
Hartnäckige Gerüchte wollen zwar weismachen, dass man mit ein paar Handgriffen "Glass"-Effekte im aktuellen Longhorn sichtbar machen kann - aber ob das dann wirklich so aussieht, wie für die Zukunft geplant, oder ob es sich dabei einfach um Teile des nicht fertigen Longhorn-Codes handelt, der nur irrtümlich in der Vorabversion enthalten ist, kann niemand mit Sicherheit sagen.
Allerdings: Einen groben Einblick in die neue Version von Windows kann man schon bekommen, indem man einfach einen kleinen Rundgang durch die verfügbare Variante macht. Dafür haben wir Ihnen einige Screenshots in einer Bildergalerie zusammengestellt. (mha)