Wie sieht die Zukunft der WinAPI aus?

Guten Tag,

ich würde gerne von ein paar Profis wissen wie diese die Zukunft der WinAPI in der derzeitigen Form, also in C geschrieben mit C-Interface oder per MFC gewrappt und mit C++, einschätzen.

Ich habe bei Wikipedia gelesen dass alles langsam auf Managed-Code umgemünzt wird und so Schritt für Schritt der Weg hin zu C# als produktiveste Sprache zum Entwickeln von Windowsanwendungen geebnet wird. Auch hier in den FAQ zu den anderen GUI-Framework steht was davon dass die WinAPI in C zugunster .NET weichen wird.

Was würdet ihre Jemanden raten der sich mit der Entwicklung von Windowsanwendungen in der Zukunft beschäftigen will?

- C und WinAPi
- C++ und MFC
- C# und .NET

Vielen Dank für eure Zeit.

Jochen Kalmbach

Mal ganz zu Anfang: Die WinAPI ist *die* Schnittstelle zum OS, es gibt keine andere. (Punkt)

Wenn Du aber Windows-Anwendungen schreiben willst, dann ist es (i.d.R.) am einfachsten mit C#.

Danke für die Antwort, dann ist also der Artikel auf Wikipedia falsch?

ich zitiere

Die .NET Framework API (früher WinFX genannt) ist eine neue, objektorientierte API, die die native Windows API erweitert und umschließt. Mit der Version 3.0 wurde das Framework weitestgehend von der nativen WinAPI abgekoppelt, so dass ein großer Teil des Frameworks mittlerweile vollständig aus verwaltetem Code besteht und nicht mehr nur ein einfacher Wrapper der nativen WinAPI ist. Die API wurde unter anderem entworfen, um zukünftigen Anwendungen einen einfachen, verwalteten Zugriff auf die zahlreichen neuen Features in Windows Vista zu geben. .NET-Anwendungen laufen als so genannter Managed Code (verwalteter Code) unter einer Laufzeitumgebung namens Common Language Runtime (CLR), einer virtuellen Machine, die im Sinne der Abstraktion keine direkten Maschinenbefehle ausführt, sondern stattdessen das aus Bytecode bestehende Programm in Maschinencode umwandelt, bevor dieses dann vom Prozessor ausgeführt werden kann. Der GUI-API-Satz für WinFX, der unter dem Codenamen Avalon läuft, wird Windows Presentation Foundation genannt und löst die alte GDI- und GDI+-API ab. Sie setzt direkt auf DirectX auf und benötigt leistungsfähige Grafikkarten, um alle Effekte angemessen darstellen zu können.

Jochen Kalmbach

Naja... es ist relativ... z.B: der XML-Parser wurde vermutlich in Managed-Code geschrieben und verwendet vermutlich nicht mehr den MSXML (aber ich weiss es nicht). Somit ist der Artikel nicht ganz falsch; aber er ist auch nicht ganz richtig, denn zumindest die Dateioperationen sind WinAPI und somit native... naja.. Wikipedia ist auch nicht alles...

Martin Richter

Man muss sich doch mal nur ansehen, welche API Funktionen durch die .NET Runtime benutzt werden...

Selbst die neuen Schnitstellen in Windows 7 und Vista sind alle in traditionellen Schnittstellen veröffentlicht. Entweder klassische DLL Exports oder COM! Es gibt nicht eine Funktion des OS, die nur über .NET verfügbar wäre.
Oder zumindest isr mir nicht eine bekannt.

Tyrdal

Wär ja auch arg aufwendig den Kernel managed zu machen.

Ich sage mal die Entwicklung mit C gehört immer noch zur Grundlage hinzu und damit kann man auch anfangen zu lernen.
Natürlich wird meistens je nach Projekt und Aufgabe auf andere (höhere) Sprachen zurückgegriffen. Meine Erfahrungen sind aber, dass auch die großen IT Unternehmen noch auf C (+ WinAPI) setzen.

mfg robotx

vlad_tepesch

naja, wenn man einfach nur Windowsanwenungen schreiben will, würd ich c# nehmen.

vorteile:
-junge (recht) gut konzeptonierte sprache
-umfangreiches Framework
-einfaches erstellen von guis
-kein MFC (das ist ein riesen Vorteil)

- wegen mono eventuell ein bisschen plattformunabhängig

schmuessla

-kein MFC (das ist ein riesen Vorteil)

Wieso ist das ein "Vorteil"?

schmuessla schrieb:

-kein MFC (das ist ein riesen Vorteil)

Wieso ist das ein "Vorteil"?

weil irgendwer mal gesagt hat, mFC ist schlecht. und alle glauben das.

vlad_tepesch

du nicht?

jedes mal, wenn ich mit MFC arbeiten mußte, hab ich fast ne Kriese gekriegt.

_matze

vlad_tepesch schrieb:

du nicht?

jedes mal, wenn ich mit MFC arbeiten mußte, hab ich fast ne Kriese gekriegt.

Vielleicht hat die MFC ja auch ne Krise gekriegt, weil sie mit dir arbeiten musste.

Also ich kann gut damit arbeiten, gar kein Problem. Mir fehlt zwar zugegebenermaßen der Vergleich mit anderen Frameworks, aber ich finde, dass man nach kurzer Eingewöhnung eigentlich gut zurecht kommt.

vlad_tepesch

_matze schrieb:

vlad_tepesch schrieb:

du nicht?

jedes mal, wenn ich mit MFC arbeiten mußte, hab ich fast ne Kriese gekriegt.

Vielleicht hat die MFC ja auch ne Krise gekriegt, weil sie mit dir arbeiten musste.

mag sein, dass das auf gegenseitigkeit beruhte

Ich schreib selten richtige anwendungen mit gui.
Meist sinds Konsolenanwendungen, oder es reicht ein fenster, was ich komplett selbst bemale und dann aber per tasten steuer.
wenns ne richtige app wird mit gui, dann nutz ich meist eine total veraltete delphi-version (kleine executable, einfach zu coden), wenns was ganz kleines ist, oder c# (hat halt den nachteile, dass es ein installiertes framework braucht

vlad_tepesch schrieb:

jedes mal, wenn ich mit MFC arbeiten mußte, hab ich fast ne Kriese gekriegt.

ich nicht, finde MFC ganz gut für kleine, dialogbasierte progrämmchen. mit diesen wizards hat man einen leichten einstieg, wenn man mal eben schnell ein kleines windows-programm machen will. mfc finde ich ganz praktisch und auch nicht zu kompliziert (obwohl im hintergrund c++ lauert).

berniebutt

MFC und co. sind nicht schlecht, wenn man das mag.
Ich mag es nicht und möchte bei C, C++ und WinApi bleiben. Damit komme ich bestens klar und habe jederzeit alles ohne fremde Bibliotheken fest im Griff.