718 kb .exe datei - nur ein Fenster ohne alles o_0

Pelle

Hallo,

habe mich kurz an die winapi gewagt bzw. mit codeblocks ein neues win32 project erstellt et voila fertig ist das fenster: Was mich erschreckte, warum hat das Fenster allein bzw. die .exe datei 718 kb für lumpige 80 zeilen code?? Ich kenne ein Programm das hat 650 kb und ca. 2000 zeilen code mit einem Fenster und ca. 50 Steuerelementen etc.. wie kann das sein?

#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;
}

Jochen Kalmbach

Mit dem MS Compiler ist das kleinste Programm:

// Smallest program:
// Compile with: cl /c /O1 /GS- CPP_VS2005.cpp
// Link with: link /subsystem:console CPP_VS2005.obj kernel32.lib

#include <windows.h>
#pragma comment(linker, "/entry:entry")

void entry()
{
  TCHAR szText[] = TEXT("Hello world\n");
  DWORD dwWritten;
  WriteConsole(GetStdHandle(STD_OUTPUT_HANDLE), szText, lstrlen(szText), &dwWritten, NULL);
}

F:\Test\CPP_VS2005>cl /c /O1 /GS- CPP_VS2005.cpp
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 15.00.21022.08 for 80x86
Copyright (C) Microsoft Corporation.  All rights reserved.

CPP_VS2005.cpp

F:\Test\CPP_VS2005>link /subsystem:console CPP_VS2005.obj kernel32.lib
Microsoft (R) Incremental Linker Version 9.00.21022.08
Copyright (C) Microsoft Corporation.  All rights reserved.

F:\Test\CPP_VS2005>dir *.exe
 Datenträger in Laufwerk F: ist 2ndDrive
 Volumeseriennummer: A8DC-498D

 Verzeichnis von F:\Test\CPP_VS2005

31.12.2007  18:54             2.048 CPP_VS2005.exe
               1 Datei(en)          2.048 Bytes
               0 Verzeichnis(se),  8.531.562.496 Bytes frei

F:\Test\CPP_VS2005>

Also 2.048 Bytes

Und Dein "Window" Programm wird auch nicht erheblich größer werden...

Pelle

Also 2.048 Bytes

Und Dein "Window" Programm wird auch nicht erheblich größer werden...

Das verstehe ich jetzt nicht...

1.) warum würde dein Windows fenster .exe nicht arg viel größe als 2 KB werden wenn du es mit dem VS2005 kompilierst? Warum habe ich das 716 KB zuviel ???

Der GCC kann doch net so schlecht sein? Kannst du mir bitte ein fenster komilieren mit dem MS und mir die größe sagen sonst glaub ichs net dann wünsche ich dir auch einen guten Rutsch ins neue Jahr

36KB mit VS 2008
wahrscheinlich einfach statisches linken ausmachen

Pelle

hgfhf schrieb:

36KB mit VS 2008
wahrscheinlich einfach statisches linken ausmachen

danke dir!

das habe ich gefunden und wundert mich sehr: http://www.activevb.de/rubriken/kolumne/kol_26/cppeffizienz.html

Praxisbelege

Tatsächlich zeigt sich, dass sehr unterschiedliche Sprachen die jeweiligen Testergebnisse anführen, sich C und C++ aber fast immer im vorderen Feld befinden. Wenn man seinen Vergleich auf C und C++ beschränkt, erscheint das Ergebnis zuerst sehr ausgeglichen. Tatsächlich handelt es sich bei Codes, in denen C gewinnt, sowie solchen, in denen die Codes nahezu gleichschnell sind, um Fälle, welche nach einem absolut gleichen Algorithmus ein rein akademisches Problem lösen (mit einer Ausnahme – „cheap concurrency“: Offensichtlich besitzt C eine bessere Bibliothek für Multithreading als C++). Schaut man sich hingegen lediglich die praxisrelevanten Codes an und beachtet zusätzlich auch alternative C++-Lösungen, welche andere Algorithmen verwenden, so ist C++ haushoch überlegen.

