MSDN Magazin > Home > Ausgaben > 2008 > August >  Tiefe Einblicke in CLR: Programmieren von Silve...
Tiefe Einblicke in CLR
Programmieren von Silverlight mit der CoreCLR
Andrew Pardoe
Silverlight™ 2.0 enthält einige Änderungen am Benutzeroberflächen-Framework von Windows® Presentation Foundation (WPF): Neue Steuerelemente, umfangreiche Netzwerk-APIs und Unterstützung für die Verwaltung digitaler Rechte (Digital Rights Management, DRM). Eine wichtige Änderung in Silverlight 2.0 ist die Möglichkeit, Microsoft® .NET-kompatible Sprachen zum Programmieren des Webclients zu verwenden. In diesem Artikel liegt der Schwerpunkt auf dem Entwicklungskern von Silverlight: CoreCLR.
Die letzten zehn oder fünfzehn Jahre haben uns viele verschiedene Technologien zur Webprogrammierung beschert, von CSS bis hin zu Varianten des ECMA­Skripts. Die meisten von ihnen beziehen sich speziell auf die Aufgabe der Webpogrammierung, denn Fähigkeiten, die beim CSS-Programmieren erlernt werden, sind in anderen Domänen nicht anwendbar. Im Gegensatz dazu ermöglicht Ihnen Silverlight 2.0, die gleichen .NET Framework-Fähigkeiten, die Sie für die Desktopprogrammierung verwenden, wie z. B. die Basisklassenbibliothek, XAML und C#, direkt auf Webclientanwendungen anzuwenden. Außerdem mussten wir keine separate CoreCLR-Entwicklungsumgebung erstellen: Sie können einfach Visual Studio® verwenden, um beim Entwerfen, Entwickeln, Debuggen und der Profilerstellung bezüglich C# oder Visual Basic® ebenso vorzugehen, wie Sie dies bei einer Desktopanwendung tun würden. Silverlight 2.0 CoreCLR wurde mit dem Ziel erstellt, die Webprogrammierung ebenso reichhaltig wie die Desktopprogrammierung zu machen.
Für Entwickler ist es zwar gut, eine reichhaltige Programmierumgebung zu haben, aber Benutzer möchten keine großen Browser-Plug-Ins herunterladen. Damit Silverlight bei den Benutzern Erfolg hat, musste für eine schnelle Installation gesorgt werden. Wir konnten die Beta 1-Installation auf 4,3 MB verkleinern. Das entspricht einer Installationszeit von etwa 6 bis 10 Sekunden über eine Breitbandverbindung. Dies ist eine erstaunliche Leistung, wenn Sie bedenken, dass die zwei wichtigen Kernkomponenten von .NET Framework 2.0 CLR – mscorwks.dll und mscorlib.dll – die jeweils gleiche Größe haben wie coreclr.dll und mscorlib.dll von Silverlight 2.0 zusammen.

