Ich möchte die WinAPI Programmierung lernen



  • Das verlinkte Buch ist natürlich _der_ Klassiker, auch heutzutage ist es allemal lesenswert.
    Aber wenn erst einmal die Grundlagen verstanden sind, hilft auch eine Suche in den hier ständig verlinkten MSDN-Seiten bei der Problemlösung.

    WinAPI lernen will schrieb:

    Macht es Sinn vorher Qt, GTK+, MFC und .Net zu lernen?

    Ich würde sagen, eher kann es umgekehrt Sinn machen, also erst WinAPI und danach das Framework deiner Wahl.
    Aber du musst es selbst wissen: Qt, wxWidgets und Konsorten kapseln dir so ziemlich alles - wenn du damit leben kannst, nicht zu wissen, wie die Funktionen intern arbeiten, kannst du auch direkt mit diesen Frameworks beginnen.

    Aber mal am Rande:
    Qt ist ein ziemlicher Brocken, setzt (wahrscheinlich aus historischen Gründen) eigene Datentypen (eigener String, eigene Container, eigene Streams) und nicht die der STL ein, inwieweit die Codingrichtlinien von wxWidgets noch gelten, weiß ich nicht und bei MFC hast du das Problem, dass die kostenlosen Expressversionen von VS sie nicht unterstützen.

    Wenn du ohnehin nur für Windows entwickeln möchtest, dann vielleicht doch ein wenig WinAPI und Unterstützung durch andere Bibliotheken, wie Boost und SFML.



  • yahendrik schrieb:

    Wenn du ohnehin nur für Windows entwickeln möchtest,

    Win32++ ist auch sehr gut.
    http://win32-framework.sourceforge.net/



  • Vielen Danke für eure Antworten.
    Ich denke ich werde mir das Buch kaufen und die WinAPI lernen.

    Allerdings habe ich langfristig für richtige Anwendungen auch andere Plattformen wie Mac OS X und Linux als Ziel, weswegen ich für diese dann eine der crossplattformfähigen APIs nutzen würde.

    Die WinAPI kann allerdings trotzdem sinnvoll sein, z.B. wenn ich nur ein Fenster zum reinzeichnen brauch und für jede Plattform eine eigene kleine Bibliothek schreibe, die mir so etwas dann plattformunabhängig abstrahiert.



  • Dann nimm doch lieber Qt...



  • Jochen Kalmbach schrieb:

    Dann nimm doch lieber Qt...

    Meinst du damit jetzt:
    Qt als Auswahl von den vielen crossplattformfähigen APIs?
    Oder einfach prinzipiell im Sinne von, WinAPI lohnt sich nicht, wenn man später Qt nimmt?

    Falls du ersteres gemeint hast, so hätte die Qt API leider ein kleines Problem.
    Wenn ich ein propritäres Programm schreiben wollen würde, dann müßte ich das vorher wissen, bevor ich die Qt API dafür nutze. Das steht in den Lizenzbedingungen.
    Propritäre Qt Anwendungen müssen schon von Beginn an mit einer kommerziellen Qt Lizenz entwickelt werden.

    Das bedeutet also, falls mein Projekt schief läuft, dann hätte ich die Lizenzkosten von Qt umsonst in den Sand gesetzt.



  • Noch etwas.

    Wie wäre VCF (Visual Component Framework) im Vergleich zu Qt?
    http://vcf-online.org/



  • WinAPI lernen will schrieb:

    Falls du ersteres gemeint hast, so hätte die Qt API leider ein kleines Problem.
    Wenn ich ein propritäres Programm schreiben wollen würde, dann müßte ich das vorher wissen, bevor ich die Qt API dafür nutze. Das steht in den Lizenzbedingungen.
    Propritäre Qt Anwendungen müssen schon von Beginn an mit einer kommerziellen Qt Lizenz entwickelt werden.

    Das bedeutet also, falls mein Projekt schief läuft, dann hätte ich die Lizenzkosten von Qt umsonst in den Sand gesetzt.

    Dann hast Du noch einen alten Stand der Lizenz-Politik im Kopf!
    So wie ich das verstanden habe ist QT jetzt LGPL und somit für jeden Fall lizenzfrei...

    Siehe:
    http://qt.nokia.com/products/licensing/
    http://qt.nokia.com/about/news/lgpl-license-option-added-to-qt/



  • So wie ich das verstanden habe ist QT jetzt LGPL und somit für jeden Fall lizenzfrei...

    Da wuerd ich meine Hand nich ins Feuer legen für 🙂
    Wie gesagt, dynamisch linken + windows ist nicht 100% zweifelsfrei.

    WinAPI:
    - Es ist sicher nicht verkehrt wenn man es kann
    - Für grafik-Programmierung bringt es aber recht wenig, wenn man sowieso andere Frameworks verwendet
    - Meist kommt man in anderen Frameworks nie soweit runter, das man selber auf DeviceContext's schreiben darf/muss
    - Gut an der WINAPI ist aber, das man das Eventsystem und die Nachrichten-schleifen lernt, auf aehnliches baut jedes Framework auf.
    - Intressanter wird die WINAPI in zusammenhang mit anderen Frameworks, eher auf Logikebene. FileOperationen z.b. uber die WInapi und mit Nutzen windows spezifischer Funktionalitaeten laesst einen viel Performanter Dinge durchfuehren als z.b. mit dem Stream-Konzept von C++ + STL. Auf kosten der Plattformunabhaengigkeit natuerlich.
    - Mit der WINAPI kannst natuerlich viel mehr spezielle Features deines BS nutzen, sofern das das Ziel ist 🙂
    - Aber Fenster Programmieren rein in c + WInapi ist in heutiger Zeit eher Selbstgeiselung. Igrendwann muessen projekte auch mal fertig werden ...

    Ciao ..



  • RHBaum schrieb:

    So wie ich das verstanden habe ist QT jetzt LGPL und somit für jeden Fall lizenzfrei...

    Da wuerd ich meine Hand nich ins Feuer legen für 🙂
    Wie gesagt, dynamisch linken + windows ist nicht 100% zweifelsfrei.

    Keine Ahnung wie das mit Qt nun genau ist, für die Seite mit dem Bedingungen müßte man wohl sowieso erstmal einen Rechtsanwalt um Rat fragen.

    WinAPI:
    - Es ist sicher nicht verkehrt wenn man es kann
    - Für grafik-Programmierung bringt es aber recht wenig, wenn man sowieso andere Frameworks verwendet
    - Meist kommt man in anderen Frameworks nie soweit runter, das man selber auf DeviceContext's schreiben darf/muss
    - Gut an der WINAPI ist aber, das man das Eventsystem und die Nachrichten-schleifen lernt, auf aehnliches baut jedes Framework auf.
    - Intressanter wird die WINAPI in zusammenhang mit anderen Frameworks, eher auf Logikebene. FileOperationen z.b. uber die WInapi und mit Nutzen windows spezifischer Funktionalitaeten laesst einen viel Performanter Dinge durchfuehren als z.b. mit dem Stream-Konzept von C++ + STL. Auf kosten der Plattformunabhaengigkeit natuerlich.
    - Mit der WINAPI kannst natuerlich viel mehr spezielle Features deines BS nutzen, sofern das das Ziel ist 🙂

    Danke für die Antwort.

    - Aber Fenster Programmieren rein in c + WInapi ist in heutiger Zeit eher Selbstgeiselung. Igrendwann muessen projekte auch mal fertig werden ...
    Ciao ..

    Allerdings haben Programm die die WinAPI nutzen etwas sehr tolles an sich.
    Sie sind sehr schlank und klein und müssen nicht erst eine .NET VM laden.

    Nichts finde ich furchbarer als Programme zum Steuern der Hardwaretreiber die dann in .Net geschrieben sind und dann dazu führen, daß Windows eine Ewigkeit beim Booten braucht.
    Und wenn man dann 3-4 von diesen Programmen hat und jedes startet eine andere Version von .Net. Erst .Net 1.0, dann .Net 2.0 usw. dann ist die Platte nach dem Booten nur noch am Arbeiten, ehe man endlich mit dem Arbeiten loslegen kann.

    Leider gibt es solche Programme leider immer häufiger. Es wäre schön, wenn die Firmen zumindest solche Programme wieder mithilfe der WinAPI realisieren würden.
    Aber das ist wohl Wunschdenken.

    Neulich habe ich mal einen Torrent Client für Windows gesucht, weil ich das neue Ubuntu ausprobieren wollte und das erschreckende war, daß die meisten Torrent Clients 70 MB auf der Platte verbraucht haben, bis ich dann uTorrent fand, der brauchte nur ca. 1 MB dank WinAPI.
    Außerdem ist die Startzeite von WinAPI Programmen deswegen ebenfalls viel schneller.



  • RHBaum schrieb:

    - Aber Fenster Programmieren rein in c + WInapi ist in heutiger Zeit eher Selbstgeiselung. Igrendwann muessen projekte auch mal fertig werden ...

    👍 Für aufwendige GUI's; aber für ein kleines Fenster mit ein paar Buttons etc. langt die WinAPI allemal.



  • Für aufwendige GUI's; aber für ein kleines Fenster mit ein paar Buttons etc. langt die WinAPI allemal.

    ja scho ...
    Aber ich z.b. hab immer ne statisch linkbare Qt Version an der Hand.
    Da werden Buttons und Fenster zum 2 Zeiler 🙂
    Klar, auf kosten der Programmgroese ! und der Ladezeit 🙂
    Statt 10kb ist mein Prog 2-3Mb gross (wie gross ist eure Blockgroesse aufn Filesystem ? ), und die Ladezeit steigt von 0,02 auf 0,05s

    Sie sind sehr schlank und klein und müssen nicht erst eine .NET VM laden.

    Wenn Du C++ programmieren willst, dann lass soweiso die Finger von .Net. .Net entwikclung hat IMHO mehr mit scripten zu tun, als wie mit programmieren.
    Wenn du .Net programmieren wölltest, wär C++ nicht die richtige Sprache. Da gibt es schoenere Sprachen, und alle Vorteile von C++ verpuffen irgendwo in der runtime 🙂
    Script und .Net Programme haben auch schon ihre daseinsberechtigung. Und wenn man sauber modular trennt, kann man die GUI, wo es sowieso nich auf Speed ankommt, schon mit sowas machen. Nur ist dann c++ irgendwie fehl am Platz.

    für die Seite mit dem Bedingungen müßte man wohl sowieso erstmal einen Rechtsanwalt um Rat fragen.

    Der kann auch ned Helfen, weil sich noch niemand richtig rechtlich damit beschaeftigt hat. Es gibt kein Vergleichsurteil und nix, dafuer viele offene Punkte, die man technisch mal so und mal so interpretieren kann. WIe das Gericht die interpretiert ist unvorhersehbar.
    Auf Alle faelle werden mit der Windows-Distribution der Qt einige Ziele/Konzepte der LGPL verletzt, das hat aber technische Ursachen(ein windows programm, was gegen die statisch-dynamischen Importlibs linkt, da kann man die qt nicht ohne weiteres austauschen, binaerkompatible Dlls zur qt entwickeln iss nahezu unmöglich).

    Nen Guter Anwalt bei nem Projekt wo es auf die Existenz ankommt, wird dir immer zur komerziellen version raten ...

    Ciao ...


Anmelden zum Antworten