MinGWs Zukunft?

blue-tec

Artchi schrieb:

blue-tec schrieb:

Ihr meint also die plattformunabhängige Entwicklung in C++, die gerade so schön mit Qt ins Rollen kommt, ist vom Aussterben bedroht?

Wenn man nicht weiter weiß, legt man den anderen Worte in den Mund, die sie nicht gesagt haben.
Nein, wir reden hier nicht von Qt und das Qt, FLTK u.a. aussterben sollen. Es geht um Windows-API! Die eine Anforderung (Windows API) schließt die andere Anforderung (Qt-API) nicht aus.

Ich habe die Anforderung "Windows API". Punkt! Entweder kann ein Produkt diese Anforderung erfüllen, oder nicht.

blue-tec schrieb:

Mir kann es eh egal sein

Dann klinke dich aus dem Thread raus, wenn dir das Thema Windows-API egal ist. Wenn jemandem etwas egal ist, dann ist er auch nicht fähig, etwas konstruktives beizutragen.

Pass mal auf mein kleiner Bastelfreund,

soweit ich weiß probiert du genau wie Qt auch etwas plattforumunabhängiges zu entwickeln. Qt hat unter Windows sehr viel mit der WinAPI zu tun und nutzt dazu unter anderem MinGW.

Du meinst also nicht im ernst das Qt unter Windows nicht viel WinAPI nutzt Auch wenn sie einiges selbst machen, so nutzen sie sehr wohl auch die WinAPI und deswegen ist der Vergleich durchaus legitim?

So und jetzt erkläre mir und den anderen mal warum Qt nix mit der WinAPI und MinGW zu tun haben soll?

Zeus

blue-tec schrieb:

Ich kann mir nicht vorstellen das es mal keinen Windows Port für den GNU-Compiler geben wird, da ja immer mehr Leute und Firmen auch plattformunabhängig entwickeln.

Mingw ist keine Platform um plattformunabhängig zu entwickeln.

blue-tec schrieb:

Ich glaube Nokia würde sofort mitmachen einen neuen Port von G++ zu schreiben wenn sie irgendwie sehen würden das es um MinGW schlecht aussieht.

Nein, Nokia hat ehrgeizige Ziele für Qt, ich sprech sie gerne aus, sie wollen in kurzen Zeit die Funktionalität von .NET erreichen, falls du ein Beleg brauchst, nutzt Google.

Außerdem kann man Qt-Entwicklung wunderbar mit Visual Studio machen. Falls Mingw wirklich ausstirbt, dann wird Qt Creator halt für Windows so geändert, dass man das WinSDK braucht und benutzt die enthaltende Compiler davon. Wesentlich eleganter als sich die ganze Compilerentwicklung an sich zu binden.

blue-tec

Gut um es ganz Behördenlike genau so beschreiben. Nicht der MinGW allein ist eine Plattform um plattformunabhängig zu entwickeln, sondern die GNU-Compilertools sind es, wo dann wiederum MinGW der Windowspart dazu ist....und so weiter uns so fort.

Das Nokia nochmal krass anzieht und ähnliches bieten will wie .NET nur für wirklich alle relevanten Plattformen ist mir bekannt. Aber du hast recht wenn der Qt-Creator halt mit dem MS-Compiler oder Intel oder sonst was läuft ist eigentlich ziemlich schnuppe ob MinGW den Bach runter geht oder nicht.

Ach ja, man kann kostenlos mit VisualStudio Express Qt genauso gut entwicklen wie mit dem Qt-Creator? Ich habe gehört dass der Debugger vom Creator wesentlich besser für Qt ist als jener von MS, oder irre ich mich da? Aber das ist auch nicht relevant, ich habe mich auf den Creator eingeschossen und war von der ersten Minute an sofort begeistert und es kommen bis jetzt alle paar Monate neue Funktionen dazu und es macht einfach Spaß zu sehen was da alle passiert.

Es ist schön wenn es total egal wird unter welchem OS man arbeitet, aber jeder wie er will.

Gruß Blue-Tec

PhilippM

Du kannst mit Visual Studio problemlos Qt-Projekte kompilieren, und mit dem VS-AddIn (das es aber glaube ich noch nicht für VS10 gibt) wird das in der IDE auch recht komfortabel.

Aber das ist im Prinzip unnötig, da ja QtCreator absolut problemlos mit den Kommandozeilentools (nmake, cl, link) von VS10 zusammenarbeitet. Wenn du dir die debug-helper-libraries entsprechend auch mit VS10 kompilierst (das geht unter Extras->Einstellungen->Qt4, dann VS-kompiliertes Qt auswählen und auf Ausgabe-Hilfsbibliothek "Neu erstellen" klicken) hast du auch ein absolut "natives" Feeling von Qt-eigenen Typen im Debugger vom Qt-Creator. Das ist an Bequemlichkeit eigentlich nicht mehr zu überbieten.

Philipp

blue-tec