Einblicke in das CoreCLR-Modul
Der Entwurf von CoreCLR begann gleich nach der Veröffentlichung der Version 2.0 von CLR im Oktober 2005. Die zwei Schwerpunkte beim Entwurf waren dabei Größe und Kompatibilität: Vom Standpunkt eines Programmierers muss das Programmieren mit der CLR immer gleich sein, wohingegen vom Standpunkt eines Benutzers der Download sehr klein sein muss. Da Silverlight auf einen unterschiedlichen Satz von Szenarios von der Desktop-CLR abzielt, konnten einige Änderungen vorgenommen werden, durch die CoreCLR vereinfacht und die Größe der Silverlight-Installation verringert werden konnte. Die dem Stapel zugrunde liegende Konsistenz ist jedoch sehr wichtig. Verhaltensunterschiede, selbst wenn sie korrekt sind, manifestieren sich weiter oben im Stapel als Fehler.
Zum Gewährleisten der Kompatibilität wurde der gleiche Code für die Komponenten ganz unten im Stapel verwendet. Das Ausführungsmodul und der virtuelle Computer sind identisch. Dies umfasst das Typsystem und die Metadaten, den Garbage Collector (GC), den JIT-Compiler und den Threadpool sowie andere zentrale Teile des Laufzeitmoduls.
Einige Änderungen wurden jedoch als Anpassung an das Webanwendungsszenario vorgenommen. Da zum Beispiel umfassende Internetanwendungen normalerweise einfach sind und eine kurze Ausführungszeit haben, konzentriert sich der JIT-Compiler auf die Verkürzung der Startzeit statt auf die Ausführung komplexer Optimierungen. Ebenso eignet sich der Server-GC-Modus, der auf mehrere Arbeitsthreads, die ähnliche Zuordnungsmuster verwenden, abgestimmt ist, nicht für webgehostete Anwendungen. Deshalb enthält Silverlight nur den Standardarbeitsstations-GC, der auf interaktive Anwendungen abgestimmt ist. Aber Microsoft Intermediate Language (MSIL) und Metadaten, die in Silverlight-Anwendungen verwendet werden, sind mit dem, was in verwalteten Anwendungen für den Desktop verwendet wird, identisch und sorgen für ein konsistentes Verhalten Ihrer Anwendung vom Desktop des Benutzers bis zum Browser.
Die Tatsache, dass Silverlight nicht dazu dient, die Desktop-CLR zu ersetzen, hatte die größte Änderung im zentralen Modul zur Folge: CoreCLR wird gleichzeitig im Prozess mit der Desktop-CLR ausgeführt. Bisher konnten nie zwei Versionen der CLR vom gleichen Prozess ausgeführt werden. Es gibt einige Gründe, warum dies ein schwieriges Problem ist. Ein Grund ist das Verwalten eines prozessweiten Zustands: Jede Instanz der CLR geht davon aus, dass sie die einzige im Prozess ist und folglich die einzige, die mit den statischen Daten arbeitet. Wenn in den Versionen 1.1 und 2.0 der CLR die Variable „staticFoo“ vorhanden ist und beide Versionen der CLR im gleichen Prozess gleichzeitig geladen werden, kann keine der Versionen in die Variable „staticFoo“ schreiben, ohne den Zustand der anderen CLR zu beeinflussen.
Der prozessweite Zustand ist zwar das offensichtlichste Problem, aber es können auch andere Probleme entstehen, wenn zwei CLR gleichzeitig in einem einzelnen Prozess ausgeführt werden. Wenn Sie z. B. zwei GCs gleichzeitig ausführen, stellt sich die Frage, wie Sie einen GC davon abhalten, den Thread des anderen GC zu unterbrechen. Darüber hinaus ist der Speicherbedarf ein Problem: Wenn Sie mehrere CLRs in einen Prozess laden, muss jeder Prozess Code laden, der allgemein sein kann und seinen eigenen Speicherplatz für statische Variablen und verwaltete Heaps besitzt.
Es gibt einige wichtige Szenarios, die die Möglichkeit erfordern, CoreCLR gleichzeitig mit der Desktoplaufzeit zu hosten. Wenn CoreCLR und die Desktop-CLR nicht gleichzeitig ausgeführt werden könnten, wäre es unmöglich, eine Desktop-Windows Forms- oder WPF-Anwendung zu schreiben, die ein Webbrowser-Steuerelement hostet, das zu einer Webseite navigiert, die Silverlight verwendet. Zur Umgehung dieses potenziellen Problems hätten wir einfach dafür sorgen können, dass Silverlight von der CLR abhängt, die auf Ihrem Windows-Computer installiert ist: Jede Installation von Windows XP SP2 und Windows Vista® hat eine relativ neue CLR, die mit dem Betriebssystem installiert wird. Wenn jedoch der gesamte Silverlight-Code auf CoreCLR ausgeführt wird, gewährleistet dies absolute Kompatibilität, unabhängig davon, welche CLR Sie auf Ihrem Computer installiert haben (oder, wie im Fall von Mac OS X, selbst wenn keine CLR auf Ihrem Computer installiert ist). Also haben wir dafür gesorgt, dass CoreCLR gleichzeitig im Prozess mit der Desktop-CLR ausgeführt wird, und wir denken, dass die Benutzer dadurch eine viel bessere Silverlight-Erfahrung haben.

