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 Studienarbeit 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 Betriebssystems in zwei Kerne und durch die Zusammenarbeit von spezieller Hard- und Software für mehr Sicherheit sorgen soll.

Neben der Installation und Analyse von Microsoft Longhorn wird die Studienarbeit durch eine 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 zugleich 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.

Seite  3 von  60

Inhaltsverzeichnis

Zusammenfassung   2

Inhaltsverzeichnis   3

Abbildungsverzeichnis   5

Abk  ürzungsverzeichnis  7

1  Einleitung  8

2  Longhorn  9

2.1  WinFX und das Longhorn SDK  9

2.2  3-Säulen Modell  11

2.2.1  Avalon  12

2.2.1.1  Ziel  12

2.2.1.2  Architektur und Funktionalität  13

2.2.1.3  XAML  15

2.2.2  Windows Future Store (WinFS)  16

2.2.2.1  Ziele von WinFS  16

2.2.2.2  Architektur  17

2.2.2.3  NTFS- Die Basis von WinFS  17

2.2.2.4  Datenmodell-Items  18

2.2.2.5  Info-Agenten  20

2.2.3  Indigo  20

2.2.3.1  Verteilte Systeme  20

2.2.3.2  Ziel  21

2.2.3.3  Einsatz von Indigo  21

2.2.3.4  Verfügbarkeit  24

2.3  NGSCB  24

2.3.1  Sicherheit durch Hard- und Software.  25

2.3.1.1  TP-MChips  25

2.3.1.2  Nexus Computing Agents.  25

2.3.1.3  Security Support Component  26

2.3.1.4  Wird NGSBC unter Longhorn zur Pflicht?  26

2.4  Sicherheitsanalyse Longhorn  27

2.5  Treiber unter Longhorn.  28

2.5.1  Longhorns Treiberinstallationsarchitektur  29

2.6  Performancevergleich Longhorn vs. Windows XP  30

3  NET Framework  32

Seite  4 von  60

3.1  Was ist das NET Framework?  32

3.2  Whidbey  34

3.2.1  Generics  36

3.2.2  Object Spaces  36

3.2.3  Whitehorse  36

3.2.4  Clickonce-Deployment  37

3.3  Performancevergleich Visual Studio NET vs. Visual Studio 2005 (Whidbey)  37

4  Fazit  39

Anlage  A: Literaturverzeichnis  41

Anlage  B: Installation Microsoft Longhorn  43

Anlage  C: Beispiel Schema WinFS  46

Anlage  :D Nessus  47

Anlage  E: Avalon Screenshots  49

Anlage  F: Bill Gates im Interview 10  56

Seite  5 von  

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  

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  

Seite  6 von  

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

AES Advanced Encryption Standard API Application Programming Interface CLR Common Language Runtime CLS Common Language Specification DCOM Distributed Component Object Model GDI Graphical Device Interface GUI Graphic User Interface IDE Integrated Development Environment JIT Just-in-Time Compiler MS Microsoft MSIL Microsoft Intermediate Language NCA Nexus Computing Agent NGSCB Next Generation Secure Computing Base ORM Object Relational Mapping RPC Remote Process Call RSA ¹ Rivest, Shamir, Adleman SDK Software Development Kit SHA-1 Secure Hash Algorithm 1 SOA Service Oriented Architecture SSC Security Support Component TMP Trusted Plattform Modul UI User Interface UML Unified Modeling Language VB Visual Basic WinFS Windows Future Store WinFX Windows Framework WVG Windows Vector Graphics XML eXtensible Markup Language XAML eXtensible Application Markup Language

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

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 ausverkauft. Ca. 7000 Entwickler, Analysten und Pressevertreter besuchten die zahlreichen Sessions. Das Interesse war gigantisch und das nicht ohne Grund. Denn während andere Microsoft 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 95 ³ 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

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

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

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 Analyse der herausragenden Features beschäftigen. Die kommenden Kapitel sollen hierzu einen 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 „3-Säulen Modell“ gut dargestellt 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 sehen. 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 Hauptaugenmerk 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 Marquardt (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.

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 Vergangenheit. 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 Programmierschnittstelle 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 Entwickler 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.

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

Unter Longhorn wird Windows erstmals eine nach einheitlichen Richtlinien gestaltete Klassenbibliothek 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 Indigo. 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.

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 Benutzer 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 UserInterface (GUI) gelegt. Das heißt Microsoft will Longhorn visuell noch ansprechender für die Benutzer gestalten. Dies soll durch die Präsentations-Säule bzw. Präsentations-Subsystem mit dem Codenamen Avalon gewährleistet werden. Avalon stellt das Next Generation Windows User Interface (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