Native Windows-Programme mit gcc/g++?

[Marc Reichelt]

Hallo an alle,

ein Freund und ich möchten uns ein wenig mit C/C++ vertraut machen.
Hierzu wollen wir erst mal auf der Konsole beginnen, um dann später ein kleines Spiel mit SDL zu verwirklichen.
In der Anfangsphase gibt es keine Probleme - er nutzt Cygwin unter Windows, und ich benutze Linux.
Nun habe ich kurz den g++ unter Windows mit folgendem C++-Code ausgetestet:

#include <iostream>  
  
int main() {  
 std::cout << "Hello World!" << std::endl;  
 return 0;  
}

Ein simples "g++ -o helloworld.exe helloworld.cpp" fördert nun eine "helloworld.exe" zu Tage, die 466 kB groß ist und nur in Cygwin läuft.
466 kB sind etwas groß für meinen Geschmack, was macht der g++ denn da?

Wird diese EXE in einem normalen DOS-Fenster aufgerufen, beschwert sich Windows, dass keine "cygwin1.dll" gefunden werden konnte. Wenn ich mir diese Datei heraussuche und in den gleichen Pfad kopiere wie die EXE-Datei, läuft das Programm auch im DOS-Fenster.

Wie bringe ich g++ bzw. gcc dazu, native Windows-Programme zu erstellen, die ohne die cygwin1.dll funktionieren? Oder wird diese DLL immer benötigt? Wie sieht es aus, wenn das Spiel irgendwo zum Herunterladen angeboten wird?

Und wie bringe ich später die SDL zum Laufen, sowohl unter Windows als auch unter Linux?

Grüße

Marc Reichelt || http://www.marcreichelt.de/

[Vinzenz Mai]

Hallo Marc,

In der Anfangsphase gibt es keine Probleme - er nutzt Cygwin unter Windows, und ich benutze Linux.

da beginnen bereits die Probleme. Cygwin ist _nicht_ Windows. Deine Programme sind _keine_ nativen Windowsprogramme.

Wie bringe ich g++ bzw. gcc dazu, native Windows-Programme zu erstellen, die ohne die cygwin1.dll funktionieren? Oder wird diese DLL immer benötigt?

Nein, Du könntest die MinGW-Version des GCC benutzen.

