Nur Ärger mit Visual C++ ExpressEdition?

benpicco

Hallo, ein Freund von mir, der DSL 6000 hat hat für mich mal das kostenlose MS Visual Studio Expesess Edition 2005 runtergeladen und mir gegeben. Naja, er hatte mir dann auch das DirectX 9 SDK und das .Net SDK runtergeladen, leider hatte er aber das MSSDK vergessen, naja hab ich das ganze mal installiert und erstmal die DirectX 9 Beispiele bestaunt.
Danach wollte ich gleich mal die EE (ExpressEdition) ausprobieren und habe zu diesem Zweck einen Code, den ich mit Dev-Cpp erstellt habe geöffnet. Als er sich nicht compillieren lies, merkte ich, das man dafür erst ein Project anlegen muss, ich wusste zu diesem Zeitpunkt noch nicht, was das Dateimassen mit sich bringt, aber egal...
Ich habe eigentlich erwartet, das ein Code, der vorher funktionierte, das auch jetzt noch tun würde, aber nein...

c:\dev-cpp\programme\prim\prim.cpp(19) : error C2668: 'sqrt': Mehrdeutiger Aufruf einer überladenen Funktion
c:\programme\microsoft visual studio 8\vc\include\math.h(581): kann 'long double sqrt(long double)' sein
c:\programme\microsoft visual studio 8\vc\include\math.h(533): oder "float sqrt(float)"
c:\programme\microsoft visual studio 8\vc\include\math.h(128): oder "double sqrt(double)"
bei Anpassung der Argumentliste '(numTyp)'

o_O, oben im code steht steht typedef unsigned int long long numTyp;
Ich bin verwirrt! Warum ist das mehrdeutig, numTyp ist doch eindeutig unsignet int long long! (Ich versuche gerade C++ zu lernen, daher kenne ich mich damit nicht so wirklich aus...)
Ich hatte noch etwas rumprobiert mit anderen Typen für numTyp, aber als ich z.b. double long verwendete, funktioniert 1. % nicht mehr und es wird 2. ungenau (und es kann 3. nicht sein, das ich ein Programm verändern muss, bloß weil ich den Compiler wechsle, oder?)
Nachdem ich über das nichtfunktinierende Visual Studio gefrustet war, wollte ich erstmal etwas anderes machen, ein Spiel schien mir für diesen Zweck angebracht, ich entschied mich für das gute alte Majesty. Aber der EE schien dieser Entschluss gar nicht zu gefallen, ich erhielt nach kurzer Zeit eine Fehlermeldung:
http://mitglied.lycos.de/benpicco/fehler.jpg
Ich war noch mehr verwirrt! 1. Gab es kein Extras\Optionen\Debuggen in der IDE der EE, 2. sollte die sich eigentlich einen Dreck um die Fehler von Anwendungen scheren, die nicht von ihr compilliert wurden! Nagut dachte ich, also weg mit dem Debugger, ich suchte im Taskmanager nach dem Prozess, der die Fehlermeldung ausgab und killte diesen, stellte sicher, das ich die EE auch wirklich beendet hatte und durchsuchte msconfig nach dem Debugger - ohne großen Erfolg, ich startete das Spiel neu und die selbe Fehlermeldung erschien...
Warum fragt ihr euch, wechsle ich dann überhaupt zur EE, wen ich doch mit Dev zufrieden war? Wegen seltsamen Inkompartiblitätserscheinungen seitens Dev-Cpp! Wollte ich z.b. OpenGL Beispiele starten, kamen nur Fehlermeldungen (das dev eigene Beispiel jedoch funktionierte...), und bei all diesen Beispielen gab es immer irgendwo einen Hinweis, das sie für das Visual Studio wären. Und auch als ich solche includes wie winbase.h oder winnt.h von dev nach EE kopierte (das vergessene MSSDK...), kam es dort nur zu Fehlern...
Gibt es den keinen einheitlichen C++ Standart, an den sich die Compillerprogrammierer halten (müssen/sollen)? Warum gibt es so gravierende Unterschiede und Inkompartiblitätserscheinungen? Für Dev gab es z.b. eigens ein Extra OpenGL Packet zum download, weil das offizielle OpenGL SDK (das zwar modemfreundlich war) anscheinend nicht funktionierte! Wie soll man den da C++ lernen, wen man nichteinmal weiß, ob das beschriebene überhaupt so funktioniert?
Danke schon mal für Antworten und Hilfe.

