# MFC oder WinAPI oder .NET



## Sebastian Thalhammer (18. Januar 2004)

Hi.

Mir geht die Frage durch den Kopf, welcher dieser Teile die Zukunft gehört. 
Zahlt es sich überhaupt noch aus reines WinAPI zu programmieren oder soll man gleich mit MFC anfangen. Wie steht es aber mit den .NET Sprachen.

P.S.: Kann man MFC eigentlich mit Win API kombinieren?


----------



## chibisuke (18. Januar 2004)

Also .NET is neu, alles will .NET haben, und in ein paar jahren wird man drauf kommen wie blöd man eigendlich is wenn man .NET programmiert.

round(Portabilität) = NULL

Also unter linux is nix mit .NET, und ich sag dir das linux in ein´paar jahren 30 - 50% marktanteil haben wird.

MFC is das gleiche...

Das einzige wo du ner chance hast, zumindest halbwegs einfach einen linux port herzustellen is das winAPI

Dann is bei .NET das problem das es net überall läuft weil man n .NET framework braucht, und viele nutzer weigern sich das zu installiere...
bei MFC braucht man die MFC runtimes, also sieht es ähnlich aus...

Tja.. bleibt das API.

Kombination von API und MFC ist grundsätzlich nicht vorgesehen, aber möglich. Sollte jedoch vermieden werden, schon aus dem grund weil sich MFC über die API header aufregt und umgekehrt.


----------



## Sebastian Thalhammer (18. Januar 2004)

Mit was programmierst du?

Bei Win API stört mich aber das detailgenau editieren der Form. (Buttons, Textboxen, usw.) Bei MFC geht das ja leichter mit dem Editor. Grundsätzlich programmiere ich ja auch gerade Win API aber da ich gerade erst angefangen habe wollte ich mich mal nach anderen Möglichkeiten umhören.


----------



## chibisuke (18. Januar 2004)

ch programmiere eigendlich fast ausschließlich API... nur wenn ich n bestehendes Programm erweitern oder abändern muss greif ich auf die dort verwendeten elemente zurück.

Die einzige Ausnahme stellt hier die Spiele Programmierung dar, da arbeite ich im 2D bereicht fast ausschließlich mti DirectDraw und im 3D bereich mit OpenGL

btw: den Editor kannst du auch beim API benutzen, spaart viel arbeit.


----------



## Sebastian Thalhammer (18. Januar 2004)

Was? wie mach ich das?
Das musst du mir genauer erklären.


----------



## chibisuke (18. Januar 2004)

Erstell deinen Dialog ganz normal mit dem Resourcen editor, und dann:

HWND CreateDialog(
  HINSTANCE hInstance,  // handle to application instance
  LPCTSTR lpTemplate,   // identifies dialog box template name
  HWND hWndParent,      // handle to owner window
  DLGPROC lpDialogFunc  // pointer to dialog box procedure
);


hInstance ist klar
lpTemplate ist die resourcenID (ACHTUNG: MAKEINTRESOURCE() benutzen)
hWndParent ist das elternfenster 
und lpDialogFunc ist die dialog prozedur die zu dem dialog gehöhrt. Funktioniert ähnlich wie eine WindowProc nur das sie BOOL zurück gibt, 

BOOL CALLBACK DialogProc(
  HWND hwndDlg,  // handle to dialog box
  UINT uMsg,     // message
  WPARAM wParam, // first message parameter
  LPARAM lParam  // second message parameter
);

Du musst außer bei WM_INITDIALOG, true zurück geben wenn du die message verarbeitet hast, und false wenn nicht.

Wenn du Window-handle von den elementen brauchst gibt die mit GetDlgItem();

Ähnliches gilt auch für Menüs....
Menüs werden mit 
HMENU LoadMenu(
  HINSTANCE hInstance,  // handle to application instance
  LPCTSTR lpMenuName    // menu name string or menu-resource 
                        // identifier
);
aus den resource geladen.


----------



## Tobiasm (18. Januar 2004)

> _Original geschrieben von chibisuke _
> *Also .NET is neu, alles will .NET haben, und in ein paar jahren wird man drauf kommen wie blöd man eigendlich is wenn man .NET programmiert.
> 
> round(Portabilität) = NULL
> ...