Danke für die Informationen, also kann man in Visual Studio genauso debuggen wie mit Qt-Creator ohne weitere Nachteile. Sind denn aber Addins nicht nur der kostenpflichtigen Version vorbehalten? Ich mache das alles ja nur als Hobby und will das auch nicht ändern und da ist mir VisualStudio zu teurer zumal ich keinen Mehrwert zum Creator für mich sehe.

So nun sind ja doch viele der Meinung das MinGW nicht mehr lange weiterbesteht, also bleibt den Leute von plattformunabhängiger Entwicklung nix mehr weiter übrig als auf mehrere Compiler zu setzen. Es müsste also zu beobachten sein wie bald viele große Projekte sich von MinGW distanzieren...ich bin mal gespannt.

Gruß Blue-Tec

Zeus

blue-tec schrieb:

Danke für die Informationen, also kann man in Visual Studio genauso debuggen wie mit Qt-Creator ohne weitere Nachteile. Sind denn aber Addins nicht nur der kostenpflichtigen Version vorbehalten? Ich mache das alles ja nur als Hobby und will das auch nicht ändern und da ist mir VisualStudio zu teurer zumal ich keinen Mehrwert zum Creator für mich sehe.

Addin dürften ab der Standard Version laufen. Bleib bei Creator.

blue-tec schrieb:

So nun sind ja doch viele der Meinung das MinGW nicht mehr lange weiterbesteht, also bleibt den Leute von plattformunabhängiger Entwicklung nix mehr weiter übrig als auf mehrere Compiler zu setzen. Es müsste also zu beobachten sein wie bald viele große Projekte sich von MinGW distanzieren...ich bin mal gespannt.

Gruß Blue-Tec

Unsinn, natürlich bleibt uns Mingw erhalten (mit alleine seinen Unangenehmlichkeiten).
Im Gegensatz zu Qt baut Artchi seine Lib so, dass er möglichst bestehende API verwendet, während Qt nur ein minimale API von System benutzt. Wenn der Primärcompiler von Windows Visual C++ und der von Linux GCC ist, wieso soll man Mingw supporten, wenndoch Mingw nicht mal die ganzen System-API ansteuern kann.

blue-tec

Na dann ist ja alles geklärt. MinGW bleibt, ist aber für viel und aktuelle WinAPI ungeeignet.

Gruß Blue-Tec

Artchi

blue-tec schrieb:

Pass mal auf mein kleiner Bastelfreund,

soweit ich weiß probiert du genau wie Qt auch etwas plattforumunabhängiges zu entwickeln. Qt hat unter Windows sehr viel mit der WinAPI zu tun und nutzt dazu unter anderem MinGW.

Du meinst also nicht im ernst das Qt unter Windows nicht viel WinAPI nutzt Auch wenn sie einiges selbst machen, so nutzen sie sehr wohl auch die WinAPI und deswegen ist der Vergleich durchaus legitim?

So und jetzt erkläre mir und den anderen mal warum Qt nix mit der WinAPI und MinGW zu tun haben soll?

Also, hier mal ein wenig Know-How von mir "Bastelfreund" für dich:

Qt hat das Konzept eine eigene Plattform zu sein, und somit praktisch seine eigene Runtime zu haben. Das haben viele Multiplattform-Toolkits, wie Qt, FTLT, GTK+ und mittlerweile wohl auch wxWidgets.

Zeus hat es erkannt und auch genannt, ich will es aber weiter ausführen. Mal ein ganz banales Beispiel, das übertrieben dargestellt ist:

Die API von z.B. Qt & Co. stellt das Zeichnen eines Pixels und eines gefüllten Rechtecks bereit:

void draw_pixel(int x, int y);
void fill_rect(rect r);

Was machen Qt & Co. in ihrer Implementierung? (es geht im Beispiel nur ums Prinzip!)

// Light wight
void draw_pixel(int x, int y)
{
#ifdef WIN32
     SetPixel( hdc, x, y, crColor); 
#endif
}

void fill_rect(rect r)
{
    // Rechteck Algorithmus nutzt draw_pixel-Funtion ohne #ifdef WIN32!
    // Im schlimmsten Fall muß draw_pixel millionenfach aufgerufen werden.
}

Hier wird der minimale Satz an Win32-API genutzt. Warum? Weil dadurch die Portierung auf andere Systeme weniger Aufwand bedeutet. Weil man weniger Code-Stellen ändern muß.

Nachteil? Ein Rechteck könnte mit der nativen Win32-Rechteck-Funktion schneller und/oder schöner gezeichnet werden.

Was mache ich, das ich die volle Win32-API nutzen will?

// Heavy wight
void draw_pixel(int x, int y)
{
#ifdef WIN32
     SetPixel( hdc, x, y, crColor); 
#endif
}

void fill_rect(rect r)
{
#ifdef WIN32
     FillRect(hdc, &r, brush);
#endif
}