Christoph

benpicco schrieb:

c:\dev-cpp\programme\prim\prim.cpp(19) : error C2668: 'sqrt': Mehrdeutiger Aufruf einer überladenen Funktion
c:\programme\microsoft visual studio 8\vc\include\math.h(581): kann 'long double sqrt(long double)' sein
c:\programme\microsoft visual studio 8\vc\include\math.h(533): oder "float sqrt(float)"
c:\programme\microsoft visual studio 8\vc\include\math.h(128): oder "double sqrt(double)"
bei Anpassung der Argumentliste '(numTyp)'

o_O, oben im code steht steht typedef unsigned int long long numTyp;

Naja, siehst du irgendwo eine sqrt-Funktion, die den Typ "unsigned int long long" übernimmt? Woher soll dann der Compiler wissen, was du möchtest?

benpicco schrieb:

http://mitglied.lycos.de/benpicco/fehler.jpg

Da hat dein Spiel wohl eine unbehandelte Ausnahme verursacht (AKA abgestürzt). Es ist üblich, dass der beim System angemeldete Debugger in diesem Fall einspringt. Natürlich ist das Spiel von selbst abgestürzt, der Debugger springt erst ein, wenn's schon passiert ist. Deine Meldung besagt, dass du Just-In-Time-Debugging deaktiviert hast (bzw. die Express-Version das gar nicht anbietet, bin mir da nicht sicher). In der Nicht-Express-Version jedenfalls gibt es "Tools->Options->Debugging->Just-In-Time", wo man genau das einstellen kann.

An den C++-Standard muss (sollte) sich schon jeder Compiler-Bauer halten. Nur legt der Standard z.B. nicht die Binärstruktur des kompilierten Codes fest. Zu deinem Beispiel mit OpenGL: Schau dir z.B. einen C++-Compiler für Mikrocontroller an, wie sie in Toastern sind. Deiner Argumentation nach müsste OpenGL darauf unverändert laufen.

groovemaster

benpicco schrieb:

Danach wollte ich gleich mal die EE (ExpressEdition) ausprobieren und habe zu diesem Zweck einen Code, den ich mit Dev-Cpp erstellt habe geöffnet. Als er sich nicht compillieren lies, merkte ich, das man dafür erst ein Project anlegen muss, ich wusste zu diesem Zeitpunkt noch nicht, was das Dateimassen mit sich bringt, aber egal...

Darüber ärgere ich mich auch manchmal. Deshalb mein Tipp, lege dir für jedes grössere Projekt eine entsprechende Verzeichnisstruktur an. Projektdateien in Projektroot, jeweils Unterverzeichnisse für Quellen, Temporaries und Ausgaben. Logfiles kannst du auch ausschalten oder löschen sofern unnötig.

benpicco schrieb:

Ich hatte noch etwas rumprobiert mit anderen Typen für numTyp, aber als ich z.b. double long verwendete, funktioniert 1. % nicht mehr

Was keine grosse Überraschung ist, immerhin ist Ganzzahldivision mit Rest bei Gleitkommazahlen irgendwie unsinnig, oder?

benpicco schrieb:

und es wird 2. ungenau

Genauso wie deine Erklärung hierzu?

benpicco schrieb:

(und es kann 3. nicht sein, das ich ein Programm verändern muss, bloß weil ich den Compiler wechsle, oder?)

Doch, kann schon sein, wenn du vorher fehlerhaften Code hattest und dein Compiler dich jetzt darauf hinweist.

benpicco schrieb:

Nachdem ich über das nichtfunktinierende Visual Studio gefrustet war

Das ist auch so etwas, was ich nicht verstehe. IDE und Compiler sind immer noch zwei unterschiedliche Einheiten. Und du regst dich über die IDE auf, hast bisher aber nur Compilerfehler gebracht.