Die Portabilität ist sehr wohl gegeben. Was ist denn mit Mono? Ganz nebenbei ist alles andere (also MFC + Win32-API) noch weniger Portabel. Wenn Du portibilität willst, nimm Java oder C++ mit QT.



> _Original geschrieben von chibisuke _
> *
> Das einzige wo du ner chance hast, zumindest halbwegs einfach einen linux port herzustellen is das winAPI
> *



lol. Das ist nicht Dein Ernst, oder ? Jetzt sag mir mal, wie Du mit der Win32-API einen Port machen willst ? Unter Linux ist so ziemlich alles anders und man müsste jeden Klein umschreiben. Da wäre es vermutlich sogar einfacher in .Net zu programmieren und sich dann die Klassen, die man braucht, noch einmal unter Linux neu zu programmieren (was man aber dank Mono größtenteils nicht braucht)...



> _Original geschrieben von chibisuke _
> *
> Dann is bei .NET das problem das es net überall läuft weil man n .NET framework braucht, und viele nutzer weigern sich das zu installiere...
> *



Sicher? Ich sehe das eher anders. Wenn man es mit dem Programm mitliefert (z.B. auf CD) wird wohl kaum ein Nutzer damit Probleme haben. Einzig über das Internet gibt es Probleme, weil es doch relativ groß ist. Aber das wird auch Ende dieses Jahres Geschichte sein, weil dann sehr viele Leute auf Windows .Net haben werden und unter Linux wird es länger dauern aber auch kommen.



> _Original geschrieben von chibisuke _
> *
> bei MFC braucht man die MFC runtimes, also sieht es ähnlich aus...
> *



Die kann man auch statisch linken.



> _Original geschrieben von chibisuke _
> *
> Tja.. bleibt das API.
> *



Klar, damit man auch wirklich alle Portabilität verliert (es gibt da Teilweise schon Probleme zwischen den einzelnen Versionen von Windows!) und man sau viel Arbeit hat, weil man wirklich jeden  von Hand machen muss.

MfG

Tobias


----------



## Alexander Schuc (18. Januar 2004)

> _Original geschrieben von Sebastian Thalhammer _
> *Hi.
> 
> Mir geht die Frage durch den Kopf, welcher dieser Teile die Zukunft gehört.
> ...



Hallo,

kommt darauf an für welche Plattform du hauptsächlich programmieren willst.
Sollte dies Windows sein, würde ich dir auf alle Fälle zu .net und C# raten, denn das ist nunmal die Zukunf von Windows.

Wenn du aber auch gerne unter Linux arbeiten willst solltest du evt. bei Java oder C++ etc. reinschnuppern. C# wäre allerdings auch eine Möglichkeit. Wie schon erwähnt gibts es das mono Projekt, welche das .net Framework für Linux umsetzt. Leider ist die Class Library noch nicht komplett, aber es ist schon recht funktionsfähig.
Solltest du dich für .net und C# entscheiden bist du (bei mir) im .net Forum herzlich willkommen. 



> Also .NET is neu, alles will .NET haben, und in ein paar jahren wird man drauf kommen wie blöd man eigendlich is wenn man .NET programmiert.


Vorallem will MS .net. Aber kannst du deine Aussage irgendwie begründen?


Mfg,
Alex


----------



## chibisuke (18. Januar 2004)

Tobiasm hat gesagt.:
			
		

> Die Portabilität ist sehr wohl gegeben. Was ist denn mit Mono? Ganz nebenbei ist alles andere (also MFC + Win32-API) noch weniger Portabel. Wenn Du portibilität willst, nimm Java oder C++ mit QT.


das ist nicht DEIN ernst! Mono? ja mono schön und gut, wie sollen die aber die APIs von .NET nachbilden wenn nahezu alle elemente daran (z.B. DCOM) durch Patentrecht geschützt ist? Von daher, Portabilität nahezu NULL... Aber das Thema wunde in anderen Threads schon hundert mal durchgekaut, ich ich bins leid über Tatsachen zu diskutieren.


> lol. Das ist nicht Dein Ernst, oder ? Jetzt sag mir mal, wie Du mit der Win32-API einen Port machen willst ? Unter Linux ist so ziemlich alles anders und man müsste jeden Klein umschreiben. Da wäre es vermutlich sogar einfacher in .Net zu programmieren und sich dann die Klassen, die man braucht, noch einmal unter Linux neu zu programmieren (was man aber dank Mono größtenteils nicht braucht)...


