Installation und Analyse Microsoft Longhorn

Inhaltsverzeichnis

Zusammenfassung

Abbildungsverzeichnis

Abkürzungsverzeichnis

1 Einleitung

2 Longhorn
2.1 WinFX und das Longhorn SDK
2.2 3-Säulen Modell
2.2.1 Avalon
2.2.1.1 Ziel
2.2.1.2 Architektur und Funktionalität
2.2.1.3 XAML
2.2.2 Windows Future Store (WinFS)
2.2.2.1 Ziele von WinFS
2.2.2.2 Architektur
2.2.2.3 NTFS- Die Basis von WinFS
2.2.2.4 Datenmodell-Items
2.2.2.5 Info-Agenten
2.2.3 Indigo
2.2.3.1 Verteilte Systeme
2.2.3.2 Ziel
2.2.3.3 Einsatz von Indigo
2.2.3.4 Verfügbarkeit
2.3 NGSCB
2.3.1 Sicherheit durch Hard- und Software
2.3.1.1 TPM-Chips
2.3.1.2 Nexus Computing Agents
2.3.1.3 Security Support Component
2.3.1.4 Wird NGSBC unter Longhorn zur Pflicht?
2.4 Sicherheitsanalyse Longhorn
2.5 Treiber unter Longhorn
2.5.1 Longhorns Treiberinstallationsarchitektur
2.6 Performancevergleich Longhorn vs. Windows XP

3 .NET Framework
3.1 Was ist das .NET Framework?
3.2 Whidbey
3.2.1 Generics
3.2.2 Object Spaces
3.2.3 Whitehorse
3.2.4 Clickonce-Deployment
3.3 Performancevergleich Visual Studio .NET vs. Visual Studio 2005 (Whidbey)

4 Fazit

Anlage A: Literaturverzeichnis

Anlage B: Installation Microsoft Longhorn

Anlage C: Beispiel Schema WinFS

Anlage D: Nessus

Anlage E: Avalon Screenshots

Anlage F: Bill Gates im Interview [10]

Zusammenfassung

Diese Studienarbeit analysiert den Microsofts Windows XP Nachfolger mit dem Codenamen Longhorn. Im Mittelpunkt der Analyse steht Microsofts neues drei Säulen Modell mit dem neuen Benutzerinterface Avalon, dem Dateisystemaufsatz Windows Future Store (WinFS) und der Kommunikationsschnittstelle Indigo. Auf alle 3 Säulen wird im Rahmen dieser Stu-dienarbeit ausführlich eingegangen.

Über diesen drei Säulen befindet sich WinFX, der Nachfolger des Win32 API. WinFX bildet die gesamte Funktionalität des Betriebssystems über Managed Code ab.

Unter den drei Säulen befindet sich das Fundament mit dem neuen Schattenbetriebssystem Next Generation Secure Computing Base (NGSCB), welches durch die Trennung des Be-triebssystems in zwei Kerne und durch die Zusammenarbeit von spezieller Hard- und Soft­ware für mehr Sicherheit sorgen soll.

Neben der Installation und Analyse von Microsoft Longhorn wird die Studienarbeit durch ei-ne Sicherheitsanalyse von Longhorn mit dem Open-Source Sicherheitsanalysetool Nessus ergänzt.

Da Longhorn nur einen Teil der Microsoft .NET Vision für die kommenden Jahre darstellt, befasst sich diese Studienarbeit auch mit der Installation und Analyse von Whidbey.

Whidbey ist der Nachfolger der Visual Studio .NET Entwicklungsumgebung und bildet zu-gleich auch das .Net Framework der zweiten Generation.

Hierbei werden einige der herausragenden Features von Whidbey, wie z.B. Generics, Ob­ject Spaces, Whitehorse und Clickonce-Deployment vorgestellt.

Abbildungsverzeichnis

Abbildung 1 Das Longhorn SDK

Abbildung 2 WinFX [23]

Abbildung 3 Longhorns 3 Säulen-Modell [10]

Abbildung 4 Das Beste von Web und Windows [23]

Abbildung 5 Avalon [4]

Abbildung 6 Code Behind mit XAML [23]