Das CoreCLR-Sicherheitsmodell
Eine andere große Änderung im zentralen Modul hat mit dem neuen Sicherheitsmodell zu tun. Beachten Sie, dass .NET-Entwickler traditionell die Codezugriffssicherheit (Code Access Security, CAS) verwendet haben, um zu verhindern, dass nicht vertrauenswürdiger Code privilegierte Vorgänge ausführt. CAS ist sehr leistungsfähig, aber ziemlich kompliziert. Sie ermöglicht dem Benutzer oder dem Administrator, mithilfe von Berechtigungssätzen verschiedene Sandboxes für Code zu definieren und diesen Sandboxes einzelne Assemblys zuzuweisen. Für Silverlight-Anwendungen wird nur eine Sandbox benötigt, die der Sandbox entspricht, die von Internet Explorer® für das Ausführen eines Skripts auf einer Webseite verwendet wird. Dieses vereinfachte Szenario ermöglichte uns, alle CAS-Richtlinien zu entfernen.
Außerdem wurde das Modell der Sicherheitsdurchsetzung vereinfacht. Das neue Modell basiert auf Sicherheitstransparenz, einem in Version 2.0 der CLR eingeführten Konzept. Im Mittelpunkt dieses Transparenzmodells steht eine Einstufung Ihres Codes in eine der drei Codebereiche: „Transparent“, „SafeCritical“ oder „Critical“. „Transparent“, die niedrigste Vertrauensebene für Code, kann die Berechtigungen für privilegierte oder vertrauliche Ressourcen oder Informationen auf dem Computer nicht höher stufen. In Silverlight 2.0 ist jeglicher Anwendungscode transparent. Critical-Code, die vertrauenswürdigste Ebene für Code, kann mit dem System durch P/Invokes interagieren oder sogar nicht nachprüfbaren Code enthalten. Für Silverlight 2.0 muss jeglicher Critical-Code Teil der Silverlight-Plattform sein. SafeCritical-Code dient dann als die Brücke, die Transparent-Code ermöglicht, durch Aufrufen von Critical-Code auf Systemressourcen zuzugreifen. Stellen Sie sich Critical-Code als die Kernel-APIs von Windows vor, Transparent-Code als den Benutzeranwendungscode und SafeCritical-Code als die API zwischen dem Benutzercode und dem Kernelcode.
Transparent-Code kann nur anderen Transparent- oder SafeCritical-Code aufrufen. SafeCritical-Code kann dann Critical-Code im Auftrag des Benutzercodes aufrufen. SafeCritical-Code ist dafür zuständig, die Eingaben zu kanonisieren bzw. in ein Standardformat einzuordnen und die Ausgaben des Critical-Codes zu bereinigen, um die Sicherheit des System zu gewährleisten (siehe Abbildung 1).
Abbildung 1 Sicherheitsdurchsetzung in der CoreCLR (zum Vergrößern auf das Bild klicken)
Der Grund für das Kanonisieren der Eingaben in Critical-Code ist etwas offensichtlicher als der Grund für das Bereinigen der Ausgaben. Wenn meine Webanwendung zum Beispiel in eine Datei auf dem lokalen Datenträger schreiben will, kann sie dies mithilfe von isoliertem Speicher tun. Sie soll dann aber nicht in eine Datei namens „..\..\..\..\bootmgr“ schreiben, also ist es wichtig sicherzustellen, dass die Eingabe in einem regulären, kanonischen Format erfolgt. Es ist schon etwas ungewöhnlicher zu denken, dass die Ausgaben des Critical-Codes ein Sicherheitsrisiko sind. Das Hauptsicherheitskonzept besteht darin, dass die Kontrolle der veröffentlichten Informationen sehr wichtig ist, um einem Angreifer so wenig Angriffsfläche wie möglich zu bieten. Angenommen, Sie versuchen, auf bestimmte Benutzerinformationen auf Ihrem System zuzugreifen, und die Antwort lautet „Berechtigung verweigert“. Wenn Sie den gleichen Zugriffsvorgang, dieses Mal für einen anderen Benutzer, wiederholen, lautet die Antwort „Benutzer … existiert nicht“. Wenn Sie wissen, dass Sie beide Antworten erhalten, können Sie wiederholt ungültige Zugriffe versuchen, um eine Liste von Benutzernamen auf dem System zu erlangen.
Eine vereinfachte Sicherheitsrichtlinie ist ein klarer Sieg für Entwickler, die im .NET-Code arbeiten, aber sie hilft auch Entwicklern, die am .NET-Code arbeiten. Wir haben versucht, so wenig Code wie möglich als „Critical“ und „SafeCritical“ zu kennzeichnen. Dass der Großteil des Codes transparent ist, hilft uns, den Umfang des Codes, der eine detaillierte Sicherheitsprüfung benötigt, gering zu halten. Wir müssen nach wie vor unseren Transparent-Code auf seine Korrektheit und Sicherheit überprüfen, aber wir wissen zumindest, dass er keine privilegierten Vorgänge durchführen kann. Große Teile von Silverlight, einschließlich der Dynamic Language Runtime (DLR), sind vollständig in Transparent-Code geschrieben. Die privilegierten Teile von Silverlight einzuschränken, ermöglicht uns, ein sichereres Produkt zu veröffentlichen, indem wir unsere Aufmerksamkeit auf die Bereiche richten, die tatsächlich einer sorgfältigen Prüfung bedürfen.