ich sagte nicht, das es ideal ist, ich sagte lediglich, das es DAS element von den 3en ist das noch am ehesten portablen ist... MFC kannst du vergessen, außer du willst die MFC klassen von hand schreiben, .NET, Mono... Da benutzt du mal die  funktion, dann findest du dazu sicher genug was hier gegen portabilität spricht.


> Sicher? Ich sehe das eher anders. Wenn man es mit dem Programm mitliefert (z.B. auf CD) wird wohl kaum ein Nutzer damit Probleme haben. Einzig über das Internet gibt es Probleme, weil es doch relativ groß ist. Aber das wird auch Ende dieses Jahres Geschichte sein, weil dann sehr viele Leute auf Windows .Net haben werden und unter Linux wird es länger dauern aber auch kommen.


Ja, ich kenne viele nutzer die sich weigern, und zwar schon deshalb, wenn man den Datenverkehr von .NET Analysiert findet man ettliches was da nicht hinein gehöhrt,,,, änlichkeiten zu Mediaplayer 9 durchaus beabsichtigt, wenn man so will... aber das ist ja auch der Grund wiso diverse Spyware Scanner inzwischen meckern.


> Die kann man auch statisch linken.


und eine datei die normal 200kB hatt auf 3MB aufblasen.


> Klar, damit man auch wirklich alle Portabilität verliert (es gibt da Teilweise schon Probleme zwischen den einzelnen Versionen von Windows!) und man sau viel Arbeit hat, weil man wirklich jeden  von Hand machen muss.


natürlich, aber immer noch besser als MFC oder .NET, und andere Alternativen waren ja nicht gefragt.


> Vorallem will MS .net. Aber kannst du deine Aussage irgendwie begründen?


Das hab ich doch oder etwa nicht? Linux ist immer mehr im kommen, und Mono wird nie das .NET framework exakt nachbilden können wegen lizenzrechte. Und vor allem, Wenn es dir entgangen ist, viele Leute Pfeifen inzwischen auf M$.



> C# wäre allerdings auch eine Möglichkeit.


Wenn man davon absieht das C# eigendlich Microsofts implementation von Java ist... mit dem C/C++ syntax hatt es jedenfalls nicht mehr so viel gemein wie mit dem Java syntax. das einzige was noch an C++ erinnert ist die tatsache das man kein "extends" zum vererben benutzt sondern einen : ...Aber naja..
Ach und wo wir schon bei Java sind... Das ist das andere Extrem zu .NET ;-) zwar nahezu komplett Platformunabhängig, solange man kein JNI benutzt, aber naja...

Noch dazu kommt, das das WinAPI eine viel leichtere migration auf andere Sprachen erlaubt, was ja auch nicht ohne ist... z.B. hab ich vor einiger zeit Stunden damit verbracht eine Externe Assembler routine als Member einer klasse zu Linken! Nichts im vergleich zu der zeit die ich durch Assembler gespaar hab, aber immerhin.

So langsam bin ich das den Ewigen streit "Was ist besser" leid. Jeder hatt hier seinen Standpunkt, und jeder kann immer wieder Argumente hin und her schieben, also spaar euch eure Argumentationen. Jeder hatt seinen Standpunkt.

Trotzdem, gut wenn auch jemand die andere Seite der Geschichte ein wenig besser erwähnt, so kann sich Sebastian seine eigene Meinung dazu bilden, und nicht nur meine nachplappern.


----------



## Daniel Toplak (19. Januar 2004)

*Portabilität?!*

Ich behaupte mal einfach, das die Zukunft nicht .Net gehören wird.
Auf Windows kann/wird .Net Zukunft sein, aber auch nur weil M$ es so will.
Aber die haben uns ja noch nie gefragt was wir wolllen, oder?
Ich gehöre zu denjenigen, die sich weigern .Net zu installieren.
Warum:
- Groß
- Überladen
- Unnötig

Zum Thema Plattformunabhängig:
Viele Leute sind zu engstirning, sie blicken nicht weiträumig.
Bei Plattformunabhängikeit spreche ich nicht nur von Windows und Linux, denn es gibt noch zig andere Betriebssysteme, die durchaus ihre Daseinsberechtigung haben.
Und im Bereich professioneller Plattformunabhängiger Anwendungen wird .Net keine Rolle Spiele. Auch Java ist glaube ich keine große Alternative. (Chris bitte verzeih mir  ).
Ok ich kann über Java nicht groß Urteilen, aber ich kann auch Gründe nennen, die dagegen Sprechen:
- benötigt JRE
- Performance
- kein echten Binaries (oder täusch ich mich da) in bezug auf Closed Source