Abbildung 7 Aufbau WinFS [10]

Abbildung 8 Aufbau NTFS [10]

Abbildung 9 WinFS-Items [10]

Abbildung 10 WinFS vordefinierte Schemata [10]

Abbildung 11 Schemata Beispiel [10]

Abbildung 12 Was ist Indigo [23]

Abbildung 13 Communication [4]

Abbildung 14 Services in Action [23]

Abbildung 15 NGSCB-Nexus [19]

Abbildung 16 NGSCB-Architektur [19]

Abbildung 17 Longhorn Services-Firewall

Abbildung 18 Treiberarchitektur [2]

Abbildung 19 Performance Vergleich Longhorn vs. WinXP

Abbildung 20 .NET Framework [11]

Abbildung 21 Die .NET Architektur [11]

Abbildung 22 nächste Generation der Entwicklerwerkzeuge [21]

Abbildung 23 Performancetest Whidbey

Abbildung 24 Installation Produkt key

Abbildung 25 Installation Setup

Abbildung 26 Beispiel Schema

Abbildung 27 a) Nessus Session Longhorn b) Nessus Scan-Optionen

Abbildung 28 Nessus-Scan

Abbildung 29 Aero [4]

Abbildung 30 Windows-Uhr

Abbildung 31 Windows-Uhr im Detail

Abbildung 32 Sidebar

Abbildung 33 Sidebar im Detail

Abbildung 34 Startmenü

Abbildung 35 Taskleiste

Abbildung 36 Windows-Explorer

Abbildung 37 Bilder im Detail

Abbildung 38 Internet Explorer

Abbildung 39 Speichern unter

Abbildung 40 Download Manager

Abbildung 41 Download Manager im Detail

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten¹

1 Einleitung

Ende Oktober 2003 rief Microsoft zur PDC (Professional Developer Conference) nach Los Angeles. Der gigantische Convention Center in Downtown Los Angeles war restlos ausver-kauft. Ca. 7000 Entwickler, Analysten und Pressevertreter besuchten die zahlreichen Sessi­ons. Das Interesse war gigantisch und das nicht ohne Grund. Denn während andere Micro­soft Events einem festen Zyklus gehorchen, gibt es PDC’s nur wenn Microsoft etwas Großes zu verkünden hat.

Bereits im Vorfeld der PDC wurde bekannt, dass sich alles um den Windows XP Nachfolger mit dem Codenamen Longhorn² drehen wird.

Für Microsoft Gründer Bill Gates stellt die Entwicklung von Longhorn den Produktlaunch des Jahrzehnts dar. Er verglich Longhorn mit der Einführung von Windows 953 und so mit dem Wechsel von der 16 Bit- auf die 32 Bit Architektur.

Gleichzeitig wurde jedoch kein genauer Termin für die Endversion von Longhorn genannt. Das einzige was durchsickerte war die Hardwarekonfiguration eines Longhorn PC’s. Demnach verfügt ein PC aus dem Jahre 2006/2007 über:

- CPU mit zwei Prozessor-Kernen und 4 bis 6 GHz
- mindestens 2 GByte Arbeitsspeicher
- Grafikkarte mit dreifacher Leistung
- Festplatte mit bis zu 1 Terabyte
- Gigabit-Netzwerkanschluss
- W-LAN-Adapter nach IEEE 802.11g

2 Longhorn

Microsoft hat zwar noch kein genaues Datum bezüglich der Veröffentlichung von MS Long­horn bekannt gegeben, aber einiges spricht dafür, dass nicht vor 2006 mit Longhorn zu rechnen ist. Diese Semesterarbeit soll sich neben der Installation hauptsächlich mit der Ana­lyse der herausragenden Features beschäftigen. Die kommenden Kapitel sollen hierzu ei-nen Einblick geben.

2.1 WinFX und das Longhorn SDK

Mit dem neuen Betriebssystem „Microsoft Longhorn“ werden viele neue Technologien und Funktionen eingeführt. Diese Features können anhand von dem „³-Säulen Modell“ gut dar-gestellt werden, welches in den folgenden Kapiteln näher erläutert wird.

