Komfortabler Dateimanager mit vielen Funktionen

Unkaputtbar

By Sven on 25.06.2005 - 22:41 in MFC

Seit meinem Umstieg auf Visual C++ vor knapp 10 Jahren programmiere ich mit der MFC (Microsoft Foundation Classes), und im Laufe der Jahre habe ich die MFC als eine verlässliche und robuste Bibliothek kennengelernt. Die MFC deckt alle Grundlagen für eine moderne Windows-Anwendung ab, kleine oder größere Erweiterungen findet man entweder im Netz oder programmiert man sich selbst.

In dem einen oder anderen Gespräch mit C++Entwicklern konnte ich feststellen, dass sich mit dem nahenden Longhorn und der Werbung für die schöne .nette Welt gewisse Ängste entwickeln, dass man in naher Zukunft mit C++ und der MFC nur noch im Regionalexpress fährt und vom .NET-Transrapid bald überholt wird. Ich selbst teile diese Ansicht nicht, denn auch in Longhorn wird .NET ein Aufsatz auf dem Betriebssystem bleiben. Das Windows-API wird natürlich weiter Bestand haben, da einerseits das gesamte Betriebssystem darauf aufbaut und Microsoft sich auch nicht erlauben kann, mit Longhorn einfach alle Brücken zu „alter“ Software zu kappen. In diesem Fall müssten sie das gesamte Betriebssystem auf gänzlich neue Füße stellen, und das kann selbst Microsoft sich nicht leisten.

Auch Avalon und seine Beschreibungssprache XAML hat für den normalen Anwendungsprogrammierer keine wirkliche Bedeutung. Oder glaubt tatsächlich jemand, man könnte einen Dateimanager oder ein Packprogramm mit einer XML-Sprache programmieren? Das nun auf später verschobene WinFS wird sicher auch aus nativen Anwendungen ansprechbar sein, ansonsten wäre wohl keine Integration in den Explorer möglich.

Steve Teixeira hat nun einen Ausblick auf die Zeit nach Visual Studio 2005 gegeben, und dieser dürfte den einen oder anderen zweifelnden C++/MFC-Programmierer doch sehr erfreuen:

MFC continues to be the C++ application framework of choice for many developers because the breath and depth of support that MFC provides for the Microsoft platforms remains unmatched by other frameworks. Visual Studio 2005 makes it possible for the C++ developer to leverage existing C++ code, the strengths of MFC, and the advantages of .NET, all within a single application.

Looking beyond Visual Studio 2005, C++ developers should expect deepened integration between MFC and the .NET framework. After the release of Windows Longhorn, Microsoft intends to add MFC support for key Longhorn APIs and features. Microsoft also intends to support the Avalon user interface framework in MFC, providing MFC developers with a bridge to the future of platform user interface design. In essence, as the platform evolves, developers can look forward to seeing MFC updated to leverage the latest managed and native APIs and frameworks.

MFC developers have access to more frameworks than any other type of developer on the platform. As such, MFC developers are free to leverage the best from all worlds as it makes business and technological sense to do so. Microsoft fully expects to support this capability into the foreseeable future.

Also, auf die nächsten 10 Jahre!

Es gibt 3 Kommentare zu diesem Beitrag

Trackback URL | RSS-Feed für Kommentare

  1. Uwe sagt:

    Haha, Sven, da hast Du mich auch endlich mal in einem Blog-Eintrag verewigt 🙂 Aber meine Paranoia ganz abschütteln kannst Du natürlich nicht. Ein wenig lindern und positive Ausblicke geben schon.

    Danke 😀

  2. XML für GUI ist schon lange in viel genutzten Anwendungen (fast alles von Mozilla.org) in gebrauch. Der eigentliche Alptraum an XAML ist, daß fast alles an Styling in das XML rein muß (das Gegenteil von XHTML + CSS also).

    Abgesehen davon, daß .NET als API einige (absichtliche) Löcher hat, und die dazugehörigen IDEs (allen voran VS.NET aufwärts) ebenso, ist .NET definitiv die Zukunft für die Programmierung unter Windows. Es ist einfach wesentlich einfacher sichere Applikationen für Laufzeitumgebungen wie die .NET Runtime zu schreiben. Auch die Nutzung von externen Komponenten ist in solchen Umgebungen wesentlich vereinfacht. Man muß sich nur mal ansehen, mit wie wenig Aufwand man mit C# COM+ Komponenten schreiben kann, damit man die Schmerzhaftigkeit von C++ (und erst recht VB) erkennt.

Top