Hier wird versucht so viel native Funktionen des Systems zu benutzen, um z.B. den Grafikchip das gefüllte Rechteck zeichnen zu lassen. Das heißt maximale mögliche Performance und evtl. ein anderes Aussehen, das eher der Plattform entspricht.

Nachteil? Ich muß für jedes System (Win32, X11 u.a.) einen Aufruf implementieren. Auf Systemen die keine Füllfunktion kennen, muß ich den Algorithmus trotzdem wie im ersten Beispiel implementieren! Denn die Funktion muß sollte trotzdem da sein. Also sehr viel Aufwand beim Portieren. Nativ ist aber immer vorzuziehen.

Hier ging es wohl gemerkt um ein dummes Rechteck. Es gibt aber so viele weitere Funktionen, die eine Library und System anbieten können. Und eine eigene Runtime hat den Vorteil, das die Library mit minimalen Aufwand überall kompiliert und man nur einen Basissatz-API anpassen muß.

Nachteil ist aber, das man nicht das Maximum aus einem System raus holen kann und sich die Funktionen für den Anwender fremd anfühlen können. Halt nicht nativ. Es ist eine Philosophie-Frage und ich verurteile Qt & Co. deshalb nicht. Aber es sind einfach Fakten, die ich hier nenne.

Sicherlich können solche Anwendungen und Libraries mit dem MinGW leben, aber ich pers. halte es für ein trauriges Ziel, das jede Anwendung auf jedem System gleich ist. Weil dann brauche ich keine Systemvielfalt mehr. Es ist für mich paradox, das ich z.B. X11 nutze, aber die Anwendung 1:1 wie die Windows-Version arbeitet (oder umgekehrt, in Windows habe ich X11-Verhalten). Dann kann ich auch gleich bei Windows bleiben.

Mein Anspruch ist Portabilität, aber bitte nicht zum Nachteil des Anwenders. Und ja, es ist ein Anspruch im wahrsten Sinne des Wortes.

Wenn ich noch weiter gehen würde, würde ich sogar nicht nur die Plattform unterscheiden, sondern noch die Compiler-Umgebung (MSVC und MinGW), was ich teilweise sogar praktiziere (siehe einen meiner vorherigen Posts!)! Aber die Man-Power ist begrenzt.

blue-tec

Da hast du mir leider gar nix neues erzählt, ich denke fast jeder hat schon mal kleine Wrapper um API Funktionen geschrieben und Fehlendes bei der einen oder anderen Plattform selbst implementiert. Mir ist auch klar das Qt viel selbst macht um den Portierungaufwand gering zu halten und es trotzdem schafft ein nativen Look hinzubekommen, während andere Frameworks wie wxWidgets mehr nativ sind und Libs wie FLTK so gut wie alles selbst machen. Das alles weiß man wenn sich ein paar Wochen mit C++ und GUI auseinandersetzt.

WinAPI verwendet Qt deswegen trotzdem auch mit MinGW, wie man auch aus de Headern sehen kann, ich habe nur mal kurz nachgeguck und gleich an Handle auf den Gerätekontex gefunden also einen hdc = GetDC blabla. Auch wenn sie die API sparsam nutzen.

Wenn man eine plattformunabhängige Lib entwickelt kann man ja nur viel anbieten aber dafür auch viel selbst machen oder den kleinsten gemeinsamen Nenner finden und ne 0815 Lib(im Vergleich zu Qt) machen die sehr eingeschränkt ist.

Gruß Blue-Tec

P.S. Ist ja auch Wurst, da wir ja herausgefunden haben das es wohl nicht so schlecht um MinGW aussieht.

Hello! fcekgbe interesting fcekgbe site!

f.-th. schrieb:

Wollt ihr ein paar Fragen zu dem Thema

Ich, ich, ich kann die Fragen beantworten!

Wie ist DOS Entstanden?

Bill Gates hat's programmiert.

Welche Firmen haben zu Anfang Windows entwickelt?

Das war Microsoft.

Welche Vorläufer gab es mit graphischen Bedieneroberflächen?

Hm, DOSSHELL oder Windows 1.0. Eines von dem beiden war es.

Welche Textverarbeitungen gab es vor Word?

Edit.exe von Microsoft

Welche Tabellenkalkulation gab es vor Excel?

Keine Ahnung, aber da QBasic bei DOS mitgeliefert wurde, konnte man damit schon schön Tabellen ausrechnen lassen. Man mußte halt ein bischen Basic programmieren können.

Welche Datenbanken gab es vor den MS-Produkten?

Das war Adabas.

Und ich kann noch eine Frage beantworten, die du nicht gestellt hast:

Wer hat das Internet erfunden?

Das war Bill Gates.

Mit dem Internet Explorer fingen plötzlich alle Firmen an, im World Wide Web present zu sein.

MS Shareholder schrieb:

Wie ist DOS Entstanden?

Bill Gates hat's programmiert.

okay wenn die erste antwort schon müll ist brauch ich den rest nicht lesen.