benpicco schrieb:

Ich war noch mehr verwirrt! 1. Gab es kein Extras\Optionen\Debuggen in der IDE der EE, 2. sollte die sich eigentlich einen Dreck um die Fehler von Anwendungen scheren, die nicht von ihr compilliert wurden! Nagut dachte ich, also weg mit dem Debugger, ich suchte im Taskmanager nach dem Prozess, der die Fehlermeldung ausgab und killte diesen, stellte sicher, das ich die EE auch wirklich beendet hatte und durchsuchte msconfig nach dem Debugger - ohne großen Erfolg, ich startete das Spiel neu und die selbe Fehlermeldung erschien...

Ich bin ehrlich gesagt etwas verwirrt, wahrscheinlich genauso wie du. Was willst du denn mit msconfig bzgl. dem Debugger? Die IDE stellt doch alle Einstellmöglichkeiten selbst zur Verfügung.

benpicco schrieb:

Wollte ich z.b. OpenGL Beispiele starten, kamen nur Fehlermeldungen (das dev eigene Beispiel jedoch funktionierte...), und bei all diesen Beispielen gab es immer irgendwo einen Hinweis, das sie für das Visual Studio wären.

Kann evtl. daran liegen, dass nicht gerade wenige Programmierer immer noch mit veralteten Werkzeugen arbeiten. Dementsprechend fehlerhaft ist auch ihr Code. Dein Beitrag ist ja ein gutes Beispiel hierfür. Aber ohne die Fehlermeldungen zu kennen, kann man da nicht viel zu sagen.

benpicco schrieb:

Und auch als ich solche includes wie winbase.h oder winnt.h von dev nach EE kopierte (das vergessene MSSDK...), kam es dort nur zu Fehlern...

Keine Überraschung. Das Platform SDK ist leider sehr compilerabhängig. MSC Header funktionieren beim GCC deshalb genauso wenig wie GCC Header beim MSC. Das ist aber bei der C++ eigenen Bibliothek (STL) auch nicht anders. Da bringt entweder jeder Compiler seine eigene Implementierung mit. Oder bei allgemeinen Implementierungen werden dann halt Fallunterscheidungen für die diversen Compiler durchgeführt. Für dich als Anwender ist das aber vollkommen irrelevant, denn die Benutzung der zur Verfügung gestellten Typen, Klassen, Funktionen etc. ist immer gleich.

benpicco schrieb:

Gibt es den keinen einheitlichen C++ stan****, an den sich die Compillerprogrammierer halten (müssen/sollen)?

Den gibt es schon. Nur ist der relativ umfangreich und Compilerhersteller brauchen nunmal eine gewisse Zeit, um diesen zu implementieren. ZB gibt es keinen Compiler, der den Standard zu 100% beherrscht (afaik). Zudem ist die Entwicklung eines Compilers ein fortlaufender Prozess. Und fehlerhafter Code der heute funktioniert könnte morgen schon nicht mehr laufen. Deshalb solltest du dich auch nicht zu sehr daran orientieren was der Compiler erlaubt, sondern was der Standard vorschreibt. Und du redest hier auch nicht von Inkompatibilitäten seitens des Standards, sondern von Bibliotheksimplementierungen. Der Standard definiert ja mehr oder weniger nur das Layout, um solch eine Bibliothek zu realisieren. Dh aber nicht, dass es trotzdem gewisse Internas geben kann, die dann ausserhalb des Standards liegen und Inkompatibilitäten hervorrufen können.

Gibt schon Compiler die den Standard zu 100% umsetzen, der Comeau Compiler ist so einer (www.comeaucomputing.com).

@Threadersteller das Visual Studio bzw. Visual C++ ist eine sehr komplexe Entwicklungsumgebung und da muss man sich erst einmal einarbeiten. Vielleicht bist du mit einer kleineren Entwicklungsumgebung für den Anfang besser dran, da deine Projekte auch noch entsprechend klein und überschaubar sind.

