Windows-Programmierung - die Zukunft
-
In letzter Zeit hat man viel von Avalon und WinFX gelesen - im Zusammenhang mit Windows Longhorn - also entschloss ich mich, der Sache etwas genauer nachzugehen.
Schnell werde ich fündig und lasse mir in einem MSDN TV Video von einem freundlichen Microsoft-Mitarbeiter erklären, was WinFX und Avalon eigentlich sein soll. (siehe hier). Soweit so gut, WinFX wird also in Zukunft die etwas angestaubte WinAPI ersetzen. Super! Aber ich habe da ein bisschen zu oft ".NET" gehört... Egal, denn irgendwo auf Microsoft.com gibts auch noch einen Download der uner anderem das vorläufige WinFX SDK enthält. Mit ca. 255 MB ein ganz schöner Brocken.
Jedenfalls, wenn man sich das anschaut, kriegt man den Eindruck, in Zukunft muss man mit .NET Sprachen oder Managed C++ programmieren. Schlimm. Weiß noch jemand näheres zu dem Thema?
-
Warum sollte man das müssen?
Bedenke: wer schreibt denn heute seine Anwendungen wirklich mit der Winapi? Fast keiner.Genauso wird es bleiben - du kannst immer eine Abstraktionsebene einfügen. Wenn du zB mit C++ und wxWidgets deine Anwendung schreibst, dann muss sich daran nichts ändern. wxWidgets wird intern vielleicht die .NET Funktionen aufrufen, vielleicht auch direkt das was darunter liegt. Für dich ändert sich aber nichts.
-
Bitte nicht schon wieder die Frage ob C++ bei MS noch Zukunft hat!
Bald mache ich freiwillig wöchentlich einen Thread auf, in dem ich diese Frage stellvertretend für andere stelle. 
Deshalb hier ein paar Ausschnitte aus der FAQ von MS (also hoch offiziell!):
How can I start taking advantage of .NET features without rewriting my application?
C++ has a complete roadmap for taking advantage of .NET Framework for C++ applications:* Compiling existing C++ code into MSIL – this allows you to take make use of any .NET classes such as .NET remoting, XML classes, etc. from your existing C++ application.
* Wrapping C++ native classes with managed wrappers which can be used by other .NET languages like C#/VB.
* Writing new .NET components that make use of existing C/C++ APIs as implementation.
* Writing new verifiable .NET components in C++ as in any other .NET languages.C++ images can be pure native code, pure MSIL or mixed-mode containing both native and MSIL, allowing incremental migration to .NET
Ist C++ wirklich noch bei MS hoch im Kurs? Das wird hier beantwortet:
If I want to take advantage of .NET, why should I use C++?
Visual C++ allows you to take full advantage of .NET while at the same time giving you the most efficient and easiest way to interoperate with existing code. It also allows you to leverage your knowledge of C++ to .NET, rather than having to learn a new language.What you get is the combination of a language you know and love, a great managed-unmanaged interop story, complete .NET support, and .NET features found ONLY with Visual C++ (such as IJW, OpenMP, and templates).
Und ja, selbst die MFC wird weiter entwickelt:
What is the future of MFC?
In Whidbey and beyond MFC remains a core feature of the professional Visual C++ toolkit. While MFC is not always the best or most modern library for writing new applications, it continues to offer features that are not available elsewhere.
Microsoft will continue to maintain and extend MFC to make it more secure and robust, and to enable it to interoperate better with newer technologies and libraries. For example, new classes and features in Whidbey enable existing MFC applications to be extended and augmented with capabilities built on the Microsoft .NET Framework.Will Microsoft continue to support and add features to MFC?
Microsoft has no plans to discontinue support for MFC. New features will in most cases enable MFC applications to better interoperate with the .NET Framework.Quelle: http://msdn.microsoft.com/visualc/productinfo/faq/default.aspx
Es gibt sogar von MS Tutorials in denen beschrieben wird, wie man ohne C++/CLI auf .NET zugreifen kann. In C++ ist nunmal ALLES möglich, wie auch in der FAQ geschrieben. Kein Grund in Panik zu geraten. Denn letztendlich ist die Basis immer Maschinencode... irgendwo da unten, verstehen CPUs nunmal kein .NET.
-
Shade Of Mine schrieb:
Warum sollte man das müssen?
Bedenke: wer schreibt denn heute seine Anwendungen wirklich mit der Winapi? Fast keiner.So gut wie alle Windows-Anwendungen benutzen den Windows API, direkt oder indirekt (z.B. ueber MFC, das ja nur ein duenner Layer ueber dem Windows API ist).
Werden die WinAPI-Aufrufe in Zukunft nicht als Aufrufe nach WinFX implementiert?
Microsoft will sicher, dass aeltere Anwendungen immer noch auf Longhorn laufen.
Anwendungen werden immer noch mit Windows API und MFC entwickelt, obwohl Microsoft schon seit geraumer Zeit .NET als Universalloesung propagiert.
Der Windows API ist die einfachste Art, Windows-Anwendungen zu schreiben. Es wird noch eine Weile brauchen, bis Microsoft allen Entwicklern die Alternativen schmackhaft gemacht hat.
-
Die Win32API wird natürlich nicht plötzlich verschwinden oder als langsamer Wrapper für WinFX implementiert werden, sondern beide Subsysteme werden parallel unterstützt werden. Der einzige Unterschied ist, dass WinFX als von der Win32API unabhängiges Subsystem implementiert wird. das Net-Framework basiert ja derzeit auf der Win32API.
Ich sehe in WinFX hauptsächlich nur Vorteile. Es wird einfacher, auf das Betriebssystem zugeschnittene Software zu entwickeln und muss sich nicht mit den klobigen Win32API-Funktionen rumschlagen sondern kommt in den Genuss, dies in einer objektorientieren Umgebung machen zu können. Außerdem gehören typische verheerende Programmierfehler wie Buffer-Overflows der Vergangenheit an.(Bezogen auf die .NET-Sprachen, managed C++ kann natürlich immer noch overflowen ;))Alles in allem denke ich, dass mit den geplanten Änderungen jeder glücklich werden kann. Unternehmen können von der geringeren Entwicklungszeit für .NET-Anwendungen profitieren, andere, die sich nicht mit C# oder anderen Sprachen anfreunden wollen, können in managed C++ schreiben und der Rest macht einfach so weiter wie jetzt
EDIT:
Der Windows API ist die einfachste Art, Windows-Anwendungen zu schreiben.
Wie meinst du das?
-
Ich verstehe die Aufregung auch nicht. Es wird weiterhin C und C++ geben müssen und zwar unmanaged! Wie sollte man sonst Gerätetreiber schreiben?
Ich sehe in .NET und WinFX nur Vorteile. Die meisten Softwarehersteller oder Arbeitgeber werden sicherlich auf C# umschwenken, aber das beudeutet nicht das C++ verschwindet! Der Markt forderte nun mal eine Sprache die einfacher ist als C++. Bestes Beispiel ist Java. Es gibt einfach zu wenig gute C++ Programmierer, die auch noch schnell programmieren.
Weiß eigentlich einer für was MS managed .NET einsetzt? Ich habe mal gehört, dass das neue Windows um .NET entwicklet worden sein. Ist da was dran?
-
Avalon wird in C# geschrieben.
-
Optimizer schrieb:
Avalon wird in C# geschrieben.
..oder managed C++
-
+++ schrieb:
Der Markt forderte nun mal eine Sprache die einfacher ist als C++. Bestes Beispiel ist Java. Es gibt einfach zu wenig gute C++ Programmierer, die auch noch schnell programmieren.
Bitte, C++ ist doch keine wirklich schwere Programmiersprache, klar, die Programmierung von GUIs ist schwerer damit. Und ja, Win Longhorn IST um .NET entwickelt, man schaue sich nur die Avalon / WinFX Beispiel Codes an. Ich war eben der Meinung, dass die kommenden Windows-Generationen C/C++ - ohne managed extensions - etwas verdrängen, besonders wenn es um grafische Anwendungen geht.
Der größte Vorteil von C/C++ ist eben die schnellere Ausführungsgeschwindigkeit.
-
+++ schrieb:
Ich verstehe die Aufregung auch nicht. Es wird weiterhin C und C++ geben müssen und zwar unmanaged! Wie sollte man sonst Gerätetreiber schreiben?
...indem für alle erdenklichen typen von hardware und deren anforderungen schon vorgefertigte software existiert, die man nur nach bedarf konfigurieren und zusammenstückeln muss. im grunde gibts sowas schon solche frameworks in windoof (wdm, ndis, der kernel ist sowieso objektorientiert). ms muss das nur auf die spitze treiben und schon müssen alle treiber mit .NET programmiert werden.
-
BloodLord schrieb:
+++ schrieb:
Der Markt forderte nun mal eine Sprache die einfacher ist als C++. Bestes Beispiel ist Java. Es gibt einfach zu wenig gute C++ Programmierer, die auch noch schnell programmieren.
Bitte, C++ ist doch keine wirklich schwere Programmiersprache, klar, die Programmierung von GUIs ist schwerer damit. Und ja, Win Longhorn IST um .NET entwickelt, man schaue sich nur die Avalon / WinFX Beispiel Codes an. Ich war eben der Meinung, dass die kommenden Windows-Generationen C/C++ - ohne managed extensions - etwas verdrängen, besonders wenn es um grafische Anwendungen geht.
C++ ist schwerer als C#. Das ist numal Fakt. Eins der Ziele von C# war eben, einfacher zu sein als C++. Der Markt fordert Sprachen mit denen man schnell Anwendungen entwicklen kann.
BloodLord schrieb:
Der größte Vorteil von C/C++ ist eben die schnellere Ausführungsgeschwindigkeit.
Der Satz wär richtig, wenn Du "ist" durch "war" ersetzt. Geschwindigkeit spielt bei den heutigen Rechnern und standardmäßigen Anwendungen keine Rolle mehr. Warum ist Java so erfolgreich?
Und jetzt bitte bei standardmäßigen Anwendungen bleiben. Also weder Echtzeitsysteme noch Spiele.