MinGW manche ausgeführte Dateien lassen sich nicht löschen?
-
Hi
Also, ich habe mit Code::Blocks mit dem MinGW Compiler ein neues Windows Projekt erstellt und ausgeführt, einfach Fenster(genauer hab ichs erst nachher so getestet, aber sorum ist das Problem verständlicher). Danahc problemlos gelöscht, alles kein Problem. Dann habe ich die Sourcecode Datei genommen und mit
C:\MinGW\bin\g++ -c Main.cpp
und
C:\MinGW\bin\g++ -o test Main.o
per Konsole kompiliert, anschließend ausgeführt und siehe da, nach dem ausführen kann ich se nicht mehr löschen oder überschreiben, weil Windows mir den Zugriff verweigert.Dann habe ich noch weitere Tests gemacht und einfach ein leeres Programm(nur Mainmethode) kompiliert, das wiederum ging problemlos, auch eine leere WinMain ging...
jetzt meine Frage, wieso lässt sich das standard WinFenster mit dem selben Compiler nur wenn Code::Blocks es kompiliert wieder entfernen?
edit:
falls jemand das Codeblocks standardding net kennt:#include <windows.h> /* Declare Windows procedure */ LRESULT CALLBACK WindowProcedure (HWND, UINT, WPARAM, LPARAM); /* Make the class name into a global variable */ char szClassName[ ] = "CodeBlocksWindowsApp"; int WINAPI WinMain (HINSTANCE hThisInstance, HINSTANCE hPrevInstance, LPSTR lpszArgument, int nCmdShow) { HWND hwnd; /* This is the handle for our window */ MSG messages; /* Here messages to the application are saved */ WNDCLASSEX wincl; /* Data structure for the windowclass */ /* The Window structure */ wincl.hInstance = hThisInstance; wincl.lpszClassName = szClassName; wincl.lpfnWndProc = WindowProcedure; /* This function is called by windows */ wincl.style = CS_DBLCLKS; /* Catch double-clicks */ wincl.cbSize = sizeof (WNDCLASSEX); /* Use default icon and mouse-pointer */ wincl.hIcon = LoadIcon (NULL, IDI_APPLICATION); wincl.hIconSm = LoadIcon (NULL, IDI_APPLICATION); wincl.hCursor = LoadCursor (NULL, IDC_ARROW); wincl.lpszMenuName = NULL; /* No menu */ wincl.cbClsExtra = 0; /* No extra bytes after the window class */ wincl.cbWndExtra = 0; /* structure or the window instance */ /* Use Windows's default colour as the background of the window */ wincl.hbrBackground = (HBRUSH) COLOR_BACKGROUND; /* Register the window class, and if it fails quit the program */ if (!RegisterClassEx (&wincl)) return 0; /* The class is registered, let's create the program*/ hwnd = CreateWindowEx ( 0, /* Extended possibilites for variation */ szClassName, /* Classname */ "Code::Blocks Template Windows App", /* Title Text */ WS_OVERLAPPEDWINDOW, /* default window */ CW_USEDEFAULT, /* Windows decides the position */ CW_USEDEFAULT, /* where the window ends up on the screen */ 544, /* The programs width */ 375, /* and height in pixels */ HWND_DESKTOP, /* The window is a child-window to desktop */ NULL, /* No menu */ hThisInstance, /* Program Instance handler */ NULL /* No Window Creation data */ ); /* Make the window visible on the screen */ ShowWindow (hwnd, nCmdShow); /* Run the message loop. It will run until GetMessage() returns 0 */ while (GetMessage (&messages, NULL, 0, 0)) { /* Translate virtual-key messages into character messages */ TranslateMessage(&messages); /* Send message to WindowProcedure */ DispatchMessage(&messages); } /* The program return-value is 0 - The value that PostQuitMessage() gave */ return messages.wParam; } /* This function is called by the Windows function DispatchMessage() */ LRESULT CALLBACK WindowProcedure (HWND hwnd, UINT message, WPARAM wParam, LPARAM lParam) { switch (message) /* handle the messages */ { case WM_DESTROY: PostQuitMessage (0); /* send a WM_QUIT to the message queue */ break; default: /* for messages that we don't deal with */ return DefWindowProc (hwnd, message, wParam, lParam); } return 0; }
-
es liegt wohl an der
while (GetMessage (&messages, NULL, 0, 0))
{
/* Translate virtual-key messages into character messages */
TranslateMessage(&messages);
/* Send message to WindowProcedure */
DispatchMessage(&messages);
}
dass ichs beim Konsolenkompilieren nich mehr löschen kann, Sinn macht das ganze für mich trotzdem nicht und ich brauche die Messageloop ja...
-
sind die dateirechte der beiden versionen identisch?
wird die problem-version vllt. nicht richtig beendet?
code-blocks benutzt doch auch nur den gcc... sind die gcc-Parameter identisch zu der manuell kompilierten?