Zum Thema Mono
Also beim kurzen Überfliegen des Mono-Projektes sind mir 2 große Nachteile aufgefallen.
- Nicht Plattformunabhängig bezieht sich nur auf Linux (ok evtl. lässt es sich auf anderen UNIX-Systemen übersetzten
- Absolut unvollständig  und das wird es evtl. auch immer bleiben, siehe Aussage von chibisuke

Also bedeutet der Weg .Net über Mono doch auch nur eine Sackgasse, oder?
Ich für meinen Teil muss beruflich Anwendungen (mit GUI) entwickeln, die auf folgenen Betriebssystemen Lauffähig sind:
Windows
Linux
SunOS
HP-UX
Irix
AIX
und da hat .Net keine Chance.
Denkt mal darüber nach.

Gruß Homer


----------



## chibisuke (20. Januar 2004)

*Re: Portabilität?!*



> _Original geschrieben von Daniel Toplak _
> *Auch Java ist glaube ich keine große Alternative. (Chris bitte verzeih mir  ).
> Ok ich kann über Java nicht groß Urteilen, aber ich kann auch Gründe nennen, die dagegen Sprechen:
> - benötigt JRE
> ...



äh... falsch ;-)

Stichwort Excelsior JET....http://www.excelsior-usa.com/jet.html
Damit kannst du in er Pro version 1.) JRE unabhängige dateien erstellen
2.) wird durch das Compilieren die Performance n nettes stück in die höhe getrieben
3.) Ist das ergebnis des diese Compiler hier auspukt eine ECHTE x86-PE EXEcutable.
naja soweit für Windows, für andere Systeme gibt es ähnliche Compiler.


----------



## Thomas Kuse (20. Januar 2004)

Wer Linux und Windows gleichermaßen mit C++ GUI Programmen eindecken will, kommt um Qt aber fast nicht herum.
Im Normalfall sind die Quellcodes 1:1 in Linux und Win32 compilierbar!


----------



## Christian Fein (20. Januar 2004)

Tobiasm hat gesagt.:
			
		

> Die Portabilität ist sehr wohl gegeben. Was ist denn mit Mono? Ganz nebenbei ist alles andere (also MFC + Win32-API) noch weniger Portabel. Wenn Du portibilität willst, nimm Java oder C++ mit QT.


mono wird nicht alles umsetzen was im .net Framework vorhanden ist. Aus dem einfachen Grund:
Softwarepatente. 

Errinnert euch an einen Spruch vom Microsoft CEO Steve Ballmer:
Es wird nur eine .net Plattform geben, und die ist von Microsoft.



> Sicher? Ich sehe das eher anders. Wenn man es mit dem Programm mitliefert (z.B. auf CD) wird wohl kaum ein Nutzer damit Probleme haben. Einzig über das Internet gibt es Probleme, weil es doch relativ groß ist. Aber das wird auch Ende dieses Jahres Geschichte sein, weil dann sehr viele Leute auf Windows .Net haben werden und unter Linux wird es länger dauern aber auch kommen.


Aber mit einem anderen Framework, womit die portabilität nicht gewährleistet ist.

.net wird nicht portabel werden. Um mit .net portable zu programmieren muss mono sowohl auf Windows als auch auf Linux Plattform verwendet werden. Portables hin und her zwischen mono  und .net wird nicht möglich sein.

Ich programmiere .net seid der Alpha version des Frameworks und finde es auch ganz gelungen (kein Wunder bei der Vorlage: Java). Damals wurde noch die portabiltät beworben, mittlerweile ist Microsoft da natürlich von weg. Portabilität heisst in Redmond:
Windows XP -> Windows CE -> Smartphone.
Aber selbst da (Smartphone) ist .net noch sehr eingeschränkt und wird wohl auch keine Rolle mehr spielen.


----------



## Christian Fein (20. Januar 2004)

*Re: Portabilität?!*



			
				Daniel Toplak hat gesagt.:
			
		

