Ich möchte die WinAPI Programmierung lernen

Belli

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.

Jochen Kalmbach

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/

Jochen Kalmbach

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/

RHBaum

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.

cooky451

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.

RHBaum

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 ...