Deine genannten Fehler hat nicht Visual C++ zu verantworten sondern du. Wenn du willst, dass man dir hilft, dann poste hier bitte deinen Quellcode und sämtliche Fehlermeldungen.

OpenGL ist im Platform SDK enthalten, welches du dir extra herunterladen musst, da es Visual C++ Express nicht dabei hat (soweit ich weiß, kann mich auch irren). Um das rauszufinden kannst du einfach mal in einem deiner Projekte ein #include <windows.h> reinschreiben und schauen ob er dir einen Fehler bringt, dass er diese Datei nicht finden kann.

Artchi

Platform SDK muß man extra runter laden, steht auch auf der Download-Seite von der Express Edtion bei. Nicht zu übersehen...

benpicco

Na gut, das ich das PSDK auch runterladen muss, wusste ich nicht, ich dachte das wäre alles im ISO Image dabei... (Gibt´s das auch als solches, ohne das man da 16€ Versandkosten zahlen muss? Mit dem modem sind´s, selbst wenn ich nur das Development Enviroment für x84 Prozessoren auswähle, immernoch ein paar 100MB... Und ich hab mich schon über die 1,26mb große exe grefreut...)
Da ich gerade erst mit der EE angefangen habe, hab ich natürlich gleich mal den Fehler auf das geschoben, das neu ist und das man nicht ändern kann - die ExpressEdition eben
Also ist´s mein code der falsch ist, schade, ich hatte gehofft er wäre richtig... Woe kann ich dann aber die Quadratwurzel aus einer 8byte große Int zahl ziehen? (Wobei es hier dann doch eher ums Primzip geht, um zukünftige Fehler zu vermeiden)
Also hier der

#include <cstdlib>
#include <iostream>
#include <math.h>

using namespace std;
typedef unsigned int long long numTyp; // eine 64bit int, max 20 stellen, 

numTyp PrimCheck(numTyp number);
void PrimShow(numTyp number);

numTyp PrimCheck(numTyp number)
{
    numTyp teil=0;
    numTyp x,to;
    if(!(number%2) && number !=2)
    teil=2;
    for(x=3; x<sqrt(number)+1; x=x+2)
    {
             if(!(number%x)) // ungenauigkeiten bei fmod, da bei doubles gerundet wird und z.b. 2^61-1 == 2^61
             {
                            teil=x;
                            break;
             }
    }
    return teil;
}
void PrimShow(numTyp number)
{
     if(!(PrimCheck(number)))
     cout << number <<endl;
     if(!(number%2))
     number++;
     do
     {
                 if(!(PrimCheck(number)))
                 cout << number <<endl;
                 number=number+2;
     }
     while(1);
}