stimmt es dass C++ schneller als C ich dachte immer andersrum wegen overhead von c++ etc..

statisches linken finde ich in codeblocks ide nichts dazu? Kannst du es mir zeigen?

ok habe in den einstellungen zum compiler noch ein paar optimierungen vorgenommen nun ist das fenster.exe 7 KB groß

Pelle schrieb:

Offensichtlich besitzt C eine bessere Bibliothek für Multithreading als C++

rofl.

CodeFinder

Pelle schrieb:

stimmt es dass C++ schneller als C ich dachte immer andersrum wegen overhead von c++ etc..

So ist es. Generell sagt man, dass C-Programme schneller sind, da es beispielsweise son Schnickschnack wie VMT's nicht gibt (Ich bevorzuge C++ trotzdem, aber das nur am Rande^^).

Pelle schrieb:

Offensichtlich besitzt C eine bessere Bibliothek für Multithreading als C++

Das ist totaler Schwachsinn, da, wenn Du WinAPI programmierst, Du sowieso die C-Implementierung der Multithreaded-Funktionen verwendest. Generell kann man das eh nicht so verallgemeinern. Des weiteren ist der Vergleich zwischen C und C++ schwierig, da C++ ja C-Code enthalten kann.

Zu Deinem Problem: Es kann, wie bereits angesprochen wurde, u.a. am statischen/dynamischen Linken liegen (wie Du ja auch schon geschrieben hast), aber auch an den Konfigurationseinstellungen des Compilers. In meiner IDE (MS Visual Studio 2005) kann man z.B. zwischen 'Debug' oder 'Release' Modus umstellen: Dies wirkt sich auch stark auf die Größe der Executeable aus . Ferne bietet jeder Compiler meistens noch Optimierungs-Optionen (gerade bezüglich der Executeable-Größe).

Edit: Frohes Neues !

Pelle

...kann man z.B. zwischen 'Debug' oder 'Release' Modus umstellen: Dies wirkt sich auch stark auf die Größe der Executeable aus . Ferne bietet jeder Compiler meistens noch Optimierungs-Optionen (gerade bezüglich der Executeable-Größe).

Edit: Frohes Neues !

richtig ich habe von debug auf release modus umgestellt und dann 7 kb erhalten anstatt 718 kb. Was mich nur wundert, warum hat meine .exe wenn das fenster sichtbar ist also nicht minimiert ganze 560 KB RAM-Verbrauch im task manager? 0,56 MB für 7KB Windows .exe datei??

Pelle schrieb:

0,56 MB für 7KB Windows .exe datei??

es gibt prinzipiell keinen zusammenhang zwischen dateigröße und speicherverbrauch. man kann ein 50 bytes großes programm in assembler schreiben, dass 1 gb arbeitsspeicher belegt. genauso kann eine exe 1 gb groß sein, aber nur einen bruchteil davon an speicher belegen.
der speicher geht in deinem fall wahrscheinlich größtenteils für die runtime library drauf, und für die ganzen dlls die eingebunden werden müssen um ein fenster zu erzeugen.

Martin Richter

Das was Windows alles benötigt ist nicht wenig:
Schau Dir doch mal alleine an, wie große die DLLs sind, die Dein programm noch zusätzlich lädt (DEPENDS.EXE). Wenn Dui nicht statisch gelinkt hast kommt die CRT Runtime DLL dazu.
Dann schau Dir an wie groß der Stack initial ist.
Es wird ein Heap angelegt auch mit einer Grundgröße und die CRT benötigt da auch gleich Speicher.
Einiges an versteckten Kosten liegt z.B. in der Comctl32. die mitz einem entsprechenden XP Manifest auch geladen wird (sofern Du das Projekt mit VS-2005/2008 erzeigt hast).
Weiterer Speciher kommt hinzu für alle Programm die in Deiner Applikation Hook-Dlls installieren (etc. etc.)