Rund um diese Neuheiten rankt sich das ebenfalls neue Programmiermodell WinFX, dessen Besonderheit darin besteht, dass es nur so genannten Managed Code verwendet. D.h. die gesamte Funktionalität des Betriebssystems wird über Managed Code abgebildet.

Hierbei handelt es sich um Programmcode, der unter der .NET-Laufzeitumgebung, der Common Language Runtime, abläuft.

WinFX ist als Nachfolger von dem Win32 Application Programming Interface (API) zu se-hen. Nachdem Microsoft 1985 die Win16- und 1994 die Win32-API veröffentlicht hatte wird voraussichtlich ab 2005 die neue WinFX-API den Programmierern zur Verfügung stehen. Nach der eigentlichen Veröffentlichung benötigt jede API mehrere Monate und Jahre um sich bei den Programmierern als Standardplattform zu etablieren.

Neben der konsistenten Namensgebung, der Benutzbarkeit, der Globalisierung und der konsistenten Parameteranordnung wurde bei der Implementierung von WinFX das Haupt-augenmerk auf, das Thema Nummer eins von Microsoft, die Sicherheit gelegt. Das heißt Microsoft probiert Probleme wie z.B. Bufferoverflows zu vermeiden und sich dadurch auch die negativen Schlagzeilen in der Presse zu ersparen. Zitat über WinFX von Bernd Mar­quardt (MSDN Regional Director in Deutschland) auf der Technical Summit 2004: „Da hat man, was man so bisher sehen kann, ganze Arbeit geleistet!“

WinFX soll sich vor allem durch höhere Produktivität sowie eine gesteigerte Sicherheit von Applikationen auszeichnen.

Man kann auch weiterhin mit dem Win32– Software Development Kit (SDK) programmieren, hat hierbei aber nicht die Möglichkeit neue „Longhorn“ Applikationen zu entwickeln. Um sol-che Anwendungen zu programmieren benötigt man WinFX. Dieses Kürzel ist nicht mit WinFS zu verwechseln, das etwas später erläutert wird. Das Kürzel FX von WinFX steht für das Framework.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1 Das Longhorn SDK

Die Grafik zeigt, dass WinFX wie auch Win32 eine Teilmenge der Longhorn SDK sind. Das SDK wird benötigt um eine vollständige Longhorn Applikation zu erstellen. Die .NET Frame-work-Klassenbibliothek ist ein Bestandteil von WinFX, so dass WinFX die Ablösung für das mit Windows NT eingeführte Win32-API bedeutet.

Die Kompatibilität soll dadurch allerdings nicht leiden, auch .NET Framework- und Win32-Anwendungen sollen Zugriff auf die Möglichkeiten von WinFX erhalten.

WinFX basierende Anwendungen werden jedoch nur auf Longhorn und späteren Systemen laufen können, eine Portierung auf ältere Betriebssysteme ist nicht vorgesehen. Dadurch zeigt bzw. macht Microsoft einen deutlichen Bruch zu der nicht-objektorientierten Vergan-genheit. Aber auch „alte“ Anwendungen werden weiterhin unter Longhorn laufen, da auch das Win32–API ein Teil des Longhorn SDK ist.

Das Managed Code-basierte WinFX kann man nur voll ausnutzen, wenn man eine der 28 .NET -Programmiersprachen verwendet.

Da ein rein prozedurales Programmieren nicht mehr zeitgemäß ist und die bisherige Prog-rammierschnittstelle Win32 im C-Stil, d.h. weder objektorientiert noch komponentenbasiert ist war es für Microsoft an der Zeit eine neue API zu entwickeln.

WinFX ist eine riesige API (was die Abbildung 2 auch verdeutlichen soll) und stellt dem Ent-wickler viele Funktionalitäten zur Verfügung, dadurch sollen sich die zu programmierenden Codezeilen deutlich verringern. Jede API von Microsoft Longhorn wird hierbei unterstützt bzw. steht im Longhorn SDK zur Verfügung.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2 WinFX [23]