Die Basisklassenbibliothek
Das .NET Framework wurde auf dem Desktop weiterentwickelt, um sowohl Benutzern als auch Serverszenarios gerecht zu werden. Deshalb ist in der Basisklassenbibliothek (Base Class Library, BCL) viel Funktionalität enthalten, die in Webclientszenarios keinen Sinn macht. Beispielsweise unterstützt Silverlight nicht CAS. Deshalb ist ein Großteil von System.Security nicht notwendig. Viele andere Klassen, wie System.Console, machen im Web keinen Sinn. (Warum ist dann eine vereinfachte System.Console-Klasse vorhanden? Sie hilft uns, das Produkt zu testen.)
Wir haben für die Bibliotheken das gleiche Ziel wie für das zentrale Modul: das Einschränken auf den kleinsten Satz der Funktionalität, die es .NET-Entwicklern ermöglichen würde, erfolgreich zu sein, ohne eine vollständig neue Technologie erlernen zu müssen. Dabei bot uns .NET Compact Framework, bei dem das gleiche auf ein anderes Szenario angewendete Problem behandelt wurde, einige Anregungen und Anleitungen. Beim Zuschneiden der BCL für Silverlight haben wir die Kompatibilität zwischen .NET Compact Framework und Silverlight beibehalten. Die Freigabe einer einzelnen Bibliothek zwischen allen Plattformen hat auf diese Weise die Wiederverwendbarkeit von .NET-Fähigkeiten maximiert.
Es gibt einige Orte in der BCL, an denen Sie eine duplizierte Funktionalität finden können. Manchmal wird die Funktionalität innerhalb der BCL dupliziert. Dies ist der Fall bei generischen und nicht generischen Sammlungen. Manchmal existiert die Funktionalität bereits im Basisbetriebssystem, wie im Fall der Globalisierungsunterstützung. Es ist nicht nur unnötig, jede Alternative in der Silverlight-BCL zu unterstützen, sondern wir können auch Gewinne bei der Leistung und der Konsistenz erzielen, indem wir dieses duplizierte Verhalten streichen.
Seit der Einführung der Unterstützung für generische Sammlungen in Version 2.0 von .NET Framework haben wir uns dafür ausgesprochen, dass die Benutzer zu Generika übergehen. In Version 1.x der Laufzeit mussten allgemeine Datenstrukturen auf Objekten basieren, damit die gleiche zentrale Datenstrukturklasse verwendet werden konnte, um Sammlungen verschiedenen Typs zu erstellen. Mit Parametern des generischen Typs kann der Compiler diese allgemeinen Datenstrukturen erweitern, um eine Typsicherheit zu bieten, sodass das Schreiben und Verwalten von Code erleichtert wird. Darüber hinaus erzielen generische Sammlungen bei Werttypen in der Regel eine bessere Leistung als spezifische Sammlungen, weil es keinen Grund gibt, Elemente einzugrenzen. Insgesamt bieten Generika sämtliche Funktionalität, die nicht spezifische Sammlungen bieten. Da die Duplizierung unnötig ist, sind in der Silverlight-BCL keine nicht spezifischen Sammlungen wie ArrayList enthalten.
Jeder ist zumindest mit einigen mit der Globalisierung verbundenen Problemen vertraut: Viele europäische Kulturen verwenden ein Komma als Dezimalzeichen. Chinesische Zahlen sind in Vierergruppen unterteilt (1000.0000) und so weiter. .NET Framework implementiert die Globalisierungsfunktionalität intern, sodass es in verschiedenen Kulturen ordnungsgemäß funktioniert. Um dies zu ermöglichen, enthält es Globalisierungsdaten für alle unterstützten Kulturen, wodurch auf .NET abzielende Anwendungen ein konsistentes Verhalten in allen unterstützten Versionen von Windows aufweisen können. Dabei gibt es jedoch auch Nachteile. Die CLR muss große Datentabellen enthalten, und die Daten veralten mit der Zeit. Außerdem sind die Daten Windows-zentriert, d. h. die Daten für einige .NET-Kulturen unterscheiden sich von den gleichen Kulturen in Mac OS X. Deshalb enthält die CoreCLR keine eigenen Globalisierungsdaten. Stattdessen wird von System.Globalization.CultureInfo die Globalisierungsfunktionalität verwendet, die vom Hostbetriebssystem bereitgestellt wird. Folglich werden sich Silverlight-Anwendungen unter Mac OS X eher wie Mac-Anwendungen und unter Windows wie Windows-Anwendungen verhalten.
Insgesamt haben wir versucht, eine ähnliche API-Oberfläche für die CLR, .NET Compact Framework und Silverlight beizubehalten, aber es gibt andere kleine Unterschiede, die sich durch die BCL ziehen. Da Silverlight z. B. einen einzelnen Benutzeroberflächenthread besitzt, hat es ein einzelnes Dispatcher-Objekt, das eine Arbeitsaufgaben-Warteschlange für die Benutzeroberfläche enthält. Die Verwendung von Dispatcher ermöglicht Ihnen, die Benutzeroberfläche über einen Nichtbenutzeroberflächenthread zu aktualisieren. Dieser Code ermöglicht Ihnen außerdem, ein Benutzeroberflächenelement, MyListBox, mit einer Sammlung, die auf einem anderen Thread erstellt wird (beispielsweise von einem Hintergrundthread) zu aktualisieren:
MyListBox.Dispatcher.BeginInvoke(() => MyListBox.ItemsSource = MyItems); 
Wir empfehlen, dass Sie in Silverlight System.ComponentModel.BackgroundWorker verwenden, weil es bei Abschluss die Aktualisierung der Benutzeroberfläche einkapselt, aber zum Zwecke der Kompatibilität sind nach wie vor untergeordnete Threading-APIs (wie z. B. System.Threading.ThreadPool.QueueUserWorkItem und System.Threading.Monitor.Enter) enthalten.
Wie das Sicherheitstransparenzmodell war manche Funktionalität, die in der Silverlight-BCL neu ist, bereits in früheren .NET Framework-Veröffentlichungen zu finden. Ein gutes Beispiel dafür ist der isolierte Speicher, der Sandboxanwendungen ein virtualisiertes Dateisystem bietet. Er existiert seit .NET Framework 1.0, aber diese Funktionalität hat immer nur begrenzte Szenarios behandelt. Silverlight konzentriert sich auf Sandboxanwendungen und kann daher die Verwendung des isolierten Speichers vollständig nutzen:
using (IsolatedStorageFile isoStore = 
    IsolatedStorageFile.GetUserStoreForApplication())
{
    using (StreamWriter writer = new StreamWriter(isoStore))
    {
         writer.Write("This is an isolated storage file.");
    }
}
Wie Cookies in einem Webbrowser ermöglicht der isolierte Speicher Silverlight-Anwendungen, um den Status aufrufübergreifend beizubehalten. Der isolierte Speicher bietet jedoch ein vollständiges virtualisiertes Dateisystem, das die Erstellung von Verzeichnissen und Dateien unterstützt. Obwohl der isolierte Speicher nicht als Speicher für hochwertige Daten, z. B. Kennwörter, gedacht ist, wird der Speicherort verschleiert, und der Zugriff ist auf jene Anwendung begrenzt, die den Speicher besitzt.
Kontingente für isolierten Speicher werden von Anwendungsgruppen definiert, die auf dem Domänennamen der Silverlight-Anwendung basieren. Zum Beispiel würden zwei Microsoft-Anwendungen, die sich in Verzeichnissen unter microsoft.com befinden, eine Anwendungsgruppe freigeben, d. h., beide Anwendungen würden das gleiche Kontingent gemeinsam verwenden. Standardmäßig erhält eine Anwendungsgruppe 1 MB Speicherplatz.
Wenn eine Anwendung jedoch zusätzlichen Speicherplatz benötigt, kann sie ein größeres Kontingent anfordern, indem sie den Benutzer mit einem Dialogfeld, in dem z. B. mitgeteilt wird, dass microsoft.com sein Kontingent auf 8 MB erhöhen will, dazu auffordert. Benutzer können den isolierten Speicher aktivieren oder deaktivieren und die aktuellen Verwendungen im Silverlight-Konfigurationsdialogfeld löschen (wird im Dialogfeld „Anwendungsspeicher“ genannt). Anwendungsgruppen können außerdem über freigegebene Speicher verfügen, die verwandten Anwendungen ermöglichen, Daten untereinander freizugeben.
Während der isolierte Speicher bereits seit einiger Zeit existiert, waren seine Verwendungen noch nie so überzeugend wie jetzt mit Silverlight. Ein konfigurierbares sicheres Dateisystem für interaktive Webanwendungen ermöglicht die Entwicklung von traditionellen Office-Anwendungen (z. B. Textverarbeitungsprogramme) oder von Anwendungen, die große Datenmengen verwalten (z. B. Systeme zur Nachverfolgung von Aktien).

