[c++] executable-grootte minimaliseren

[Verwijderd]

ik wil een spel maken dat zo klein mogelijk is. ik heb namelijk maar 96Kb om een spelletje in te maken. maar nu vroeg ik me af hoe ik het beste het formaat van mijn executable naar beneden krijg. ik heb op dit moment maar 63 regels aan code maar door alle troep die geinclude word om een windowtje te maken is de exe al bijna 10k. aangezien ik al regelmatig redelijk uitgebreide dingen heb gezien in slechts 4 Kb denk ik toch dat ik wat fout doe

ik heb enkel dit als code:

code:

#include <windows.h>

LRESULT CALLBACK MainWndProc
    (HWND hwnd, UINT message, WPARAM wParam, LPARAM lParam)
{
    switch(message)
    {
    case WM_DESTROY:
                ::PostQuitMessage(0);
        return 0;
    }

    return ::DefWindowProc (hwnd, message, wParam, lParam);
}

int WINAPI WinMain
    (HINSTANCE hInst, HINSTANCE hPrevInst,
     char * cmdParam, int cmdShow)
{
        WNDCLASSEX _class;

        _class.cbSize = sizeof (WNDCLASSEX);
        _class.style = 0;
        _class.lpszClassName = "test";
        _class.hInstance = hInst;
        _class.hIcon = 0;
        _class.hIconSm = 0;
        _class.lpszMenuName = 0;
        _class.cbClsExtra = 0;
        _class.cbWndExtra = 0;
        _class.hbrBackground = reinterpret_cast<HBRUSH> (COLOR_WINDOW + 1);
        _class.hCursor = ::LoadCursor (0, IDC_ARROW);
        _class.lpfnWndProc = MainWndProc;

        
        ::RegisterClassEx(&_class);

        HWND _hwnd;
        _hwnd=::CreateWindowEx(0,"test","test",
            WS_OVERLAPPEDWINDOW | WS_VISIBLE,CW_USEDEFAULT,0,
            CW_USEDEFAULT,0,0,0,hInst,0);

        ::ShowWindow (_hwnd, SW_SHOWNORMAL);
        ::UpdateWindow (_hwnd);

        // The main message loop
        MSG  msg;
        int status;
        while ((status = ::GetMessage (&msg, 0, 0, 0)) != 0)
        {
            if (status == -1)
                return -1;
            ::TranslateMessage (&msg);
            ::DispatchMessage (&msg);
        }


        return msg.wParam;

    return 0;
}

[TheNameless]

Probeer eens een #define WIN32_LEAN_AND_MEAN voordat je windows.h include.
Dit zorgt ervoor dat er minder in de windows.h geinclude wordt.
Misschien scheelt het al iets.

[ Voor 10% gewijzigd door TheNameless op 20-04-2006 10:17 ]

[eghie]

Volgens mij is die windows.h de boosdoener. Deze is geloof ik aardig groot. Vele maken gebruik van kleine header bestanden, die voor een bepaald doel zijn geschreven, zodat ze geen onnodige code erin hebben zitten. Ook kun je je compiler je bestand laten optimaliseren op grootte. En je hebt ook programmatjes die je executable nog kunnen comprimeren, bijvoorbeeld het programma UPX.

[Verwijderd]

@maya, tnx, maar scheelde eigenlijk niets.

@ eghie ik ging eigenlijk ook al vanuit dat ik de headers moest herschrijven. maar daar had ik eigenlijk geen zin in dus hoopte het op een andere manier kleiner te maken.. maarja.. zal anders toch maar moeten gaan prutsen in me headers.

en idd die compressie had ik ook al bedacht, maar natuurlijk hoe minder je mee begint, hoe minder je over houd

[Gonadan]

Voor zover ik weet is windows.h gewoon een header die weer een heleboel andere headers include.
Als je die headers die je daarvan nodig hebt handmatig include dan kan je windows.h en daarmee al die ongebruikte headers weglaten

[Verwijderd]

http://www.google.nl/sear...ndows.h&btnG=Zoeken&meta=

http://www.catch22.net/tuts/minexe.asp

[XTerm]

De grootte van de header maakt niet zoveel uit, wel de dingen waar je standaard tegen linked. Als je van de windows API gebruikt maakt zal je al zowieso tegen MFC dingen moeten linken en de stdlib komt dan ook mee binnen.

Dynamisch of niet, dat kost wel wat aan code size. Als je echt piepklein wil gaan moet je een freestanding binary hebben, dat wil zeggen dat je niet gebruik kan maken van de library calls van de standard C library.

Probeer je ding ook in C ipv in C++ te maken, over het algemeen maken C compilers kleinere binaries.