WinFX will neben der Entwicklung von High-Level Anwendungen auch eine einfache Ent-wicklung von Low-Level-Funktionalitäten ermöglichen. Hierbei ist eine spezielle und tief grei-fende Software gemeint.

Unter Longhorn wird Windows erstmals eine nach einheitlichen Richtlinien gestaltete Klas-senbibliothek erhalten, die einzelne Teile des Betriebssystems kapselt.

Wie auch schon erwähnt baut WinFX auf dem bereits verfügbaren .NET auf. Das .NET-Framework stellt hierbei allerdings nur einen extrem kleinen Teil von WinFX dar, denn WinFX kapselt wirklich das komplette System, einschließlich aller Objekte die bei XP in Form von Add-on-Bibliotheken zu haben sind.

2.2 3-Säulen Modell

Microsofts Longhorn Technik stützt sich vor allem auf drei Säulen: Avalon, WinFS und In­digo. Hierdurch soll eine Trennung von Präsentation, Daten und Kommunikation erreicht werden. Für die Präsentation wurde Avalon, für die Datenspeicherung das Windows Future Store (WinFS) und für die Kommunikation Indigo entwickelt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3 Longhorns 3 Säulen-Modell [10]

Diese drei Säulen stützen sich auf die so genannten Fundamentals (Systemdienste). Hierzu zählt z.B. das Schatten-Betriebsystem NGSCB und eine Funktion namens ClickOnce, mit der es möglich sein soll, Programme für Longhorn zu entwickeln, die sich selbstständig auf dem neuesten Stand halten. Hierbei laden sich die Anwendungen automatisch ohne Benut-zer Aktion die Updates aus dem Internet herunter und halten sich so auf dem neusten Stand.

2.2.1 Avalon

Wie bei Windows üblich wird auch in Longhorn viel Wert auf ein benutzerfreundliches Gra­phic User Interface (GUI) gelegt. Das heißt Microsoft will Longhorn visuell noch anspre-chender für die Benutzer gestalten. Dies soll durch die Präsentations-Säule bzw. Präsentati-ons-Subsystem mit dem Codenamen Avalon gewährleistet werden. Avalon stellt das Next Generation Windows U ser I nterface (UI) dar und ist somit das sichtbarste Thema, bei der Vorstellung der Longhorn Features. Avalon ist der Name für das GUI Framework von Long­horn und soll den Umgang mit vielen Daten, wie z.B. Office Dokumenten, Emails, aber vor allem Multimedia vereinfachen.

2.2.1.1 Ziel

Durch Avalon sollen neue Formen von Windows Anwendungen ermöglicht werden, die den Webanwendungen immer ähnlicher werden. Das bezieht sich nicht nur auf das Design, son-dern immer mehr auch auf die Bedienung. Hierbei wird sehr deutlich das Microsoft das Ziel verfolgt das Beste bzw. die Vorteile vom Web (Internet) und den klassischen Windows Sys-temen, in dem Betriebssystem MS Longhorn zu vereinen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4 Das Beste von Web und Windows [23]

Bei vielen Longhorn bzw. Avalon Anwendungen wird man den Eindruck haben, dass diese interaktiven Clientanwendungen immer mehr wie Internetanwendungen aussehen und auch so arbeiten. Man klickt durch den Windows Explorer und hat den Eindruck man navigiert mit dem Internet Explorer durch Webpages (Beispiele siehe Anlage F). Microsoft lässt ihren Internet Explorer immer weiter mit dem Windows Explorer verwachsen und gibt auch dem User bzw. Entwickler mit der neuen e Xtensible Application Markup Language (XAML) die Möglichkeit neue Anwendungen in diesem Stil zu programmieren. Die im Internet immer stärker werdende Trennung zwischen Webdesign und Webprogrammierung (Funktionalität) will Microsoft durch XAML auch in Longhorn umsetzten.

2.2.1.2 Architektur und Funktionalität

Avalon baut nicht auf den herkömmlichen Windows Forms bzw. Win32 auf, sondern das .NET Framework wurde um mehrere neue Klassen erweitert. Diese neue Technologie soll die bekannten Schnittstellen wie das Graphical Device Interface (GDI), GDI+ und zum Teil auch DirectX ablösen und ist tief in dem Betriebssystem verwurzelt.