int main(int argc, char *argv[])
{
    numTyp zahl=23;
    numTyp teiler=0;
    cout << "***Primzahlen***\n";
    cout << "(Geben sie 0 ein um alle Primzahlen ab einer Zahl ihrer Wahl anzuzeigen)";
    while(1)
    {
    cout << "\nZahl eigeben:";
    cin >> zahl;
    if(zahl)
    {
    teiler=PrimCheck(zahl);
    if(teiler==0)
    cout << "Primzahl\n";
    else
    {
        cout << "Keine Primzahl\n"; 
        cout << zahl << "=";
        while(teiler=PrimCheck(zahl))
        {    
             cout<<teiler<<"*";    
             zahl=zahl/teiler;                     
        }
        cout<<zahl;
    }
    }
    else
    {
        cout << "Alle Primzahlen ab ";
        cin >> zahl;
        PrimShow(zahl);
    }  

    }
    //system("PAUSE");
    return EXIT_SUCCESS;

Das das Programm sonst auch abgestürtzt wäre, könnte villeicht sein, ist aber schwer festzustellen, daher schloss ich auf´s naheliegende und gab dem neu installierten Visual Studio kurzerhand die Schuld...

benpicco

Gibt es denn keine Möglichkeit für die Modulo Operation und Wurzel aus 8 Byte langen INTs?
Und nochetwas:
Dieses PSDK, ich hab da das hier gefunden:
http://www.microsoft.com/downloads/details.aspx?familyid=D8EECD75-1FC4-49E5-BC66-9DA2B03D9B92&displaylang=en
Aber warum liegt dabei die betonung so auf Server 2003? Ist es das richtige?
The applications you develop with this edition of the SDK can run on the x86, x64 and Itanium-based versions of Windows Server 2003 SP1, Windows XP SP2, Windows XP x64 Pro Edition, and Windows 2000
stimmt mich zwar positiv, aber heißt das das damit programmierte läuft nicht unter 2000 oder 9x?

Artchi

Da der WinServer 2003 das aktuellste MS-OS ist, ist das 2003er PSDK entsprechend das aktuelleste. Logisch, oder?

Die Programme laufen natürlich auch unter Win2000, hast du doch selbst das Zitat gepostet.

The applications you develop with this edition of the SDK can run on the x86, x64 and Itanium-based versions of Windows Server 2003 SP1, Windows XP SP2, Windows XP x64 Pro Edition, and Windows 2000

Dann noch was, ohne das ich mir deinen Code wirklich angeschaut habe, was mir aber gleich auffiel:

typedef unsigned int long long numTyp; // eine 64bit int, max 20 stellen,

Ehm, wer sagt denn, das unsigned int long long in Microsofts Compiler 64 bittig ist? Keiner der nativen C++ Typen im MS-Compiler ist 64 bittig. MS hat eigentlich __int64 eingeführt, als 64 bittigen Typ. Den mußt du typedeffen.

http://msdn2.microsoft.com/en-us/library/cc953fe1.aspx

Artchi

Ehm, sehe gerade in dem von mir geposteten Link:

"long long" Equivalent to __int64.

Blue-Tiger

typedef unsigned int long long numTyp; // eine 64bit int, max 20 stellen,

Muesste das nicht

typedef unsigned long long int numTyp;

heissen, wenn man das "int" unbedingt scheiben will?

benpicco

auch das int hinten ran zu schreiben, oder es ganz wegzulassen oder alles mit __int64 zu ersetzen bringt nichts, scheibar sind für sqrt nur

c:\programme\microsoft visual studio 8\vc\include\math.h(581): kann 'long double sqrt(long double)' sein
c:\programme\microsoft visual studio 8\vc\include\math.h(533): oder "float sqrt(float)"
c:\programme\microsoft visual studio 8\vc\include\math.h(128): oder "double sqrt(double)"

erlaubt...

benpicco

Endlich hab ich das PSDK, ich hab´s auch installiert, aber es funktionieren immer noch keine Windows-Fenster
Ich hab auch schon SetEnv.Cmd ausgeführ, ja ich habe sogar die ganzen dateien aus include und libs des SDKs in die entsprechenden C++ Ordner kopiert - das einzige was ich dafür bekam waren folgende Linking Fehler:

MS VC++ EE schrieb:

------ Build started: Project: API Test, Configuration: Debug Win32 ------
Compiling...
testsrc.cpp
Linking...
testsrc.obj : error LNK2019: Verweis auf nicht aufgelöstes externes Symbol "__imp__ReleaseDC@8" in Funktion ""long __stdcall WndProc(struct HWND__ *,unsigned int,unsigned int,long)" (?WndProc@@YGJPAUHWND__@@IIJ@Z)".
testsrc.obj : error LNK2019: Verweis auf nicht aufgelöstes externes Symbol "__imp__GetTextMetricsA@8" in Funktion ""long __stdcall WndProc(struct HWND__ *,unsigned int,unsigned int,long)" (?WndProc@@YGJPAUHWND__@@IIJ@Z)".
testsrc.obj : error LNK2019: Verweis auf nicht aufgelöstes externes Symbol "__imp__GetDC@4" in Funktion ""long __stdcall WndProc(struct HWND__ *,unsigned int,unsigned int,long)" (?WndProc@@YGJPAUHWND__@@IIJ@Z)".
testsrc.obj : error LNK2019: Verweis auf nicht aufgelöstes externes Symbol "__imp__PostQuitMessage@4" in Funktion ""long __stdcall WndProc(struct HWND__ *,unsigned int,unsigned int,long)" (?WndProc@@YGJPAUHWND__@@IIJ@Z)".
testsrc.obj : error LNK2019: Verweis auf nicht aufgelöstes externes Symbol "__imp__EndPaint@8" in Funktion ""long __stdcall WndProc(struct HWND__ *,unsigned int,unsigned int,long)" (?WndProc@@YGJPAUHWND__@@IIJ@Z)".
testsrc.obj : error LNK2019: Verweis auf nicht aufgelöstes externes Symbol "__imp__TextOutA@20" in Funktion ""long __stdcall WndProc(struct HWND__ *,unsigned int,unsigned int,long)" (?WndProc@@YGJPAUHWND__@@IIJ@Z)".
testsrc.obj : error LNK2019: Verweis auf nicht aufgelöstes externes Symbol "__imp__BeginPaint@8" in Funktion ""long __stdcall WndProc(struct HWND__ *,unsigned int,unsigned int,long)" (?WndProc@@YGJPAUHWND__@@IIJ@Z)".
testsrc.obj : error LNK2019: Verweis auf nicht aufgelöstes externes Symbol "__imp__DefWindowProcA@16" in Funktion ""long __stdcall WndProc(struct HWND__ *,unsigned int,unsigned int,long)" (?WndProc@@YGJPAUHWND__@@IIJ@Z)".
testsrc.obj : error LNK2019: Verweis auf nicht aufgelöstes externes Symbol "__imp__DispatchMessageA@4" in Funktion "_WinMain@16".
testsrc.obj : error LNK2019: Verweis auf nicht aufgelöstes externes Symbol "__imp__TranslateMessage@4" in Funktion "_WinMain@16".
testsrc.obj : error LNK2019: Verweis auf nicht aufgelöstes externes Symbol "__imp__GetMessageA@16" in Funktion "_WinMain@16".
testsrc.obj : error LNK2019: Verweis auf nicht aufgelöstes externes Symbol "__imp__UpdateWindow@4" in Funktion "_WinMain@16".
testsrc.obj : error LNK2019: Verweis auf nicht aufgelöstes externes Symbol "__imp__ShowWindow@8" in Funktion "_WinMain@16".
testsrc.obj : error LNK2019: Verweis auf nicht aufgelöstes externes Symbol "__imp__CreateWindowExA@48" in Funktion "_WinMain@16".
testsrc.obj : error LNK2019: Verweis auf nicht aufgelöstes externes Symbol "__imp__RegisterClassA@4" in Funktion "_WinMain@16".
testsrc.obj : error LNK2019: Verweis auf nicht aufgelöstes externes Symbol "__imp__GetStockObject@4" in Funktion "_WinMain@16".
testsrc.obj : error LNK2019: Verweis auf nicht aufgelöstes externes Symbol "__imp__LoadCursorA@8" in Funktion "_WinMain@16".
testsrc.obj : error LNK2019: Verweis auf nicht aufgelöstes externes Symbol "__imp__LoadIconA@8" in Funktion "_WinMain@16".
C:\Dokumente und Einstellungen\Besitzer\Eigene Dateien\Visual Studio 2005\Projects\API Test\Debug\API Test.exe : fatal error LNK1120: 18 nicht aufgelöste externe Verweise.
Build log was saved at "file://c:\Dokumente und Einstellungen\Besitzer\Eigene Dateien\Visual Studio 2005\Projects\API Test\API Test\Debug\BuildLog.htm"
API Test - 19 error(s), 0 warning(s)
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

Falls es am Code liegen sollte, hier ist der

#include <windows.h>

	LRESULT CALLBACK WndProc (HWND, UINT, WPARAM, LPARAM);

	int WINAPI WinMain (HINSTANCE hInstance, HINSTANCE hPrevInstance,
	                PSTR szCmdLine, int iCmdShow)
	{
	        static char szAppName[] = "HalloWelt";
	        HWND hwnd;
	        MSG msg;
	        WNDCLASS wndclass;

	        wndclass.style = CS_HREDRAW | CS_VREDRAW;
	        wndclass.lpfnWndProc = WndProc;
	        wndclass.cbClsExtra = 0;
	        wndclass.cbWndExtra = 0;
	        wndclass.hInstance = hInstance;
	        wndclass.hIcon = LoadIcon(NULL, IDI_APPLICATION);
	        wndclass.hCursor = LoadCursor(NULL, IDC_ARROW);
	        wndclass.hbrBackground = (HBRUSH) GetStockObject (WHITE_BRUSH);
	        wndclass.lpszMenuName = NULL;
	        wndclass.lpszClassName = szAppName;

	        RegisterClass(&wndclass);

	        hwnd = CreateWindow( szAppName,        // Klassenzugehörigkeit
	             "Das erste Fenster",        // Titelzeile
	             WS_OVERLAPPEDWINDOW,        // Fensterart
	             CW_USEDEFAULT,            // x-Wert der oberen linken Ecke
	             CW_USEDEFAULT,            // y-Wert der oberen linken Ecke
	             CW_USEDEFAULT,            // Breite des Fensters
	             CW_USEDEFAULT,            // Höhe des Fensters
	             NULL,                // Kinderfenster?
	             NULL,                // Menühandle
	             hInstance,                // Handle zur Instanz
	             NULL );                // Parameter zur Weitergabe an WM_PAINT
	        ShowWindow(hwnd, iCmdShow);
	        UpdateWindow(hwnd);

	        while (GetMessage(&msg, NULL, 0, 0))
	        {
	         TranslateMessage(&msg);
	         DispatchMessage(&msg);
	        }
	        return msg.wParam;
	}

	LRESULT CALLBACK WndProc (HWND hwnd, UINT message, WPARAM wParam, LPARAM lParam)
	{
	 HDC hdc;
	 PAINTSTRUCT ps;
	 static int cxChar, cyChar, cxCaps;
	 TEXTMETRIC tm;

	 switch(message)
	 {
	  case WM_CREATE:
	       hdc = GetDC(hwnd);
	       GetTextMetrics (hdc, &tm);
	       cxChar = tm.tmAveCharWidth;
	       cyChar = tm.tmHeight + tm.tmExternalLeading;
	       cxCaps = (tm.tmPitchAndFamily & 1 ? 3 : 2) * cxChar / 2;
	       ReleaseDC(hwnd, hdc);
	       return 0;
	  case WM_PAINT:
	       hdc = BeginPaint(hwnd, &ps);
	       TextOut(hdc, 5*cxChar, 2*cyChar, "Hallo Windows-Welt !", 20);
	       EndPaint(hwnd, &ps);
	       return 0;
	  case WM_DESTROY:
	       PostQuitMessage(0);
	       return 0;
	 }
	 return DefWindowProc (hwnd, message, wParam, lParam);
	}

groovemaster

benpicco schrieb:

ja ich habe sogar die ganzen dateien aus include und libs des SDKs in die entsprechenden C++ Ordner kopiert

Keine gute Idee. Sag der IDE, wo sie nach Headern und Libs zu suchen hat (Tools Options Projects and Solutions VC++ Directories). Alles andere ist Unsinn.

Was die Fehler betrifft, das sind Linkerfehler. Das Kompilieren ansich war erfolgreich. Warum die Fehler auftreten, ist auch schnell erklärt. Irgendwo in deinem Code werden die entsprechenden Funktionen aufgerufen. Damit der Linker das richtig verknüpfen kann, also dass beim Aufruf auch zur entsprechenden Stelle gesprungen wird, muss er wissen, wo die Funktionen definiert sind. Das kannst du der Platform SDK Doku entnehmen. ReleaseDC ist zB in user32.lib zu finden. Und diese Bibliotheken gibst du deinem Linker mit. Project Properties Configuration Properties Linker Input Additional Dependencies

benpicco

Danke! Das funktioniert *juhu*!
Endlich ein funktionstüchtiges Fenster *freu*

P.S.: Gibt es eigendlich auch ne Funktion, die die Libraries automatisch anhand der Befehle einbindet