MinGWs Zukunft?



  • Hallo! Normalerweise arbeite ich mit VisualC++. Da ich aber eine OSS Bibliothek entwickle, die möglichst auch von MinGW Anwendern genutzt werden soll, kompiliere und teste ich notgedrungen auch mit dem MinGW. Meine Bibliothek funktioniert also sowohl mit MSVC als auch MinGW.

    Jetzt habe ich mal den aktuellen MinGW 4.4.1 aus dem Code Blocks zum Testen genutzt. Ich muß aber trotz der Aktualität folgendes festetellen:

    1. der MinGW kennt immer noch kein GDI+ (ab WinXP standard). Man kann mit Aufwand die orig. GDI+ LIB und Header für MinGW anpassen, aber das ist doch recht aufwändig.
    2. der MinGW scheint auch bei der alten GDI sich nicht fort zu entwickeln. Ich benutze zum Zeichnen der Fonts das Anti-Aliasing mittels CLEARTYPE_QUALITY (ab WinXP verfügbar). Kennt der MinGW leider nicht, also nutze ich per bedingter Kompilierung ANTIALIASED_QUALITY. Kein Beinbruch, aber gibt mit zu denken.

    Weiß jemand wie es mit dem MinGW steht? Mittlerweile ist Win7 draußen, und der aktuellste MinGW kann nicht mal die WinXP API Grafik-API. Ich weiß leider nicht, wie es mit der restlichen Windows API steht. Aber ich kann mir vorstellen, das Direct2D von Win7 wahrscheinlich auch nicht von MinGW unterstützt wird? Irgendwann wird es doch unbrauchbar?

    Macht es also Sinn den MinGW noch groß zu unterstützen? Denn das Windows SKD inkl. Compiler ist ja kostenlos. Wie macht ihr das, wenn ihr aktuelle Windows APIs nutzt (also mehr als nur Std-C++) und eine (OSS) Bibliothek pflegt?

    Gibt es offizielle Infos zu MinGWs Zukunft?



  • Macht es also Sinn den MinGW noch groß zu unterstützen?

    Eigentlich nicht. Die Weiterentwicklung von MinGW erfolgt nicht sichtbar, die Qualität des generierten Codes ist (Größe der Exes 🙄 ) schlecht, verglichen mit MSVC. Dann noch die fehlende Unterstützung für Windows-spezifische Libs... Ich würde ihn nicht mehr unterstützen.

    Entweder, das Projekt rappelt sich wieder auf und wird wieder aktuell und brauchbar, oder es stirbt (danach sieht es für mich aus). In beiden Fällen ist man den Klotz am Bein los. 😃

    Der einzige Grund, warum ich MinGW nutze ist der ELF-Crosscompiler, den ich für PrettyOS brauche.

    Solange das Projekt nicht vorwärts kommt, würd ich die Unterstützung für MinGW fallen lassen. (Vielleicht bringt es manche Leute dazu, zu besseren Compilern zu wechseln)



  • Der Qt-Creator setzt auf MinGW, aber da du eh nur für Windows entwickelst würde ich immer nur VisualStudio unterstützen. Das nutzen seit der EE die Meisten die Windows only unterwegs sind.

    G hibbes



  • Das ist ein lizenzrechtliches Problem. Bei MinGW dürfen offiziell keine angepassten Header mitgeliefert werden, da diese dann noch Code von Microsoft enthalten würden. Die einzige Möglichkeit ist es die Header von Grund auf zu rekonstruieren, wobei Informationen aus Dokumentation und Testprogrammen kommen. Der Aufwand ist allerdings recht groß und unnötig, da man inoffiziell an jeder Ecke angepasste Header bekommt.



  • Mr X schrieb:

    Macht es also Sinn den MinGW noch groß zu unterstützen?

    Eigentlich nicht. Die Weiterentwicklung von MinGW erfolgt nicht sichtbar,

    Bist Du auf dem aktuellen Stand? Ich hatte den Eindruck, das Geschichte.

    die Qualität des generierten Codes ist (Größe der Exes 🙄 ) schlecht, verglichen mit MSVC.

    Auch das ist Quatsch, würde ich mal sagen. Ein schlichtes cout<<"hello, world\n"-Programm mit 9216 Bytes.



  • Der erzeugte Code ist mir ehrlich gesagt egal. Darum geht es mir überhaupt nicht!

    Mir geht es um die Windows API! Kann ein Compiler für Windows mit der Windows API umgehen? Wenn er das irgendwann nicht mehr kann, wird er nicht mehr für die Windows-Entwicklung geeignet sein. Oder?

    Das MinGW-Projekt muß doch aber eine Roadmap haben? Ich selber kann mich aber als Einzelkämpfer nicht auch noch darum kümmern. Ich habe schon GDI+ aus meinem Projekt raus geschmissen, wegen dem MinGW. Da meine Bibliothek noch recht klein ist, und jetzt ein Unix-Port ansteht, kann ich mit den Einschränkungen noch leben.

    Aber lange werde ich die Einschränkungen nicht mitmachen. Mal schauen wie viel User den MinGW dann nutzen.



  • hibbes schrieb:

    Der Qt-Creator setzt auf MinGW, aber da du eh nur für Windows entwickelst würde ich immer nur VisualStudio unterstützen.

    Es wird einen Unix-Port geben.

    Qt u.a. kann ich nicht als Maßstab nehmen, weil diese keine vollständige Windows API nutzen. Qt u.a. nutzen nur einen Basisteil der Windows-API und alles andere wird plattform-neutral neu implementiert. Ich nutze aber nach Möglichkeit alles was mir Windows zur Verfügung stellt. Ich will es eigentlich gerade nicht so machen, wie Qt, FLTK u.a. es tun! Deshalb wird mir MinGW vielleicht in der Zukunft ein Hindernis. Noch geht alles, da die Bibliothek noch eher basic ist.



  • Geht es nur darum, daß die Header-Files nicht da sind? Die Windows-DLLs müßten doch gehen. Wenn Du eigene Header pflegst und nach und nach nur die Funktionen reinmachst, die Du brauchst, geht das ganz schmerzfrei, oder?



  • Anscheinend lässt Mingw nur noch die win32api durch Cygwin pflegen. Der Download und die Datei sind der Sorgeforge Seite und im SCM entfernt. Allerdings hat Cygwin GDI+ API vor einen Monat reingenommen. Außerdem ist es sehr bekannt wie gut Mingw ihre Release pflegen... eher garnicht. Also ich würde MinGW nicht supporten wollen.



  • @Artchi: Tja, schaut so aus als müsstest du entweder diese inoffiziellen Headerdateien für MinGW nehmen oder wirklich für jedes System nen anderen Compiler voraussetzen.



  • volkard schrieb:

    Geht es nur darum, daß die Header-Files nicht da sind? Die Windows-DLLs müßten doch gehen. Wenn Du eigene Header pflegst und nach und nach nur die Funktionen reinmachst, die Du brauchst, geht das ganz schmerzfrei, oder?

    Die GDI+ Libs hatte ich schon mal per Internet-Anleitung für den MinGW angepasst. Man mußte so um die zwanzig Zeilen im <gdiplus.h> ändern. Weiterhin braucht man ja auch eine gdiplus.a-Datei, obwohl es nur eine gdiplus.lib von MS gibt, auch wenn die Implementierung in einer DLL ist. Die .lib kann man mit einem Tool nach .a konvertieren.

    Letztendlich könnte ich ein paar Signaturen von Klassen und Funktionen ausliefern. Aber die .a muß man noch besorgen.

    Aber dann denke ich mir: warum muß ich die fehlenden Libs pflegen? Ich habe schon mit meiner Lib genug Arbeit. Ganz davon abgesehen, das ich den MinGW pers. nicht nutze. Man müsste eigentlich so denken: wer meine Lib mit seinem MinGW nutzen will, kann ja die Arbeit machen.

    Vorerst werde ich Kompromisse eingehen. Wenn mein Projekt mehr Manpower hätte, könnte man evtl. per bedingter Kompilierung für den MinGW die GDI und für den MSC die GDI+ bzw. später Direct2d nutzen.



  • Zeus schrieb:

    Anscheinend lässt Mingw nur noch die win32api durch Cygwin pflegen. Der Download und die Datei sind der Sorgeforge Seite und im SCM entfernt. Allerdings hat Cygwin GDI+ API vor einen Monat reingenommen. Außerdem ist es sehr bekannt wie gut Mingw ihre Release pflegen... eher garnicht. Also ich würde MinGW nicht supporten wollen.

    Sieht ja echt übel aus. Fragt sich nur, warum alle so auf den MinGW fliegen? OK, als reiner C und C++ Compiler (also für Standard-Libs) ist er sicherlich brauchbar. Aber warum wird er z.B. im Code Blocks so favorisiert? Solche IDEs können doch problemlos das Windows SDK + MSC nutzen bzw. verweisen. Denn diese sind ja kostenlos von MS erhältlich.



  • Die Meinung scheint wohl zu sein, das man den MinGW nicht unterstützen muß. Werde ich wohl auch ab einem bestimmten Punkt in der Zukunft so handhaben.

    Danke für Eure Meinung. 🙂



  • Artchi schrieb:

    Zeus schrieb:

    Anscheinend lässt Mingw nur noch die win32api durch Cygwin pflegen. Der Download und die Datei sind der Sorgeforge Seite und im SCM entfernt. Allerdings hat Cygwin GDI+ API vor einen Monat reingenommen. Außerdem ist es sehr bekannt wie gut Mingw ihre Release pflegen... eher garnicht. Also ich würde MinGW nicht supporten wollen.

    Sieht ja echt übel aus. Fragt sich nur, warum alle so auf den MinGW fliegen? OK, als reiner C und C++ Compiler (also für Standard-Libs) ist er sicherlich brauchbar. Aber warum wird er z.B. im Code Blocks so favorisiert? Solche IDEs können doch problemlos das Windows SDK + MSC nutzen bzw. verweisen. Denn diese sind ja kostenlos von MS erhältlich.

    Tja Code::Blocks kann ich mir nur so erklären als dass die IDE sehr gut geeignet ist um mit reinem C++ anzufangen, da es egal ist welches OS man nutzt. Die wxWidgets Unterstützung von CB ist auch nicht zu verachten. CB ist für mich ein Ersatz für das frühere DevC++ was ja in sehr vielen Artikeln und Büchern als Lehr-IDE bevorzugt wurde.

    MinGW wird halt immer dann gerne genommen wenn man sich nicht auf ein OS festlegen möchte. Unter Linux ist GCC ja eh DER Compiler und unter Darwin OSX weiß ich es nicht.



  • Das läuft auf die Frage hinaus, wie verhält sich Microsoft den "Kleinkunden" gegenüber, wenn es keinen Wettbewerber mehr gibt?

    Wird dann der Compiler und die API noch mit der notwendigen Ernsthaftigkeit weiterentwickelt, wenn keine Alternative da ist? War es nicht von es jahrelang von MS Usus die Mitbewerber mit "speziellen" Funktionen in ihren Programmen aus zu bremsen?

    Und wird es dann, wenn Microsoft die alleinige Lösung ist, noch kostenfreie Programme für z.B. Studenten geben?

    Kann ja sein das ich etwas missverstanden hab und Microsoft kein Wirtschaftsunternehmen, sonder ein charitativer Verein ist 😃

    Ich darf das noch schreiben, da ich nicht auf B.G.s oder seines Nachfolgers Gehaltsliste stehe 🕶



  • Es ist auch zusätzlicher Aufwand wenn man in einer IDE verschiedene Compiler (und vor allem Debugger) unterstützen will. Ich weiß auch grad gar nicht ob der Visual Studio Debugger im Plattform SDK vorhanden ist, und ob dieser eine dokumentierte Schnittstelle besitzt. Da ist das Arbeiten mit gdb evtl. einfacher.



  • hibbes schrieb:

    Tja Code::Blocks kann ich mir nur so erklären als dass die IDE sehr gut geeignet ist um mit reinem C++ anzufangen, da es egal ist welches OS man nutzt. Die wxWidgets Unterstützung von CB ist auch nicht zu verachten. CB ist für mich ein Ersatz für das frühere DevC++ was ja in sehr vielen Artikeln und Büchern als Lehr-IDE bevorzugt wurde.

    Der CB kann ja mit dem MSC umgehen. Das ist ja der Witz. Nur als Default ist halt MinGW eingestellt. Die brauchen bloß das Default ändern, und den Download-Link angeben, wenn man das Windows SDK noch nicht hat.

    hibbes schrieb:

    MinGW wird halt immer dann gerne genommen wenn man sich nicht auf ein OS festlegen möchte. Unter Linux ist GCC ja eh DER Compiler und unter Darwin OSX weiß ich es nicht.

    Was hat das mit dem OS zu tun? Das Argument habe ich noch nie verstanden. Wenn ich den MSC benutze, kann ich trotzdem OS-unabhängig programmieren. Der MSC hat ja die C++-Standard-Library mit TR1.

    Und wenn ich die Windows API nutze, ist das Argument eh hinfällig. Und wenn ich z.B. wxWidgets mit MSC benutze, wird der Code eh unter Linux neu kompiliert werden müssen, dann halt mit GCC.

    Also, das Argument pro MinGW verstehe ich nicht. 😕



  • Tobiking2 schrieb:

    Es ist auch zusätzlicher Aufwand wenn man in einer IDE verschiedene Compiler (und vor allem Debugger) unterstützen will. Ich weiß auch grad gar nicht ob der Visual Studio Debugger im Plattform SDK vorhanden ist, und ob dieser eine dokumentierte Schnittstelle besitzt. Da ist das Arbeiten mit gdb evtl. einfacher.

    Zum Debugger kann ich leider nichts sagen. Aber CB unterstützt von Haus aus auch den MSC mit Windows SDK.



  • Die Beliebheit von Mingw ist Geschichte als es kein freien Kompiler unter Windows gabs *gg*



  • f.-th. schrieb:

    Das läuft auf die Frage hinaus, wie verhält sich Microsoft den "Kleinkunden" gegenüber, wenn es keinen Wettbewerber mehr gibt?

    Wird dann der Compiler und die API noch mit der notwendigen Ernsthaftigkeit weiterentwickelt, wenn keine Alternative da ist? War es nicht von es jahrelang von MS Usus die Mitbewerber mit "speziellen" Funktionen in ihren Programmen aus zu bremsen?

    Und wird es dann, wenn Microsoft die alleinige Lösung ist, noch kostenfreie Programme für z.B. Studenten geben?

    Kann ja sein das ich etwas missverstanden hab und Microsoft kein Wirtschaftsunternehmen, sonder ein charitativer Verein ist 😃

    MS hat genug Konkurrenz auf Windows:
    ICC (Intel C++ Compiler) http://software.intel.com/en-us/intel-parallel-composer/
    PGI Compiler Tools http://www.pgroup.com/
    Embarcadero Turbo C++ (ehem. Borland)

    Wobei der ICC der wohl bekannteste Konkurrent sein dürfte. Zumindest gibt es mehrere ernsthafte C++ Compiler für Windows. Den ICC kann man sogar von VisualStudio nahtlos aus benutzen.

    Übrigens konnte man das Plattform SDK inkl. MSC schon vor 8 Jahren kostenlos runter laden. Ist also nicht erst seit heute so. Ob es vorher schon kostenlos war, weiß ich nicht, da ich da noch das VisualC++ 6 gekauft hatte.


Log in to reply