3. Dateigröße der EXE-Reduzieren

Dateigröße der EXE-Reduzieren

  • O

    Hallo
    ich habe ein kleines Konsolentool in C++ gemacht, nichts wildes, nur ca 60 Zeilen.
    Gut ich habe noch Includes dabei.
    Aber trotzdem, die EXE ist 92KByte gross!(Ich hab mit "Release" kompiliert)

    Ich hab mal mit dem Hex-Editor reingeschaut, und da steht viel zu viel Schrott drin. Von den tausend Nullen am ende ganz zu schweigen.
    Der Pfad wo kompiliert wurde steht z.b. auch drin.

    Ja von den EXE Packern ala PKZIP und UPX habe ich schon gehört und benutzt.
    Aber kann man das nicht anders lösen? Mit Kompiler Optionen?

    Ich hab mal die Option "Favor Small Code" angemacht, aber das bringt gar nix.
    😞

    0
  • R

    1. dynamisches Linken aktivieren
    2. Executable strippen, wie das unter Windows geht weiß ich nicht. Du kannst ja man: strip vom mingw oder so benutzen.

    0
  • O

    Reduziert sich die größe auch wenn man Assembler einbaut?

    0
  • R

    Ovaron123 schrieb:

    Reduziert sich die größe auch wenn man Assembler einbaut?

    Assembler Programme sind idr. schon kleiner. Aber der Aufwand steht nicht im Verhältniss.

    0
  • S

    wenns nur 60 zeilen sind kannst dus ja in c schreiben
    die exe is dann in der regel deutlich kleiner

    alles was du dazu bei den meisten c/c++ kompilern machen musst is deine .cpp
    in .c umzubenennen

    darfst dann auch natürlich auch keine stl/klassen... und sonstige c++ erweiterungen verwenden und variablen nur am anfang eines {}-blocks erstellen

    0
  • O

    Nach ein wenig rumprobieren hab ich jetzt bei Visual C++ 7 was seltsames entdeckt:

    Hier mal ein Beispiel Code:

    #include <iostream>
using namespace std;
class B
{
public:
   B() {cout << "B- Constructor 1" << endl;};
   B(int value) {cout << "B- Constructor 2 mit Value:"<< value << endl;};
   ~B(){cout << "Delete Objekt B" << endl;};
   virtual void DoSomething() = 0{cout << "DoSomething BaseClass" << endl;};
};