Was alles geladen wird kann die DEPENDS auch sagen...

Das ganze leppert sich zusammen.

Pelle

Martin Richter schrieb:

Das was Windows alles benötigt ist nicht wenig:
Schau Dir doch mal alleine an, wie große die DLLs sind, die Dein programm noch zusätzlich lädt (DEPENDS.EXE). Wenn Dui nicht statisch gelinkt hast kommt die CRT Runtime DLL dazu.
Dann schau Dir an wie groß der Stack initial ist.
Es wird ein Heap angelegt auch mit einer Grundgröße und die CRT benötigt da auch gleich Speicher.
Einiges an versteckten Kosten liegt z.B. in der Comctl32. die mitz einem entsprechenden XP Manifest auch geladen wird (sofern Du das Projekt mit VS-2005/2008 erzeigt hast).
Weiterer Speciher kommt hinzu für alle Programm die in Deiner Applikation Hook-Dlls installieren (etc. etc.)

Was alles geladen wird kann die DEPENDS auch sagen...

Das ganze leppert sich zusammen.

also ich includiere in der fenster.exe nur die windows.h datei um das fenster darzustellen. Natürlich habe ich mir die windows.h mal angeschaut und diese DAtei includiert ja weitere files... z.B. sind also alle unten aufgezählten files .dll files? sprich wenn .h dateien compiliert werden nennt man sie .dll dateien? Die ganzen includierten .h files in der windows.h sind diese dafür zuständig, dass meine 7 KB datei auf 560 ca. anschwillt? Kann ich denn aus der window.h datei nicht includes entfernen/auskommentieren die ich nicht benötige?

#include <winresrc.h>
#include <stdarg.h>
#include <windef.h>
#include <wincon.h>
#include <winbase.h>
#include <wingdi.h>
#include <winuser.h>
#include <winnls.h>
#include <winver.h>
#include <winnetwk.h>
#include <winreg.h>
#include <winsvc.h>
#include<ole2.h>
#include <winsock.h>
#include <winsock2.h>
#include <cderr.h>
#include <dde.h>
#include <ddeml.h>
#include <dlgs.h>
#include <imm.h>
#include <lzexpand.h>
#include <mmsystem.h>
#include <nb30.h>
#include <rpc.h>
#include <shellapi.h>
#include <winperf.h>
#include <commdlg.h>
#include <winspool.h>

/*
	windows.h - main header file for the Win32 API

	Written by Anders Norlander <anorland@hem2.passagen.se>

	This file is part of a free library for the Win32 API.

	This library is distributed in the hope that it will be useful,
	but WITHOUT ANY WARRANTY; without even the implied warranty of
	MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

*/
#ifndef _WINDOWS_H
#define _WINDOWS_H
#if __GNUC__ >=3
#pragma GCC system_header
#endif

/* translate GCC target defines to MS equivalents. Keep this synchronized
   with winnt.h. */
#if defined(__i686__) && !defined(_M_IX86)
#define _M_IX86 600
#elif defined(__i586__) && !defined(_M_IX86)
#define _M_IX86 500
#elif defined(__i486__) && !defined(_M_IX86)
#define _M_IX86 400
#elif defined(__i386__) && !defined(_M_IX86)
#define _M_IX86 300
#endif
#if defined(_M_IX86) && !defined(_X86_)
#define _X86_
#elif defined(_M_ALPHA) && !defined(_ALPHA_)
#define _ALPHA_
#elif defined(_M_PPC) && !defined(_PPC_)
#define _PPC_
#elif defined(_M_MRX000) && !defined(_MIPS_)
#define _MIPS_
#elif defined(_M_M68K) && !defined(_68K_)
#define _68K_
#endif

#ifdef RC_INVOKED
/* winresrc.h includes the necessary headers */
#include <winresrc.h>
#else

