Die Grundlagen der WinAPI lernen?



  • stable schrieb:

    Die komplette WinAPI wird laut MS irgendwann 🙄 durch .Net ersetzt.

    Wo steht das?



  • stable schrieb:

    Die komplette WinAPI wird laut MS irgendwann 🙄 durch .Net ersetzt.

    Quelle?



  • Ist doch schon ein alter Hut... 😉
    z.B.
    http://de.wikipedia.org/wiki/.NET_Framework_3.0

    oder solche Meldungen

    WinAPI-32-Ersatz Langfristig beabsichtigt Microsoft, das Win32-API durch die Klassen des .NET Frameworks zu ersetzen. Damit verwischen auch die charakteristischen Merkmale der verschiedenen Sprachen. Ob eine Anwendung mit Visual Basic .NET programmiert wird oder mit C# oder C++ – es spielt keine Rolle mehr. Alle Sprachen greifen auf die gleiche Bibliothek zurück, sprachspezifische, operative Bibliotheken gibt es nicht mehr. Die Konsequenz ist, dass die Wahl für eine bestimmte Sprache nicht mehr der Entscheidung gleichzusetzen ist, wie effizient eine Anwendung geschrieben werden kann oder was sie zu leisten imstande ist.



  • Das sind keine offiziellen Quellen. In Wikipedia kann jeder anonyme Hans Wurst einen Beitrag schreiben.

    Also: quellen bitte.

    Oder soll ich mal mehrere offizielle Quellen posten, wo selbst die VC++-Productmanager sagen, das das die MFC und Win-API nochmal so richtig aufdreht?



  • stable schrieb:

    Die komplette WinAPI wird laut MS irgendwann 🙄 durch .Net ersetzt.

    Totaler Blödsinn!
    Die WinAPI wird weiterhin die Grundlage des Windows-Betriebssystems bleiben!

    Mit Vista wurde versucht schon teile des OS mit "managed Code" zu schreiben, dieses Vorhaben ist aber gescheitert und *alles* im Betriebssystem ist "unmanaged"!

    Nur bestimmte "Aufsätze" auf das OS sind managed!



  • Wer die Win-API oder MFC nicht mag, soll doch einfach mit .NET programmieren. Es bedarf doch nicht erst einer vorsätzlichen Lüge um z.B. die Win-API nicht mehr nutzen zu wollen. Es ist doch völlig legitim, wenn jemand lieber mit C# programmieren will. Wer trotzdem C++ machen will, kann sich ja ein anderes Framework nehmen (Qt oder sowas). Aber deshalb Falschmeldungen verbreiten?

    Das zeigt auch wieder, das man nicht alles glauben soll, was in wikipedia steht. Vorallem steht in Wikipedia, das man immer eine Quelle angeben soll. Zu der Aussage "Das Win32-API soll durch .NET Framework nach und nach abgelöst werden" gibt es aber keine Quellenangabe.



  • Ich weis garnicht was ihr gegen WinAPi habt. Ich find die Klasse und Arbeite sehr viel damit. Auch größere Projekte erstell ich mittels WinApi. In VS (andere kenn ich nicht) hast du ja auch einen schicken Resourceneditor und kannst dir deine Dialoge zusammenklicken, du musst ja nicht alles per Hand machen.
    Und ich weis nicht vielleicht liegt das daran das ich erst mit WinApi angefangen habe aber ich finde die MFC, naja wie soll ich sagen 😮
    Als ich das erste mal reingeschaut habe kamm ich garnicht klar weil man nicht erkennt wann was passiert, Total unübersichtlich. Das war bei WinApi (und da war ich noch jünger und unerfahrener) anders. Da weis man wenigstens wo man ist und wann man was macht :p (jaja ich weis wenn ich MFC könnte, könnte ich das auch sehen 🙄 )

    Naja und einen Anfänger von der WinApi gleich von vornerein abzuraten find ich Falsch. Guck sie dir mal an. Besonders es ist scheis egal ob du VB, C++, Delphi oder so programmierst, auf die WinApi kannst du immer zugreifen.

    MfG schirrmie



  • Einem Anfänger würde ich die Win-API trotzdem nicht empfehlen. Was aber nicht heißt, das die WIn-API ausstirbt. Keiner kann mir erzählen, das er _komplexe_ Systeme ausschliesslich im C-Style (halt Win-API) komfortabler als mit einem OO-Framework entwickeln kann. Zumindest nicht so komfortabel, als wenn ich ein modernes und sauberes OO-Framework (meinetwegen .NET) nehme (egal welche Sprache).

    Schön das ich weiß wie die Win-API funktioniert. Aber bringt mich das weiter als jemand der kein Win32 kann? Wer C programmiert, soll oder kann nur Win32-API nehmen, richtig. Wenn ich aber C++ programmiere, sehe ich keinen Grund, mir nen Ast mit der C-API von Windows abzubrechen. Auf Win32-API greife ich zurück, wenn mir das verwendete OO-Framework ein bestimmtes Problem nicht lösen kann. Sagen wir mal, ich will auf einen TWAIN-Interface zugreifen. Wenn mir das OO-Framework da nichts anbietet, muß ich gezwungenermaßen auf Win32-API zugreifen. Aber wenn das OO-Framework mir das was anbietet, mach ich nen Bogen um die Win32-API. Und die meisten Programmieranfänger, wollen erstmal ein paar Fenster mit Buttons erstellen. Völlig unwichtig wie die Windows-Messages für Makros haben.

    Aber das ist eh eine Grundsatzdiskussion, die hier regelmäßig auftaucht.



  • Also kann ich das alles so zusammenfassen, dass die WinAPI noch immer nützlich ist, es aber für C++ Programmierer nicht notwendig ist, sie als Grundlage für die GUI-Programmierung zu lernen, weil es viele andere gute APIs, wie Qt, wxWidget etc. gibt.
    Ich habe mich bis jetzt so weit entschlossen, mich einige Zeit weiterhin mit dem Buch zu beschäftigen. Da ich irgendwann einmal danach auf eine andere API, wie Qt umsteigen will, muss ich mich natürlich erst einmal mit der Objektorientierung, also C++ oder C# beschäftigen. Denn eine andere Wahl außer der WinAPI bleibt mir ja als C Programmierer sowieso nicht übrig!
    Ist das überhaupt sinnvoll von C auf C++ umzusteigen oder ist es unpassend, weil man dadurch automatisch schlechten Code schreibt, also typische C-Programmierung anwendet, die bei der C++ Programmierung einfach nicht üblich ist?

    MfG
    gollo



  • Es gibt so viele OO-Libraries und OO-Frameworks, die die Win32-API kapseln... bzw. einen Teil davon (kommt auch darauf an, was man unter Win32-API alles versteht). Es gibt mit MFC, wxWidgets, VCF und wenn man will, noch VACA schon Win32-API-Wrapper für C++ler. Wenn du Qt nimmst, hast du keinen direkten Win32-Wrapper, weil Qt vieles selbst macht, und auch dann entsprechend auf vieles Win32-API verzichtet. Was aber nicht schlecht sein muß!!! Ist halt alles eine Frage des Konzeptes.

    Und ja, ich würde jemand von C abraten, wenn er eigentlich C++ lernen will. C finde ich nur in ganz bestimmten Gebieten nötig. Aber selbst da, wo mal C unverzichtbar war, wird es langsam von C++ verdrängt (z.B. bei BMW in der Motorsteuerungs-Software), da auch die Embedded-Hardware immer leistungsfähiger wird. Aber ist ein anderes Thema. Wer sich an C gewöhnt hat, wird in C++ Gefahr laufen, seine alten Gewohnheiten nicht ablegen zu können. Gerade weil C++ zum großen Teil zu C kompatibel ist. Aber diese Kompatibilität ist ja nur da, um einfacher C-Programme migrieren zu können und nicht um weiter im C-Stil zu programmieren (dann kann man gleich bei C bleiben).

    Wenn Du GUI-basierte Anwendungen machen willst, bist du erst Recht bei C++ besser aufgehoben als bei C. Gerade OO ist für GUI-Entwicklung prädestiniert. Und sowas wie Qt oder gtkmm zeigen was mit C++ einfacher möglich ist. Da aber C++ vom Sprachumfang her komplexer (umfangreicher!) ist als C, würde ich die Zeit, die man sonst für C-Lernen benötigt, lieber in C++ stecken. Ist ne einfache Kosten-Nutzen-Rechnung.



  • Artchi schrieb:

    Oder soll ich mal mehrere offizielle Quellen posten, wo selbst die VC++-Productmanager sagen, das das die MFC und Win-API nochmal so richtig aufdreht?

    Ja, bitte.



  • *push*



  • Nachschaubar z.B. hier:
    Steve Teixeira and Bill Dunlap: Visual C++ Today and Tomorrow
    http://channel9.msdn.com/Showpost.aspx?postid=281987

    Und wer Zeit hat kann sich schon mal davon überzeugen, dass dies auch so ist:
    Siehe: March Orcas CTP (hier wurde schon sehr viel in der MFC bzgl. Vista/XP gemacht)
    http://msdn2.microsoft.com/en-us/vstudio/aa700831.aspx

    Da ist z.B. das folgende schon drin:
    Siehe: Vista-style File Dialogs with MFC
    http://blogs.msdn.com/vcblog/archive/2006/12/14/vista-style-file-dialogs-with-mfc.aspx

    Es ist aber wohl nicht zu viel verraten, dass die VC++ Community nicht sehr begeistert ist wie es aktuell bei MS *nur* noch in Richtung C# (anscheindend) geht. Es wäre schön, wenn nicht *nur* die VC++-Produkt-Gruppe versuchen würde gegen Windmühlen zu kämpfen sondern dies auch noch von weiter oben gesagt würde, das VC++ Zukunft hat...

    Diese Diskussion findet gerade auch heftig zwischen den VC++ MVPs und der MS Produkt-Gruppe statt... ab Montag findet in Seatlle das "MVP Global Summit" statt, wo auch einige VC++ MVPs dabei sein werden und dort ihr "Anliegen" auch nochmals zum Ausdruck bringen werden... ich wäre eigentlich auch gerne dabei gewesen, konnte aber jetzt aus gesundheitlichen Gründen nicht rüberfliegen...



  • Ja, aber die Leute die was bei MSVC was zu sagen haben, haben auch gesagt, das die Richtung falsch bzw. das sie C++ falsch eingeschätzt haben. Vorallem die Kunden wollen weiter C++. Entsprechend wird C++ wieder mehr Aufmerksamkeit bekommen:
    http://channel9.msdn.com/showpost.aspx?postid=281987
    Bitte alle 30 Min. anschauen!!!

    Das schreibt MS in einem offiziellen MSDN-Beitrag zur C/C++ Roadmap vom Oktober 2004:

    In the years since the .NET Framework, the CLR, and C# were announced, many developers have wondered about Microsoft's plans for C++. Some have speculated that C# is a replacement for C++, but it most certainly is not. C# is a language that is easier to learn than C++, and provides access to the functionality of the CLR. For those who already know C++, there's no need to learn anything to gain access to the functionality of the CLR, and C++ has features that are not in C#, so moving would actually involve giving up some power.

    Quelle: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnvs05/html/movNETWFX.asp

    Das schreibt MS in einem offiziellen MSDN-Beitrag zur MFC Roadmap vom Juni 2005:

    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.

    Quelle:
    http://msdn.microsoft.com/visualc/whidbey/mfc2005/default.aspx


Anmelden zum Antworten