[farlane]

XTerm schreef op donderdag 20 april 2006 @ 10:45:
Als je van de windows API gebruikt maakt zal je al zowieso tegen MFC dingen moeten linken en de stdlib komt dan ook mee binnen.

Huh? Win32 API != MFC API

Andersom is wel waar, MFC gebruiken betekent ook Win32 gebruiken

[TheBlasphemer]

Ten eerste, de grootte van je header maakt geen donder uit
De header geeft eigenlijk alleen maar aan waar bepaalde dingen te vinden zijn, en aangezien dr geen echte code inzit, zie je er ook niks van terug in je executable size.
Wat je wel terugziet in je exe is alle libraries die meegelinked zijn. Standaard gooit C++ allerlei wrappers om je main functie heen, die nodig zijn voor de standaard zooi (zoals std:: zooi, of functies als printf).
Als je dat weg wilt halen moet je eerst bij de linker "Ignore default libraries" ofzo uitzetten, vervolgens je entry point zetten naar je Main functie.
Als je dan nog dingen naar bijv console wilt printen, gebruik dan de pure Win32 functies, zoals CreateFile, ReadFile, WriteFile, etc

Als laatste als je echt miereneukerig wilt zijn kun je dem alignment nog veranderen. Standaard wordt elke exe ge-'aligned' op 4kb, dit betekent dat als je exe grootte niet deelbaar is door 4kb, dr wat null-bytes achteraan worden geplakt
Dit kun je ook nog weg krijgen, is een linker switch, maar weet niet meer precies welke.

Als je echt van die die-hard 4kb exes wilt maken zul je C++ weg moeten gooien, dat lukt je gewoon niet In dat geval zou ik eens ASM leren

[Gonadan]

TheBlasphemer schreef op donderdag 20 april 2006 @ 11:32:
Ten eerste, de grootte van je header maakt geen donder uit
De header geeft eigenlijk alleen maar aan waar bepaalde dingen te vinden zijn, en aangezien dr geen echte code inzit, zie je er ook niks van terug in je executable size.

Ben ik nou gek of zitten er in headers ook vaak een hele stapel declaraties van constanten?

[TheBlasphemer]

Gonadan schreef op donderdag 20 april 2006 @ 11:33:
[...]

Ben ik nou gek of zitten er in headers ook vaak een hele stapel declaraties van constanten?

Klopt, maar zolang je ze niet gebruikt wordt er niks mee gedaan...
Meeste constanten in de win32 headers zijn overigens toch #define's, en die worden niet eens meegecompiled, #define's zijn meer een soort "Search-and-replace"ers
"#define x y" doet eigenlijk niks anders dan de compiler vertellen "Als je ergens X ziet moet je dr lekker Y van maken"

[marcelk]

TheBlasphemer schreef op donderdag 20 april 2006 @ 11:37:
[...]


Klopt, maar zolang je ze niet gebruikt wordt er niks mee gedaan...
Meeste constanten in de win32 headers zijn overigens toch #define's, en die worden niet eens meegecompiled, #define's zijn meer een soort "Search-and-replace"ers
"#define x y" doet eigenlijk niks anders dan de compiler vertellen "Als je ergens X ziet moet je dr lekker Y van maken"

Dat is de taak van de preprocessor, niet van de compiler zelf.

[ Voor 6% gewijzigd door marcelk op 20-04-2006 11:57 ]

[Soultaker]

Misschien ten overvloede, maar de compiler kan zelf meestal ook optimaliseren voor ruimte. Dat scheelt allicht een paar bytes.

Verder is het bepalend welke functies uit de standard library gebruikt worden. Bedenk ook dat die standard library bij het opstarten dingen doet, wat code toevoegt. Ik denk dat de grootte van je executable dus vooral bepaald wordt door die standard library en dat de kleinste programma's die helemaal niet gebruiken, omdat ze geschreven zijn in assembly en alleen de Win32 API gebruiken.

[.oisyn]

In assembly hoeft niet per se, LIBCTINY is wel handig though
http://msdn.microsoft.com/msdnmag/issues/01/01/hood/

[MSalters]

LIBCTINY werkt voortreffelijk, autorun.exe ermee gebakken van 3K. En dat is "met windows.h included", wat zoals TheBlasphemer terecht zegt dus geen bal uitmaakt.

[Rmg]

Je kan je ook nog eens met upx je executable gaan inpakken scheelt vaak ook een hoop http://upx.sourceforge.net/

[Thralas]

Qua packers is WinUpack (of http://upo.mathesoft.de/, maar daar heb ik geen ervaring mee) een van de beste qua output filesize.