#include <stdarg.h>
#include <windef.h>
#include <wincon.h>
#include <winbase.h>
#if !(defined NOGDI || defined  _WINGDI_H)
#include <wingdi.h>
#endif
#ifndef _WINUSER_H
#include <winuser.h>
#endif
#ifndef _WINNLS_H
#include <winnls.h>
#endif
#ifndef _WINVER_H
#include <winver.h>
#endif
#ifndef _WINNETWK_H
#include <winnetwk.h>
#endif
#ifndef _WINREG_H
#include <winreg.h>
#endif
#ifndef _WINSVC_H
#include <winsvc.h>
#endif

#ifndef WIN32_LEAN_AND_MEAN
#include <cderr.h>
#include <dde.h>
#include <ddeml.h>
#include <dlgs.h>
#include <imm.h>
#include <lzexpand.h>
#include <mmsystem.h>
#include <nb30.h>
#include <rpc.h>
#include <shellapi.h>
#include <winperf.h>
#ifndef NOGDI
#include <commdlg.h>
#include <winspool.h>
#endif
#if defined(Win32_Winsock)
#warning "The  Win32_Winsock macro name is deprecated.\
    Please use __USE_W32_SOCKETS instead"
#ifndef __USE_W32_SOCKETS
#define __USE_W32_SOCKETS
#endif
#endif
#if defined(__USE_W32_SOCKETS) || !(defined(__CYGWIN__) || defined(__MSYS__) || defined(_UWIN))
#if (_WIN32_WINNT >= 0x0400)
#include <winsock2.h>
/*
 * MS likes to include mswsock.h here as well,
 * but that can cause undefined symbols if
 * winsock2.h is included before windows.h
 */
#else
#include <winsock.h>
#endif /*  (_WIN32_WINNT >= 0x0400) */
#endif
#ifndef NOGDI
/* In older versions we disallowed COM declarations in __OBJC__
   because of conflicts with @interface directive.  Define _OBJC_NO_COM
   to keep this behaviour.  */ 
#if !defined (_OBJC_NO_COM) 
#if (__GNUC__ >= 3) || defined (__WATCOMC__)
#include <ole2.h>
#endif
#endif /* _OBJC_NO_COM */
#endif

#endif /* WIN32_LEAN_AND_MEAN */

#endif /* RC_INVOKED */

#ifdef __OBJC__
/* FIXME: Not undefining BOOL here causes all BOOLs to be WINBOOL (int),
   but undefining it causes trouble as well if a file is included after
   windows.h
*/
#undef BOOL
#endif

#endif

Martin Richter

Du missversehst mich. Ichmeine die DLLs die das System zwangsweise eben mit Deiner Applikation einbindet. Das hat gar nichts mit Deinen Headern zu tun.

Schau Dir doch mal bitte DEPENDS.EXE an!

Die entsprechenden DLLs, di in Deinen Speicher geladne werden sind eben da und notwendig.

Was ist Dein Problem mit 750KB oder mehr oder weniger?

Pelle

Martin Richter schrieb:

Du missversehst mich. Ichmeine die DLLs die das System zwangsweise eben mit Deiner Applikation einbindet. Das hat gar nichts mit Deinen Headern zu tun.

Schau Dir doch mal bitte DEPENDS.EXE an!

Die entsprechenden DLLs, di in Deinen Speicher geladne werden sind eben da und notwendig.

Was ist Dein Problem mit 750KB oder mehr oder weniger?

wenn ich schon C schreibe und nicht java dafür nehme will ich kleine programme coden. Warum hast DU denn ein Problem damit, sollte doch meines sein?? Und nein asm rechtfertigt das Nutzen-/Aufwandsverhältnis nicht... Ich habe alles auf C:\ abgesucht und finde keine depends.exe im speicher ist sie auch nicht geladen, wo ist diese datei?

