Sie sind hier
Windows Framework (WinFX)
Eintrag zuletzt aktualisiert am: 26.06.2019
Der Name WinFX hat eine Entwicklung vollzogen.WinFX war ursprünglich (Jahr 2003) angekündigt als Name der Programmierschnittstelle in Windows Longhorn, die das Win32-API in vielen Teilen ablöst. WinFX sollte mit der Version 6.0 (entsprechend der Betriebssystemversion) starten.
Später (2004) würde WinFX auf andere Windows-Systeme (Windows XP und Windows Server 2003) ausgedehnt und daher von dem Longhorn-Projekt gelöst. WinFX sollte eine Erweiterung zum .NET Framework 2.0 sein und es war im Gespräch, das .NET Framework in WinFX umzubenennen. Zu diesem Zeitpunkt erhielt WinFX die Versionsnummer 3.0.
Im Jahr 2006 hat sich Microsoft dann aber entschlossen, den Namen .NET Framework zu behalten und die neuen Funktionen von WinFX in das .NET Framework zu integieren und daraus das .NET Framework 3.0 zu machen.
Kernbestandteile (Stand September 2005, PDC 2005)
Windows Presentation Foundation (WPF), Codename AvalonWindows Communication Foundation (WCF), Codename Indigo
Windows Workflow Foundation (WWF)
Windows CardSpace (WCS) , früher: Infocard
Mit Ausnahme der Windows Workflow Foundation und CardSpaces lösen die Kernbausteine von WinFX andere Programmierkonzepte ab. WPF tritt an die Stelle der in das .NET Framework integrierten Windows Forms, WCF ist ein Ersatz für .NET Remoting, ASP.NET Webservices und den Anwendungsserver COM+.
Andere Bestandteile, die ursprünglich Teil von WinFX sein sollten
Windows File System (WinFS)Microsoft PowerShell, ehemals Microsoft Shell (MSH), Codename Monad
Text (Stand Oktober 2003, PDC 2003)
Die .NET-Klassenbibliothek ist in weiten Teilen lediglich ein Wrapper für Funktionen aus dem Win32-API oder bestehenden COM-Komponenten. In Redmond existiert die Vision, dieses Verhältnis irgendwann umzukehren und .NET-Komponenten zum primären API für Windows zu machen. Mit der nächsten Windows Version (2006, Codename Longhorn) wird Microsoft eine umfangreiche .NET-Klassenbibliothek mit Namen Windows Frameworks (WinFX) einführen, die den Weg zur "Verdotnettung" von Windows einläutet.Avalon, WinFS und Indigo sind per Programmcode ansprechbar über eine neue Klassenbibliothek die den Namen WinFX trägt. WinFX umfasst auch die heute .NET Framework-Klassenbibliothek, sodass WinFX die Ablösung für das mit Windows NT eingeführte Win32-API bedeutet. WinFX ist komplett in Managed Code geschrieben. Eine Portierung von WinFX auf ältere Betriebssysteme ist nicht vorgesehen, sodass WinFX-basierte Anwendungen nur auf Longhorn und späteren Systemen laufen können. Microsoft bricht hier also deutlich mit der nicht-objektorientierten Vergangenheit. Das Win32-API bleibt aber auch in Longhorn noch erhalten, sodass alte Anwendungen auf Longhorn laufen können.
Die bisherige primäre Programmierschnittstelle Win32 ist noch im C-Stil aufgebaut, also weder objektorientiert noch komponentenbasiert - wobei doch rein prozedurales programmieren schlicht und einfach als nicht mehr zeitgemäß zu bewerten ist. Viele Win32-Funktionen wurden in den letzten Jahren in COM-Komponenten gekapselt, wobei man den Komponenten stark anmerkte, dass sie von verschiedenen Leuten zu verschiedenen Zeiten gestaltet wurden. Durch WinFX erhält Windows in Longhorn erstmals eine nach einheitlichen Richtlinien gestaltete Klassenbibliothek, die große Teile des Windows-Betriebssystem kapselt.
Bei Microsoft ist ein deutlicher Trend zu erkennen, die Windows-Programmierschnittstellen zu vereinheitlichen. Dabei ist es sinnvoll und konsequent, auf die moderne .NET-Plattform und damit auf Managed Code zu setzen. Sowohl aus Sicherheitsgesichtspunkten als für die Betriebssystemunabhängigkeit werden sich für einen Großteil der Anwendungen nur Plattformen durchsetzen können, die ein Zwischensprachkonzept einsetzen, also Java oder .NET.
Entwickler, die nicht den Weg zu Managed Code nicht mitgehen wollen, werden zukünftig auf Funktionalität verzichten müssen. Während .NET-Anwendungen jede Win32-API-Funktion und COM-Komponente nutzen können, steht nicht jede .NET-Klasse auch alten Programmierplattformen zur Verfügung. Das Managed Code-basierte WinFX-API in Longhorn kann man nur voll ausnutzen, wenn man eine der 28 .NET-Programmiersprachen verwendet.
Eines Tages wird WinFX einmal nicht mehr als ein Aufsatz auf Win32 existieren, sondern Win32 wird eine Kompatibilitätsschicht auf Basis von WinFX sein. Das Verhältnis wird sich genau umkehren wie bei DOS-Ebene und Windows!