class A : public B
{
public:
   A(){cout << "A- Constructor 1" << endl;};
   A(int a): B(a){cout << "A- Constructor 2 mit Value:"<< a << endl;};
   ~A(){cout<< "Delete Object A"<<endl;};
   virtual void DoSomething(){cout << "DoSomething Class A"<<endl;};
private:

};
class C: public B
{
public:
	C(){cout << "C- Constructor 1" << endl;};
	C(int a): B(a){cout << "C- Constructor 2 mit Value:"<< a << endl;};
	~C(){cout<< "Delete Object C"<<endl;};
	virtual void DoSomething(){cout << "DoSomething gClass C"<<endl;};
private:

};
int main()
{
   B* pA[3];
   cout << endl;
   cout << endl;
   pA[0] = new A(3);
   cout << endl;
   pA[1] = new C(1);
   cout << endl;
   cout << endl; 
   pA[0]->DoSomething();
   pA[1]->DoSomething();
   cout << endl;
   delete pA[0];
   delete pA[1];
   cout << "End of DELETE[]" << endl;
   return 0;
}

    Wenn ich dies nun mit Visual C++ 7 Compiliere (Microsoft Develop Environement 7.1) kommt eine EXE mit unglaublichen 91kb raus. (Release).
    Geh ich nun in die "Property Pages" von dem Projekt und stelle in
    "Configuration Properties->General->Use of MFC" den Wert von "Use Standard Windows Libraries" auf "Use MFC in a Shared DLL" sind es nur noch 6Kb!! 🙂

    Nun kommt das seltsame: Stell ich den Wert wieder auf "Use Standard Windows Libraries" sind es immr noch 6kb. 😕

    Außerdem verwende ich gar kein MFC. Es ist eine Konsolenanwendung.
    Nun frage ich mach was das soll?? 😕 😕

    0
  • S

    Ovaron123 schrieb:

    Außerdem verwende ich gar kein MFC. Es ist eine Konsolenanwendung.
    Nun frage ich mach was das soll?? 😕 😕

    in den MFC DLLs ist die C++ Runtime drinnen

    0
  • ?

    Bei mir macht der BCC aus einem kleinen Beispielprogramm (paar Zeilen in C, nur
    Konsolen-I/O - das
    vom BCC erzeugte .asm hat nur 3 KByte Größe) stattliche 96 KByte executable.
    Kann man das nicht auch irgendwie reduzieren, ohne dynamische Libraries ?

    0
  • H

    Hallo!

    Schau dir mal upx und Konsorten an, sowas kann deine EXE Files nochmal enorm verkleinern.

    0

  • Ovaron123 schrieb:

    Aber kann man das nicht anders lösen?

    Kauf dir dür 1 € 'nen Rohling, verschiebe einige Daten von HD darauf, du kannst 6000 neue 100k Progs machen.

    Bye, TGGC (Denken, und gut ist.)

    0
  • O

    @Headhunter
    Danke UPX kenn ich. Nettes Tool. Vor allem kann ich mir vorstellen, das Virenprogramme damit Probleme haben.

    Kauf dir dür 1 € 'nen Rohling, verschiebe einige Daten von HD darauf, du kannst 6000 neue 100k Progs machen.

    Solche Kommentare von Leuten mit 19 Beiträgen kann man ignorieren.

    0
  • R

    dotc schrieb:

    Bei mir macht der BCC aus einem kleinen Beispielprogramm (paar Zeilen in C, nur
    Konsolen-I/O - das
    vom BCC erzeugte .asm hat nur 3 KByte Größe) stattliche 96 KByte executable.
    Kann man das nicht auch irgendwie reduzieren, ohne dynamische Libraries ?

    ja, vorallem sollte man besonders umfangreiche Funktionen wie printf vermeiden.

    http://www.fefe.de/dietlibc/diet.pdf (ist teilweise ein bisschen übertrieben, sollte aber einen Einstieg bieten.)

    0
  • C

    Danke UPX kenn ich.

    man sollte natürlich bedenken dass alles was gepackt wurde auch wieder entpackt werden muss. Spätestens bei der Ausführung 😉 und das kostet wiederum Rechenzeit.
    Es gibt noch mehr packer (die auch gleichzeitig debug/disassemblierschutz bieten) und je nach optionen und nach der Art des Programms kann die Perfomance gehörig in die Knie gehen (ich denke gerade an einige Packer die man so einstellen kann (als paranoider Programmierer) dass die den Code wirklich erst vor der Ausführung Blockweise entpacken)).Am besten ist immer noch sich über die Compileroptionen zu informieren und eventuell den ganzen überflüssigen Kram aus der Linker/Compileroption entfernen.

    Vor allem kann ich mir vorstellen, das Virenprogramme damit Probleme haben.

    Nunja, die haben damit wohl die wenigsten Probleme - denn EXE bleibt EXE auch der Packer muss den PE-Format erhalten.

    0
  • G

    es gibt wetbewerbe worum es geht eine gut aussehende grafik demos zu machen die möglicht kein sein soll, aber echt darüber hin ist es wirklich scheiss egal ob die exe 10 oder 100 kb gross ist, noch darüber hinaus erkauft man sich die verkleinerung mit geschwindigkeit einbussen und notwendigen installern (nur wo die mfc dlls installiert sind leuft das programm)

    in c++ gibt es so vieles nützliches zu lernen und du verschendes deine zeit mit sowas,

    0
  • R

    UPX löst vorallem das Problem nicht. Das Programm bleibt ja trotzdem N byte groß. UPX kann man gebrauchen, wenn man wirklich ein begrenztes Speicher-Medium hat (zB. Diskette oder CDROM). Ansonsten ist es schwachsinn das Ding zu benutzen bzw. sogar noch schlimmer.

    @Gerard
    Programmgröße ist nicht unbedingt unwichtig und die Geschwindigkeit kann sogar beschleunigt werden.

    0
  • O

    Have you checked the memory requirements for your program when its compressed? In my experience, applications that have been compressed by exe packers take anywhere between 30% to 500% (yes, five hundred) more memory at runtime. I don't think the memory tradeoff is worth the small exe size.

    Hab ich auch gerade im Netz gefunden.

    Hier ist noch eine andere Möglichkeit um EXE Dateien in VC6 ohne Packer zu verkleinern http://www.coldcity.com/code_tinyexes.asp

    Könnte man aber auch so machen:

    // Make alignments safe for i386 architecture...
#pragma comment(linker, "/FILEALIGN:512")
#pragma comment(linker, "/ALIGN:4096")

    wobei :

    Section Alignment:
    Alignment (in bytes) of sections in RAM when loaded into memory. Must greater or equal to File Alignment. Default is the page size for the architecture.

    File Alignment:
    Alignment factor (in bytes) used to align the raw data of sections in the image file. The value should be a power of 2 between 512 and 64K inclusive. The default is 512. If the SectionAlignment is less than the architecture�s page size then this must match the SectionAlignment.

    0
  • ?

    Ist schon unglaublich, wie die Programmgrößen zugenommen haben in den letzten
    Jahren. Das erste Unix lief auf einer Maschine mit 4K Hauptspeicher, die nächste Version hatte Fortran und war in C geschrieben und lief mit 28 K RAM. In den 70ern waren Basic-Interpreter 2 KByte (Integer Basis) oder 4 KByte (mit Floating Point)
    groß, in den 80ern gab's noch Schackprogramme, die mit 700 Byte Speicher liefen.

    0
  • O

    Ovaron123 schrieb:

    Kauf dir dür 1 € 'nen Rohling, verschiebe einige Daten von HD darauf, du kannst 6000 neue 100k Progs machen.

    Solche Kommentare von Leuten mit 19 Beiträgen kann man ignorieren.

    hrhr böser fehler 😃

    @topic:
    die größe der exe hängt hauptsächlich mit den benutzten headern zusammen, benutzt du <iostream>, linkt dir der compiler normalerweise automatisch die ganze std-lib dazu, dass die borland exe so klein ist liegt daran,dass dein programm die std libs nicht dazu gelinkt hat, und somit unter umständen auf fremd pcs nichtmal startet.

    0
  • ?

    Ovaron123 schrieb:

    @Headhunter
    Danke UPX kenn ich. Nettes Tool. Vor allem kann ich mir vorstellen, das Virenprogramme damit Probleme haben.

    Kauf dir dür 1 € 'nen Rohling, verschiebe einige Daten von HD darauf, du kannst 6000 neue 100k Progs machen.

    Solche Kommentare von Leuten mit 19 Beiträgen kann man ignorieren.

    Man ist aber nicht dazu verplichtet.

    Bye, TGGC (Denken, und gut ist.)

    0
Anmelden zum Antworten