Bei Longhorn soll keine pixelbasierte Darstellung wie bisher, sondern eine dpi⁴-unabhängige, d.h. auflösungsunabhängige Vektorgrafik mit Windows Vector Graphics (WVG) genutzt werden. Ein Grund hierfür ist sicherlich das man mit den Bitmap-basierenden Systemen, bei den immer größer werdenden Bildschirmen mit höheren Auflösungen, schnell an die Grenzen des Machbaren stößt. Ein weiteres Feature dieser WVG Technologie ist, dass man einen stufenlosen Zoom erhält.

Die einzelnen Elemente (wie z.B. Buttons, DataGrids oder Labels) werden sich auch ohne großen Aufwand transformieren, d.h. beliebig drehen, spiegeln, verzerren, etc. lassen, da sie über Vektoren beschrieben werden.

Die verschiedenen Technologien, die heute bestehen um Oberflächen auf dem Windows Desktop anzuzeigen sollen bei Avalon zusammengefasst werden. Avalon schafft dadurch ein einheitliches Modell für UI, Dokumente und Medieninhalte.

Das bedeutet man möchte eine flexible Architektur bekommen, die die verschiedenen Tech-nologien integriert.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5 Avalon [4]

Ein herausragendes Merkmal von Avalon ist neben den vielen neuen Controls das Composi-ting –das einfache Überlagern von mehreren Elementen zu einem neuen. So hat man z.B. die Möglichkeit einen Button zu erzeugen, in dem man Button-, Text-, Grafik- oder sogar Vi-deostream-Elemente übereinander legt. Dieser Button, der gar nicht mehr wie ein solcher aussieht, aber sich immer noch wie einer verhält wäre mit den heutigen Technologien nicht mit dieser Einfachheit zu realisieren.

Das Build 4051 von Longhorn ist noch 2 Dimensional, d.h. die von Microsoft angekündigte, auf dem neuen Grafik-Framework basierende grafische 3D-Benutzungsoberfläche "Aero" wurde noch nicht implementiert. Weitere grafische und funktionale Features, wie z.B. die neue Sidebar, werden in den Anlagen F anhand einiger Screenshots vorgestellt.

Um alle Möglichkeiten von Avalon sinnvoll umsetzen zu können wird man sicherlich leis-tungsfähige Grafik-Hardware benötigen.

2.2.1.3 XAML

XAML ist eine Markup Sprache, die Benutzeroberflächen deklarativ beschreibt und somit Windows-Anwendungen wie Internetseiten wirken lässt. Die Anwendungsoberflächen wer-den nicht mehr programmiert, sondern durch XAML deklariert. Es handelt sich hierbei um einen neuen Ansatz von Microsoft das GUI für Applikationen zu definieren.

Nicht nur das Navigieren sondern auch der Aufbau erinnert stark an das ASP.NET Konzept von Microsoft. Eine Trennung von UI (Darstellung) und Code kann durch das von .NET be-kannte Code-Behind Konzept auch in XAML erreicht werden.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 6 Code Behind mit XAML [23]

Avalon bzw. die Markup Sprache XAML ermöglicht eine Komposition von Elementen. D.h. Elemente wie z.B. ein Button können als Container für andere Elemente dienen. Man könnte z.B. ein Button als Container für ein Video-Stream Element benutzen.

Daneben haben alle Controls Eigenschaften die in der XAML Datei einfach hinzugefügt wer-den können. Neben den statischen Eigenschaften sollen auch sich zeitlich veränderbare Ei-genschaften relativ einfach programmierbar sein. Dadurch können auf einfachem Wege An-wendungsoberflächen und Animationseffekte hinzugefügt werden.

[...]

---

¹ Abkürzung steht für die Anfangsbuchstaben der Entwickler des RSA-Algorithmus

² Longorn: 1.) Codename des Windows XP Nachfolger. 2.) Namen einer Büffelart

³ Früheres Betriebssystem der Firma Microsoft. Erschienen 1995/1996

⁴ dots per inch / Punkte pro Zoll