warum geht der server mehrmals am tag offline? Ich schreibe was wills abschicken und zapp "die site kann icht angezeigt werden" ? Das Problem habe ich nur mit dem c-++.de forum.

Jochen Kalmbach

http://www.dependencywalker.com/

Martin Richter

Ansonsten gehört DEPENDS.EXE zum Lieferumfang von VisualStudio.

Nochmal: Die Größe Deines Programmes hängt einfach auch davon ab, welche DLL's sie verwendet und welchen Speicher die einfach allokieren...

Wnen Du meinst ein JAVA Programm würde weniger Speicher weg nehmen, dann irrst Du Dich. Es ist vieleicht in der Größe der EXE kleiner. Alleridngs wird hier ja auch die ganze Runtime nachgeladen, gleiches gilt für .NET Programe.
Ganz zu Schweigen von deren dynamischen Speicherhunger.

Pelle

Martin Richter schrieb:

Ansonsten gehört DEPENDS.EXE zum Lieferumfang von VisualStudio.

Nochmal: Die Größe Deines Programmes hängt einfach auch davon ab, welche DLL's sie verwendet und welchen Speicher die einfach allokieren...

Wnen Du meinst ein JAVA Programm würde weniger Speicher weg nehmen, dann irrst Du Dich. Es ist vieleicht in der Größe der EXE kleiner. Alleridngs wird hier ja auch die ganze Runtime nachgeladen, gleiches gilt für .NET Programe.
Ganz zu Schweigen von deren dynamischen Speicherhunger.

Ich habe Visual Studio nicht, werde mir aber mal die express version laden mit dem intel compiler um vergleiche mit dem gcc zu haben. Die vergleiche basieren dann auf dem fertig programm natürlich nicht dem leeren fenster

Natürlich sind java programm so fett wegen der runtime siehe task manager java.exe etc. die eigene programm.exe ist ja extra angezeigt, wobei auch die ziemlich fett ist für einen mp3 player den ich nun in C coden möchte. es ist schon ein unterschied ob die mp3.jar 12 mb hat oder 2 mb im RAM , wenn C dann im hinblick auf größe und speed sonst kann ich gleich java nehmen.

Pelle schrieb:

Natürlich sind java programm so fett wegen der runtime

bei c-programmen ist das genauso "natürlich", denn auch die brauchen idR eine laufzeitbibliothek.

und "nur ein fenster ohne alles" ist auch schon eine ganze menge, was den speicherbedarf rechtfertigen kann. möglicherweise legt windows einen pixelbuffer für den inhalt deines fensters im adressraum des prozesses an, und schon sind ein paar hundert k weg. es ist eine übliche strategie, bessere geschwindigkeit durch höheren speicherverbrauch zu erlangen.

schreib dir doch einfach mal ein kleines programm, dass nichts weiter tut als

int main() { while(1); }

und schau, was dabei rauskommt.

außerdem könnte es auch gut sein, dass du nun noch viele tausend zeilen code dazuschreibst ohne dass der speicherverbrauch ansteigt, weil die rtl vielleicht schon im voraus speicher reserviert (reine spekulation).

du solltest dich nicht mit optimierung deines programmes rumschlagen wenn du noch nicht mal angefangen hast zu programmieren. 700 k sind übrigens nicht wirklich beanspruchend für einen modernen computer mit windows.

dmesg

http://www.phreedom.org/solar/code/tinype/

Pelle

dmesg schrieb:

http://www.phreedom.org/solar/code/tinype/

danke!

Mich würde interessieren was du dich um die paar kB Speicher kümmerst. Also heutzutage sind die meisten Computer mit genügend RAM ausgestattet. Du hast keinen Plan für was Headerdateien benötigt werden und weist nicht wie DLLs entstehen, machst dir aber Gedanken wegen der Speicheroptimierung deiner Programme. Dann postest du einen haufern Quellcode den du nicht interpretieren kannst. Vieleicht solltest du ertmal die Grundbegriffe der Programmierung lernen.