Nur ein kleiner Hinweis, der nichts direkt mit Deiner Anfrage zu tun hat:
Die Windows-Version von apache wird mit Visual C++ übersetzt (ok, man kann sie auch mit Borland oder sonstwas kompilieren, solange man sich die Mühe macht, sich die notwendigen Bibliotheken zu besorgen.

Außerdem weißt Du bestimmt, dass die Express-Editionen von Visual C++, Visual Basic, ... kostenlos sind.

Freundliche Grüße

Vinzenz

[Christoph Schnauß]

hallo Vinzenz,

Außerdem weißt Du bestimmt, dass die Express-Editionen von Visual C++, Visual Basic, ... kostenlos sind.

Die Seite gibts auch in deutscher Sprache.

Grüße aus Berlin

Christoph S.

[Marc Reichelt]

Hallo Vinzenz,

In der Anfangsphase gibt es keine Probleme - er nutzt Cygwin unter Windows, und ich benutze Linux.

da beginnen bereits die Probleme. Cygwin ist _nicht_ Windows. Deine Programme sind _keine_ nativen Windowsprogramme.

Aber zunächst reicht es ja für uns beide, eine gleiche Umgebung zu haben, in der wir C++-Programme schreiben, kompilieren und ausführen können.

Nur ein kleiner Hinweis, der nichts direkt mit Deiner Anfrage zu tun hat:
Die Windows-Version von apache wird mit Visual C++ übersetzt (ok, man kann sie auch mit Borland oder sonstwas kompilieren, solange man sich die Mühe macht, sich die notwendigen Bibliotheken zu besorgen.

Außerdem weißt Du bestimmt, dass die Express-Editionen von Visual C++, Visual Basic, ... kostenlos sind.

Das wusste ich bisher nicht. Ich habe mir damals (ziemlich lange her...) eine Student Editition von Microsoft gekauft, die Visual Basic und unter anderem auch Visual C++ enthielt. Mit Visual Basic habe ich damals gearbeitet (bzw. gespielt), Visual C++ hatte ich nur kurz ausgetestet.

Wenn Visual C++ für Windows die beste Lösung ist, dann werde ich es wohl demnächst mal austesten. Ich wünsche mir seit längerem, zu verstehen, warum die meisten Spiele nur für Windows geschrieben werden. DirectX ist dabei natürlich der triftigste Grund, aber ich fragte mich, warum nicht beispielsweise SDL verwendet wird. Wenn ich mir die Probleme mit den Compilern ansehe, dann wird mir auch schnell klar, warum die meisten Spieleentwickler nur für eine Plattform entwickeln.

Grüße

Marc Reichelt || http://www.marcreichelt.de/

[OhneName]

Hallo Marc,

der Grund warum die meißten Programme nur für eine Plattform entwickelt werden ist nicht weil man das Programm auf beiden Plattformen kompilieren müsste, sondern das nicht jede Library auf jeder Plattform funktioniert.

Beispiel 3D-Spiele:
Es gibt 2 große APIs (Application Programming Interface) für 3D-Spiele. DirectX und OpenGL, DirectX funktioniert nur auf Windows. Wer ein Spiel in DirectX entwickelt kann es also nur an Windows-Benutzer verkaufen. Für Benutzer anderer Plattformen müsste er es unter Verwendung von OpenGL komplett neu entwickeln.

Der Grund warum nur wenige Spiele SDL verwenden ist, dass DirectX bereits Möglichkeiten für Sound und Eventhandling beinhaltet, man hat also alle Funktionen die SDL bietet bereits. Unter den Spielen, die OpenGL verwenden sind dagegen auch viele dabei die SDL für die Sachen nutzt, die OpenGL nicht bietet.

Die Wahl ist also entweder DirectX (evtl. mit WinAPI oder MFC) oder OpenGL mit SDL (bzw. andere Libraries, die ähnliche Funktionen bereitstellen), wenn man plattformunabhängig bleiben will.

Gruss,
OhneName

[Mathias Brodala]

Hallo OhneName.

Es gibt 2 große APIs (Application Programming Interface) für 3D-Spiele. DirectX und OpenGL, DirectX funktioniert nur auf Windows.

Wobei DirectX noch „ein bisschen mehr“ als eine 3D–API ist. Du müsstest Direct3D mit OpenGL vergleichen, da DirectX eine umfangreiche Multimedia–Suite mit diversen Schnittstellen und Aufgabenbereichen ist.

Wer ein Spiel in DirectX entwickelt kann es also nur an Windows-Benutzer verkaufen.

Projekte wie Cedega, WineX und WINE selbst unternehmen hiergegen etwas und kommen augenscheinlich auch gut voran. Zumindest sind viele gute Spiele hiermit auch unter nicht–Windosen lauffähig.

Für Benutzer anderer Plattformen müsste er es unter Verwendung von OpenGL komplett neu entwickeln.

Da stellt sich natürlich die Frage: Warum nicht von Anfang an nachgedacht und gleich mit Hilfe des plattformunabhängigen OpenGL entwickelt? Eine mögliche Antwort ist — soweit ich dies verstanden habe — dass man in OpenGL vieles noch selbst implementieren muss/kann/darf, wohingegen Direct3D vieles in vorgefertigter Form bereitstellt. Dass letzteres für Entwickler attraktiver erscheint und da auch gerne die Plattformunabhängigkeit zurückgestellt wird, kann man in gewissem Maße nachvollziehen. Nichtsdestotrotz gibt es gute OpenGL–basierte Rendering–Engines; man ist nicht zwangsläufig auf Direct3D angewiesen.

Einen schönen Samstag noch.

Gruß, Mathias

[OhneName]

Hallo Ashura/Mathias

Es gibt 2 große APIs (Application Programming Interface) für 3D-Spiele. DirectX und OpenGL, DirectX funktioniert nur auf Windows.

Wobei DirectX noch „ein bisschen mehr“ als eine 3D–API ist. Du müsstest Direct3D mit OpenGL vergleichen, da DirectX eine umfangreiche Multimedia–Suite mit diversen Schnittstellen und Aufgabenbereichen ist.

Da hast du natürlich recht, ich hab aber ja auch ein bisschen später in dem Post noch gesagt, dass DirectX noch einiges mehr beinhaltet als nur 3D-Grafik.

Wer ein Spiel in DirectX entwickelt kann es also nur an Windows-Benutzer verkaufen.

Projekte wie Cedega, WineX und WINE selbst unternehmen hiergegen etwas und kommen augenscheinlich auch gut voran. Zumindest sind viele gute Spiele hiermit auch unter nicht–Windosen lauffähig.

Da hast du natürlich auch Recht, aber meinst du die Softwarefirma würde ein DirectX/WinAPI/MFC-Programm auch an Benutzer anderer Systeme verkaufen mit dem Hinweis "Benutzen sie bitte WINE für unser Programm!"? Imho kann man für ein Programm für das man erst noch ein anderes Programm braucht nicht wirklich Geld verlangen. Da hätte man sich ja einen schönen Brocken Arbeit in Bezug auf die Cross-Plattform-Entwicklung gespart und der Benutzer hat dann das Problem, wenn mit WINE irgendeine DirectX-Sonderfunktion nicht funktioniert.

Für Benutzer anderer Plattformen müsste er es unter Verwendung von OpenGL komplett neu entwickeln.

Da stellt sich natürlich die Frage: Warum nicht von Anfang an nachgedacht und gleich mit Hilfe des plattformunabhängigen OpenGL entwickelt? Eine mögliche Antwort ist — soweit ich dies verstanden habe — dass man in OpenGL vieles noch selbst implementieren muss/kann/darf, wohingegen Direct3D vieles in vorgefertigter Form bereitstellt. Dass letzteres für Entwickler attraktiver erscheint und da auch gerne die Plattformunabhängigkeit zurückgestellt wird, kann man in gewissem Maße nachvollziehen. Nichtsdestotrotz gibt es gute OpenGL–basierte Rendering–Engines; man ist nicht zwangsläufig auf Direct3D angewiesen.

Meines Wissens haben Direct3D und OpenGL einen ähnlichen Funktionsumfang. Der Unterschied ist aber nunmal, dass DirectX all die anderen wichtigen Sachen wie Sound, Eventhandling, etc. gleich mit dabei hat, während man bei OpenGl da erst einmal andere Libraries wie SDL, GLUT oder OpenAL benötigt.

In Anbetracht des Marktanteils von Windows, ist es aber auch verständlich, dass die Plattformunabhängigkeit noch einen recht geringen Stellenwert bei der Wahl der 3D-API hat.

Einen schönen Samstag noch.

Gruß, Mathias

Danke, dir auch,
OhneName

[Mathias Brodala]

Hallo OhneName.

Wobei DirectX noch „ein bisschen mehr“ als eine 3D–API ist. Du müsstest Direct3D mit OpenGL vergleichen, da DirectX eine umfangreiche Multimedia–Suite mit diversen Schnittstellen und Aufgabenbereichen ist.

Da hast du natürlich recht, ich hab aber ja auch ein bisschen später in dem Post noch gesagt, dass DirectX noch einiges mehr beinhaltet als nur 3D-Grafik.

Ich weiß, ich war zu faul, das ganze nochmal zu löschen. Außerdem ist der verlinkte Vergleich recht lesenswert.

[…] meinst du die Softwarefirma würde ein DirectX/WinAPI/MFC-Programm auch an Benutzer anderer Systeme verkaufen mit dem Hinweis "Benutzen sie bitte WINE für unser Programm!"?

Nein, ganz gewiss nicht. In diese Richtung sollte meine Anmerkung auch nicht gehen. Ich wollte eher andeuten, dass auch nicht–Windows–Nutzer DirectX–basierte Spiele kaufen, wenn sie in Aussicht haben, dass diese auf ihrem System lauffähig sind.

Meines Wissens haben Direct3D und OpenGL einen ähnlichen Funktionsumfang.

Dem widerspreche ich nicht, aber eine ähnliche Funktionalität bzgl. der Bedienung?

In Anbetracht des Marktanteils von Windows, ist es aber auch verständlich, dass die Plattformunabhängigkeit noch einen recht geringen Stellenwert bei der Wahl der 3D-API hat.

Ja, leider. Ich hoffe innigst, dass sich dies in Zukunft bessert.

Einen schönen Samstag noch.

Danke, dir auch,

Danke.

Gruß, Mathias

[OhneName]

Hallo Mathias

Meines Wissens haben Direct3D und OpenGL einen ähnlichen Funktionsumfang.

Dem widerspreche ich nicht, aber eine ähnliche Funktionalität bzgl. der Bedienung?

Ich bin mit meinen Programmierfähigkeiten noch nicht so weit, dass ich mich an 3D-Grafik heranwage. Nachdem ich mühevoll C++ gelernt habe, versuche ich mich lieber doch erst an der einfacheren 2D-Grafik mit Hilfe des SDL, einer echt tollen Library für diese Aufgabe. Aber ich habe desöfteren schon gelesen, dass DirectX in einem objektorienterten C-Stil geschrieben ist, im Gegensatz zu OpenGl, was vielleicht dem ein oder anderen Programmierer besser oder schlechter gefällt. Das halte ich aber nicht für eintscheidend.

Wer weiß schon was sich die Chefs dieser Spieleentwicklungsfirmen denken bei der Wahl der 3D-API. Ich versteh ja auch nicht, warum ein Betriebssystem marktführend ist obwohl es deutlich bessere und preiswertere Alternativen gibt. Vielleicht hängt es einfach mit der verwendeten Engine zusammen, die in vielen Fällen DirectX verwendet. Oder es ist wie so häufig in dieser Welt das Geld das am Ende den Ausschlag gibt.

Gruss,
OhneName

[Der Martin]

Hallo Vinzenz,

Die Windows-Version von apache wird mit Visual C++ übersetzt (ok, man kann sie auch mit Borland oder sonstwas kompilieren, solange man sich die Mühe macht, sich die notwendigen Bibliotheken zu besorgen.

das bringt mich auf die Frage: Was für Bibliotheken? Ich habe bisher angenommen, die Sourcen des Apache seien vollständig in dem Sinn, dass kein zusätzlicher Programmcode mehr gebraucht wird. Irre ich mich da?
Ich habe zwar bisher noch nicht versucht, Apache/Win32 selbst zu übersetzen, wohl aber aus technischem Interesse mal darüber nachgedacht. Als Besitzer und überzeugter Nutzer von Borland C++ hätte ich es selbstverständlich mit diesem Compiler versucht, auch auf die Gefahr hin, dass ich einige Compiler-Direktiven und Spleens anpassen müsste.

Wenn du nun sagst, dass dazu noch zusätzliche Bibliotheken nötig sind, dann bedeutet das ja, dass die Win32-Binaries "mehr" umfassen, als im Sourcecode enthalten ist. Bitte etwas konkreter.

Außerdem weißt Du bestimmt, dass die Express-Editionen von Visual C++, Visual Basic, ... kostenlos sind.

Ja, aber die Visual-Studio-Komponenten nisten sich an so vielen Stellen unangenehm tief ins System ein, dass ich sie gern von meinem PC fernhalte.

Schönen Abend noch,
 Martin

[Vinzenz Mai]

Hallo Martin,

Die Windows-Version von apache wird mit Visual C++ übersetzt (ok, man kann sie auch mit Borland oder sonstwas kompilieren, solange man sich die Mühe macht, sich die notwendigen Bibliotheken zu besorgen.

das bringt mich auf die Frage: Was für Bibliotheken? Ich habe bisher angenommen, die Sourcen des Apache seien vollständig in dem Sinn, dass kein zusätzlicher Programmcode mehr gebraucht wird. Irre ich mich da?

Du brauchst auf jeden Fall das "Windows Platform SDK" von Microsoft - und ob es mit Borland überhaupt klappt, scheint fraglich zu sein. Die offizielle Doku erwähnt ausschließlich Visual C++ 5.0 oder neuer.

Freundliche Grüße

Vinzenz

[Der Martin]

n'Abend Vinzenz,

Du brauchst auf jeden Fall das "Windows Platform SDK" von Microsoft ...

ach, _das_! Ja, natürlich - aber daraus auch nur die große Sammlung an Headerdateien. Die zugehörigen Importbibliotheken kann man sich dann aus den Windows-DLLs selbst generieren. Kenn ich vom Prinzip her.

und ob es mit Borland überhaupt klappt, scheint fraglich zu sein.

Ob es im Fall von Apache läuft, kann ich nicht mit Bestimmtheit sagen - aber das Platform SDK lässt sich grundsätzlich auch mit dem Borland-Compiler verwenden. Ja, okay - es ist natürlich auf MSVC "optimiert", dadurch kann es immer mal wieder zu Errors beim Compilieren kommen. Aber in solchen Fällen muss man eben die entsprechende Headerdatei hernehmen und die eine oder andere Direktive von Microsoft- in Borland-Syntax umschreiben.
Mit ein paar kleineren Projekten habe ich das schon erfolgreich praktiziert.

Die offizielle Doku erwähnt ausschließlich Visual C++ 5.0 oder neuer.

Ja, das heißt aber nichts anderes, als dass für diese Versionen alles passend voreingestellt ist. Mit anderen Compilern muss man halt etwas Handarbeit leisten. Bei einem so umfangreichen Projekt wie dem Apache Webserver artet das wirklich in Arbeit aus - aber wenn man da mal ein Wochenende investiert, kriegt man das auch hin.

So long,
 Martin

[OhneName]

Hallo Marc,

C++ und SDL sind eine schöne Wahl, damit arbeite ich auch zur Zeit. Ich habe mich zwar noch nicht so viel mit Cross-Plattform-Entwicklung beschäftigt, aber ich versuche dir trotzdem ein wenig zu helfen.

Da Linux und Windows ein unterschiedliches Format für ausführbare Dateien haben musst du deinen Quelltext sowieso einmal für Windows und einmal für Linux kompilieren. Da kommst du nicht drumherum. Es ist aber glaube ich möglich auf Windows das Programm für Linux zu kompilieren, aber dann funktioniert's halt nicht auf Windows.

Wenn du dein Programm für Windows kompilieren willst, dann brauchst du auch einen Compiler, der dir die richtigen Programme erstellt. Dazu eignet sich am besten der Windows-Port des g++, besser bekannt als MinGW. Am besten benutzt du zur Entwicklung auch gleich eine richtige IDE, die vereinfacht das Kompilieren und Linken ganz erheblich. Empfehlen kann ich da Code::Blocks. Nimm aber einen Nightly Build, die sind deutlich aktueller und fast genau so stabil wie der letzte Release Candidate.

Wenn du den g++ unter Windows laufen hast ist es ja klar, dass er dir ein Linux-Programm erstellt, für dessen Ausführung du wiederum Cygwin benötigst. Also nicht geeignet für Leute, die kein cygwin haben.

Wenn du für deine Programme später SDL benutzt, dann linkst du erstmal die SDL-Libraries dazu. Der Windows-Benutzer benötigt zur Ausführung dann die SDL.dll, der Linux-Benutzer die entsprechende Lib für Linux.

Also so ganz einfach wie du dir das gedacht hast ist es halt doch nicht :-)

Gruss,
OhneName

[seth]

gudn tach!

Wenn du dein Programm für Windows kompilieren willst, dann brauchst du auch einen Compiler, der dir die richtigen Programme erstellt. Dazu eignet sich am besten der Windows-Port des g++, besser bekannt als MinGW. Am besten benutzt du zur Entwicklung auch gleich eine richtige IDE, die vereinfacht das Kompilieren und Linken ganz erheblich. Empfehlen kann ich da Code::Blocks. Nimm aber einen Nightly Build, die sind deutlich aktueller und fast genau so stabil wie der letzte Release Candidate.

code::blocks kenne ich nicht, aber auf bloodshed dev-c++ kann ich noch hinweisen. ein open-source-ide, das auf dem gcc von mingw basiert.

Wenn du den g++ unter

ich ergaenze sichrheitshalber: "[...g++ unter] cygwin unter [windows...]"

Windows laufen hast ist es ja klar, dass er dir ein Linux-Programm erstellt, für dessen Ausführung du wiederum Cygwin benötigst.

noch ein wort zum visual-kram: die anforderungen an die hardware bei ms-visual-zeugs sind sehr hoch. die vielen hundert MB freier platz sind da u.a. zu nennen. vermutlich ist fast jedes andere ide hardware-anspruchsloser.
und der einfache gcc (also ohne ide) laeuft ja sogar auf gurkenschaelern.

prost
seth

[Marc Reichelt]

Hallo seth,

code::blocks kenne ich nicht, aber auf bloodshed dev-c++ kann ich noch hinweisen. ein open-source-ide, das auf dem gcc von mingw basiert.

Sieht interessant aus, ich werde die IDE gleich heute Abend zusammen mit meinem Kollegen austesten. :-)

Grüße

Marc Reichelt || http://www.marcreichelt.de/

[OhneName]

Hallo Marc

code::blocks kenne ich nicht, aber auf bloodshed dev-c++ kann ich noch hinweisen. ein open-source-ide, das auf dem gcc von mingw basiert.

Sieht interessant aus, ich werde die IDE gleich heute Abend zusammen mit meinem Kollegen austesten. :-)

Dev-Cpp habe ich am Anfang auch benutzt und ist imho auch ganz brauchbar. Wichtig für euch könnte aber der Abschnitt "System : Windows 95/98/NT/2000/XP" sein. http://www.codeblocks.org/ ist dagegen problemlos auch auf Linux nutzbar. Desweiteren ist C::B nicht an den MinGW-Compiler gebunden, sondern funktioniert mit jedem bekannten Compiler zusammen.

An eurer Stelle würde ich einfach mehrere IDEs ausprobieren und dann entscheiden welche euch am besten gefällt.

Gruss,
OhneName

PS: Bei code::blocks unbedingt einen Nightly Build aus dem Forum nutzen, der letzte Release Candidate ist schon ziemlich alt.

[Marc Reichelt]

Hallo OhneName,

Dev-Cpp habe ich am Anfang auch benutzt und ist imho auch ganz brauchbar. Wichtig für euch könnte aber der Abschnitt "System : Windows 95/98/NT/2000/XP" sein. http://www.codeblocks.org/ ist dagegen problemlos auch auf Linux nutzbar. Desweiteren ist C::B nicht an den MinGW-Compiler gebunden, sondern funktioniert mit jedem bekannten Compiler zusammen.

Das wäre erst mal nicht problematisch, wir sollten beide nur zwei Umgebungen (eventuell auch unterschiedliche Umgebungen) haben, in denen wir den gleichen Code kompilieren können. Am Besten wäre natürlich auch, wenn das Makefile ebenfalls unverändert auf beiden Systemen funktioniert. Na mal sehen, heute Abend legen wir los... :-)

Grüße

Marc Reichelt || http://www.marcreichelt.de/