Plattformübergreifendes Arbeiten
Silverlight wird auf Nicht-Windows-Plattformen ausgeführt. Wir haben eine Partnerschaft mit Novell, um Linux durch die Moonlight-Laufzeit des Mono-Projekts zu unterstützen. Microsoft bearbeitet außerdem eine Version von Silverlight für das branchenführende Symbian-Betriebssystem und für Windows Mobile®. Moonlight wird unter Mono ausgeführt, und die mobile Version von Silverlight wird unter .NET Compact Framework ausgeführt (was einen viel geringeren Speicherbedarf hat als CoreCLR). Die Mac OS X-Version von Silverlight wird aber auf der gleichen CoreCLR ausgeführt wie Windows.
Wir haben dies mithilfe einer Plattformanpassungsschicht (Platform Adaptation Layer, PAL) erreicht. Die PAL ist eine API, die für den Betrieb auf verschiedenen Plattformen programmiert wurde. Sie bietet Abstraktionen für die Fehlerbehandlung, die Dateiverarbeitung, für Netzwerkdienste, Threadingsemantiken und so weiter. Funktionen in der PAL verwenden die gleichen Namen von Win32®-APIs, unterscheiden sich aber bei der Implementierung. Einige der APIs durchlaufen nur die Parameter der PAL-Funktion bis zu einer OS X-Funktion, während andere eine benutzerdefinierte Logik verwenden müssen, um die OS X-Funktionalität und die Windows-API-Signaturen aufeinander abzustimmen. Eine Windows-Funktionalität, die von CoreCLR verwendet wird, existiert auf dem Mac nicht und musste deshalb vollständig in PAL implementiert werden (siehe Abbildung 2).
Abbildung 2 Plattformanpassungsschicht (zum Vergrößern auf das Bild klicken)
Viele der Silverlight-PAL-Vorteile entspringen den Erfahrungen, die wir beim Entwickeln der SSCLI (Shared Source Common Language Infrastructure), auch als Rotor bezeichnet, gewonnen haben. Die SSCLI wurde auf einigen Plattformen im UNIX-Stil sowie unter Windows ausgeführt. Bei der Basisbetriebssystemfunktionalität gibt es große Unterschiede auf Plattformen im UNIX-Stil. Die SSCLI-PAL musste sowohl auf einem Mikrokernel (wie z. B. dem Mach-Kernel in Mac OS X) als auch auf einem monolithischen Kernel funktionsfähig sein und verschiedene Betriebssystemdienste, wie z. B. Threading, die Ausnahmebehandlung und Netzwerkstapel, bewältigen. Da Silverlight nur auf Windows- und Intel Mac-Computer abzielt, konnten wir Mac-spezifische Implementierungen für viele der Funktionen in der PAL schreiben, was hinsichtlich der Größe und der Leistung der PAL hilfreich ist.
Die PAL unterstützt nur die Teilmenge von Win32, die notwendig ist, um das Ausführen von Silverlight zu ermöglichen. Es gibt keinen Grund, die Registrierung, GDI+ oder COM zu unterstützen. Wir haben Windows weder auf der Grundlage von OS X implementiert, noch haben wir genügend Windows implementiert, um die gesamte Funktionalität der Desktop-CLR zu unterstützen. Das Begrenzen der PAL, sodass sie nur Silverlight unterstützt, ermöglicht, dass sie klein und schnell ist.
Die Unterschiede zwischen Betriebssystemen auszublenden, ist ein schwieriges Problem, wenn Sie in Betracht ziehen, wie sehr sich OS X von Windows unterscheidet. Ein Großteil von OS X ist in Objective C geschrieben und macht ein Ausnahmebehandlungssystem verfügbar, das mit C++ inkompatibel ist. Die CLR erstellt E/A-Threads, die von Arbeitsthreads verschieden sind. Diese basieren auf E/A-Abschlussports, die in Windows NT® 3.5 eingeführt wurden und unter OS X nicht existieren. Sogar etwas so Einfaches wie das Suchen einer Datei ist unter Mac anders, da unter Windows der umgekehrte Schrägstrich als Verzeichnistrennzeichen verwendet wird.
Im Laufe der Entwurfs- und Entwicklungsphase der CoreCLR haben wir uns auf eine Umgebung konzentriert, die Entwicklern ermöglicht, vorhandene Fähigkeiten und Tools wiederzuverwenden, um einen umfassenden Inhalt für eine kleine, sichere Laufzeit zu entwickeln. Die meisten Entscheidungen wurden dabei von den reduzierten Szenarios umfangreicher Internetanwendungen gesteuert, aber einige Entwürfe profitierten von der Arbeit, die wir in der Vergangenheit geleistet haben. Einige der Entscheidungen, die wir für CoreCLR getroffen haben, werden letztendlich wieder ihren Weg zum Desktop finden. Sie können sich z. B. auf die nächste Version der Desktop-CLR freuen, die gleichzeitig im Prozess mit anderen Versionen der CLR ausgeführt wird. Außerdem werden die meisten Änderungen, die für das verbesserte Sicherheitstransparenzmodell vorgenommen wurden, in unserer nächsten CLR erscheinen.
Es wurde sorgfältig in Betracht gezogen, was für webbasierte Szenarios sinnvoll ist und was die Laufzeit nicht enthalten muss. Wir hoffen, dass wir die richtige Auswahl getroffen haben, und vertrauen darauf, dass Sie uns mitteilen werden, wie wir für weitere Verbesserungen sorgen können. Viel Spaß beim Programmieren mit Silverlight 2.0, und behalten Sie diesen Bereich im Auge, was künftige tiefere Einblicke in CoreCLR betrifft.

Senden Sie Fragen und Kommentare in englischer Sprache an clrinout@microsoft.com.

Andrew Pardoe ist Programmmanager für CLR bei Microsoft. Er bearbeitet alle Aspekte des Ausführungsmoduls sowohl für Silverlight als auch für die Desktoplaufzeit. Andrew Pardoe kann unter Andrew.Pardoe@microsoft.com erreicht werden.

Page view tracker