> I
> Zum Thema Plattformunabhängig:
> Viele Leute sind zu engstirning, sie blicken nicht weiträumig.
> Bei Plattformunabhängikeit spreche ich nicht nur von Windows und Linux, denn es gibt noch zig andere Betriebssysteme, die durchaus ihre Daseinsberechtigung haben.
> ...



Java spielt schon eine grosse Rolle in plattformunabhängigen Anwendungen.. Java ist nach C++ die 2. meist eingesetzte Sprache. Gerade wenn es um sogenannte Business-Anwendungen geht die stark auf Netzwerke setzen ( SOAP - RPC - Verteilte Systeme) ist Java die nr 1.
IBM mit ihrem Websphere, BEA mit Weblogic , Oracle , Borland verdienen sich die Finger krum und dämlich an den jeweiligen Applikationsserver.
Das sind Cash-Cows für die Firmen. Amazon hat die Webseite mithilfe J2EE aufgebaut. 

Zur performance, da war vor kurzem erst ein neuer Benchmark in der iX der aufzeigte das Java mittlerweile 90% an C++ heran. In manchen Operationen sogar schneller als C++, das kommt durch den HotSpot Compiler der den Code extrem optimiert. Ich lese dazu gerade ein Buch, es ist erstaunlich was dieser durch Caching und ähnliche Techniken alles leistet. 
Java wird schon seid 1.2 nicht mehr wirklich interpretiert. Auch wenn kompilierter Java Code immer noch bytecode ist, wird dieser bei Bedarf in binary kompiliert.

Java hat sich nicht durchgesetzt auf dem Desktop, das stimmt. Das liegt zumeist an der mangelenden Performance von Swing Oberflächen. Das problem ist die meisten Leute
nehmen die Geschwindikeit von Swing Oberflächen und münzen das ganze als Java ist langsam.  Das geht mir gewaltig auf die Eier, weil es eine extrem unqualifizierte Aussage ist. 
Swing ist deshalb so langsam, weil sämmtliche Controlls auf den Monitor gezeichnet werden und nicht nativ vom Betriebssystem her kommen. Dies war nötig da nicht alle Plattformen auf denen die VM portiert wurde, z.b eine Combobox vorhanden war. Also gibt es AWT welches ein kompromiss aus allen OS ist und demnach nur wenige Controlls bietet, und Swing welches durch die zusatzschicht etwas träge wirkt.
Aber ich programmiere mittlerweile wenn ich GUIs programmiere mit SWT. SWT gibt es nicht für alle Plattformen auf denen eine JVM läuft, sondern nur auf jenen die bestimmte Anforderrungen entsprechen. So gibt es SWT für Windows, Linux/UNIX GTK und Motif, MacOS und OS/2. Damit dürfften doch mehr als 99% aller eingesetzten OS entsprechen. Durch SWT wird nicht selber gezeichnet sondern ähnlich wie bei AWT die nativen Betriebssystemkomponenten genutzt. SWT Applikationen unterscheidet sich in aussehen und feeling rein gar nicht von nativen Applikationen. Wer das mal gerne testen möchte, der gehe auf http://www.eclipse.org und lade sich eclipse herunter 




			
				Daniel Toplak hat gesagt.:
			
		

> I
> 
> Zum Thema Mono
> Also beim kurzen Überfliegen des Mono-Projektes sind mir 2 große Nachteile aufgefallen.
> ...



Auch wenn du von Java keine Ahnung hast (  scherz), hier hast du vollkommen recht


----------



## Christian Fein (20. Januar 2004)

> _Original geschrieben von Thomas Kuse _
> *Wer Linux und Windows gleichermaßen mit C++ GUI Programmen eindecken will, kommt um Qt aber fast nicht herum.
> Im Normalfall sind die Quellcodes 1:1 in Linux und Win32 compilierbar! *



Mich dünkt es gibt auch ein GTK Port für Windows? 

shit habe ich jetzt wirklich 3 Beiträge hintereinander geschrieben?  *ich oller spamer*


----------



## Thomas Kuse (20. Januar 2004)

Ja hier: http://www.inkscape.org/cgi-bin/wiki.pl?Win32Port
Aber ich mags nicht 

[edit]
wenn ich das schon höre 
*[..]so all Gtk+ widgets render text painfully slowly[..]
*


----------



## Sebastian Thalhammer (20. Januar 2004)

Nun. Ich glaube ich hätte meine Frage genauer formulieren sollen. 
Um zum Punkt zu kommen. Ich bin die ewige textbasierte Programmierung leid. Ich möchte grafische Anwendungen erstellen. Da ich aber keine Kurse besuche sondern mir alles selber lernen muss/will, bin ich gezwungen den richtigen Weg von Anfang an zu wählen. 

Ich möchte, da ich schon längere Zeit in C/C++ programmiere, auch dabei bleiben. Ich möchte Anwendungen erstellen, die auch mit dem Internet arbeiten können sowie ich Anwendungen schreiben will, die systemnaher sind (z.b.: Zugriff auf Ports oder Hardware).

Vielleicht ist das aber auch nicht möglich, deshalb bitte ich um Erklärung.


----------



## Thomas Kuse (20. Januar 2004)

Qt, GTK+, MFC, .NET, WinAPI

Das sind alles riesige Befehlsbibliotheken.
Du solltest Dir davon eine auswählen, nach den Kriterien die Du benötigst!
Mithilfe der normalen Bibliotheken von C++ kannst Du auch in Konsolen-Programmen Hardware ansprechen oder Netzwerkverbindungen aufbauen etc. es liegt also alles an Dir und Deinem Portemonaie.


----------



## Christian Fein (20. Januar 2004)

> _Original geschrieben von Sebastian Thalhammer _
> *Nun. Ich glaube ich hätte meine Frage genauer formulieren sollen.
> Um zum Punkt zu kommen. Ich bin die ewige textbasierte Programmierung leid. Ich möchte grafische Anwendungen erstellen. Da ich aber keine Kurse besuche sondern mir alles selber lernen muss/will, bin ich gezwungen den richtigen Weg von Anfang an zu wählen.
> 
> ...



Den richtigen Weg von Anfang an gibt es nicht. Grundsätzlich bringt dich jede Kentniss weiter. Sprich wenn du C# und .net lernst, so hilft dir das Java zu verstehen und zu lernen, genauso wie du auch für C++ etwas lernst. 
Solange du dich nicht auf schlechte Programmiersprachen wie VB versteifst, oder sehr 
eigenwillige wie LIPS, wird dich jede Kentnis weiterbringen.
Eine schöne biblothek wurde schon vorgeschlagen Qt. Da ich absoluter Java Liebhaber bin, muss ich dir auch zu Java raten 

Kurz gesagt: Willst du dich auf Windows beschränken und Windows wirklich verstehen:
C++ &  WinAPI
Willst du dich auf Windows beschränken, und GUIs und Webprogrammierung durchführen:
C# .net und ASP.net
willst du Plattformunabhängig programmieren:
C++ & Qt
willst du plattformunabhängig programmieren, webprogrammierung und Handyprogrammierung und dabei sexy wirken:
Java


----------



## Thomas Kuse (20. Januar 2004)

Hey wir sind hier im C++ Board ... Bitte keine Publicity für JAVA hier  ;-]


----------



## Christian Fein (20. Januar 2004)

> _Original geschrieben von Thomas Kuse _
> *Hey wir sind hier im C++ Board ... Bitte keine Publicity für JAVA hier  ;-] *




Hey in meinem Beitrag drüber habe ich:
Java nur 4 mal genannt, 
C++ 3 mal C# 2 mal und VB + LISP jeweils 1 mal.
Das heisst
4 mal Java 6 mal andere Programmiersprachen und davon 50% C++ 

Unterstell mir hier mal keine publictity für die "most sexy programming language"


----------



## chibisuke (20. Januar 2004)

Also grundsätzlich bei Windows anwendungen, wenn du was Windows eigenes haben willst, dann WinAPI

Wenn du größtmögliche kompatiblität zu linux willst, dann würd ich GTK vorschlagen....


----------



## Thomas Kuse (20. Januar 2004)

@chibisuke:
Wo gibt es Kompatibilitäts-Einschränkungen bei Qt?


----------



## chibisuke (20. Januar 2004)

Ich hab nicht gesagt das es solche gibt, ich sagte lediglich das ich persöhnlich GTK empfehlen würde...


----------



## Act of Fate (26. Januar 2006)

Tja....arm...niemand erwähnt hier wxWidgets http://www.wxwidgets.org

Einfach genial, schaut es Euch an..einfacher und besser geht das nciht.


----------

