.exe Dateigröße

[Counter909]

HI


also hab ich etwas programmiert und meine .exe ist am Ende 580Kb groß, doch finde ich
dass es i.wie vielzu groß ist, weil ich kein Form mehr besitze, sondern nur noch Code. Wenn ich jetzt ein neues Projekt mache, nur mit Code (.pas) dann ist sie höchstens einpaar Kbs groß)
Am Anfang hatte ich um zu testen noch eine Form1 eingefügt mit Button und so zum testen, aber
habe sie dann entfernt , aber die Größe ist jetzt trotzdem so groß geblieben.

Ich hab das Gefühl, dass i-wo noch sachen im projekt gespeichert sind, die viele Kbs schlucken ^^
hat vllt einer eine Idee ?

[SirThornberry]

du wirst einfach weiterhin die units wie forms und sysutils eingebunden haben und die enhalten nunmal viel

[Counter909]

also wenn ich die systutils wegnehmen, dann erkennt er sowas wie " inttostr" nicht mehr

die Forms konnte ich wegnehmen, allerdings Größe ist wie gehabt :-(

[1234588]

funktionen wie IntToStr() kannst du mit Str() nachbasteln, StrToInt() mit Val() etc.
das kleinstmoegliche programm ist imho

Delphi-Quellcode:

begin
end.

arg viel kleiner wird es ohne groeßere umwege nicht gehn.

[Nils_13]

Brauchst du denn eine Oberfläche ? Ansonsten würde es genügen einfach mit einer Konsolenanwendung zu arbeiten. So wie du das beschrieben hast, brauchst du immer noch einen Button. Dies ließe sich via NonVCL erreichen, allerdings ist das nicht so gut falls du mal was zusammen mit FreePascal und/oder Lazarus für z.B. Linux machen willst. Es gibt ein Tool speziell für die Delphi-VCL, welches die Dateigröße erheblich verkleinern kann. Leider fällt mir der Name gerade nicht ein.

[Counter909]

keiner eine Idee, wie das Tool heißen könnte, mit dem ich das etwas verkleinern könnte ? :-)

[burn]

UPX ... um nur einen der üblichen Verdächtigen zu nennen.

mfg Steve

[Luckie]

Zitat:

Zitat von burn

UPX ... um nur einen der üblichen Verdächtigen zu nennen.

Und den Hinweis nicht vergessen, dass man wissen sollte, was man macht.

[Dezipaitor]

Oder gleich C++ oder sogar Assembler. Je kleiner die Anwendung werden soll, desto unbequemer muss man sie programmieren.

[jbg]

Zitat:

Zitat von Dezipaitor

Oder gleich C++

Also wenn ich da auch wie unter Delphi eine monolithische EXE Datei erstelle, ist die aber noch viel größer als mit Delphi. Bei Delphi kann man auch die RTL/VCL in DLLs (aka BPLs) auslagern, wie es gerne von manchen 64KB C++ Programmieren gemacht wird, , die angeben wollen wie klein ihre EXE Datei ist. Dabei wissen diese aber oftmals garn nicht, dass da noch ein gewaltiger DLL Rattenschwanz dranhängt, der bei Delphi eben standardmäßig in die EXE hinein kompiliert wird.

[1234588]

Zitat:

Zitat von Dezipaitor

Oder gleich C++ oder sogar Assembler. Je kleiner die Anwendung werden soll, desto unbequemer muss man sie programmieren.

ich erstelle dir mit (fast) jedem delphi compiler kleineren code im vergleich zu einem gleichwertigem c++ programm.
selbst mit der vcl.
eine leere konsolen applikation erstellt mit devcpp(mingw) hat bei mir bereits +460kb (mit cstdlib und iostream).
es ist eben nicht alles gold was glaentzt ;)

[jbg]

Zitat:

Zitat von jbg

ein gewaltiger DLL Rattenschwanz dranhängt, der bei Delphi eben standardmäßig in die EXE hinein kompiliert wird.

Ach ja und wenn mir jetzt jemand damit kommt, dass die C++ DLLs alle bei Windows dabei sind, der hat wohl die ganzen Microsoft Visual C++ 2005 Redistibutables, die in letzter Zeit des öfteren die Runde machen, noch nicht gesehen.

[turboPASCAL]

@Counter909,

(Simple Erklärung zu UPX & Co)

Also UPX ist eine schlechte Idee. Dieses Tool komprimiert die Datei nur also eine Art
selbst entpackendes Archiv für Exe-Datein.
Wenn solch eine komprimierte Exec gestartet wird entpack sich diese im Hauptspeicher.
Dazu kommt noch mal die Grösse der Exec. D.h. mit UPX lädt man sich das Programm
zwei mal in den Speicher. Das Tool macht also nur bei kleinen Dateien und oder
zu Transportzwecken für USB-Stick oder Internet Sinn wenn man es nicht in ein
Zip.- Rar.- oder anderes Archiv packen kann oder darf.

Die Grösse der Exec's:

Die normale VCL - Standard Delphi Anwendungen enthält Units und Libarys die dem Programmierer
das programmieren erleichtern. So braucht sich dieser nicht explizit zB. um das Erstellen
einer Form (eines Fensters) oder eines Buttons sowie "Fehlerabfangroutinen" zu kümmern.
Eine solche erzeugte Datei ist nun rund 500 KByte gross.

Will man das nun vermeiden kann man auch ohne die VCL programmieren. ( Stichwort nonVCL )
Der Nachteil ist das der Programmierer sich nun um alles selbst kümmern muss (zB. um das Erstellen des
Fensters, Buttons o.ä.). Der Vorteil eine kleine Exec.-Datei. Die Grösse der Datei ist dafür minimal.
Ein kleines Programm kann so zB. bei rund 20 KBytes liegen.

Beispiele.:
Standard - VLC Anwendung mit einem Fenster:

Delphi-Quellcode:

// - 1 ---------------------------------------------------------------------

program Project1;

uses
  Forms,
  Unit1 in 'Unit1.pas' {Form1};

{$R *.res}

begin
  Application.Initialize;
  Application.CreateForm(TForm1, Form1);
  Application.Run;
end.

// - 2 ---------------------------------------------------------------------

unit Unit1;

interface

uses
  Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
  Dialogs;

type
  TForm1 = class(TForm)
  private
    { Private-Deklarationen }
  public
    { Public-Deklarationen }
  end;

var
  Form1: TForm1;

implementation

{$R *.dfm}

end.

Die Grösse der Exec.-Datei beträgt nun schon ~ 400 kBytes.

Standard - nonVLC Anwendung mit einem Fenster:

Delphi-Quellcode:

program Project1;

(* {$R 'resource.res' 'resource.rc'} *)

uses
  Windows, Messages;

const
  wndClassName = 'mWndClass';
  wndAppTitle  = 'nonVCL';
  WndWidth     = 320;
  WndHeight    = 240;

var
  hWndApp: Cardinal;

function WndProc(_hWnd: HWND; _Msg: UINT; _wParam: wParam; _lParam: LParam):
  lresult; stdcall;
var
  x, y : integer;
begin
  Result := 0;

  case _Msg of
    WM_CREATE:
      begin
        // Fenster zentrieren
        x := GetSystemMetrics(SM_CXSCREEN);
        y := GetSystemMetrics(SM_CYSCREEN);
        MoveWindow(_hWnd, (x div 2) - (WndWidth div 2),
          (y div 2) - (WndHeight div 2), WndWidth, WndHeight, TRUE);
      end;
    WM_DESTROY:
      PostQuitMessage(0);
  else
    Result := DefWindowProc(_hWnd, _Msg, _wParam, _lParam);
  end;
end;

var
  WndClass: TWndClass;
  msg: TMsg;

BEGIN
  with WndClass do
  begin
    // cbSize        := SizeOf(TWndClassEx);
    Style         := CS_HREDRAW or CS_VREDRAW;
    lpfnWndProc   := @WndProc;
    cbClsExtra    := 0;
    cbWndExtra    := 0;
    hbrBackground := COLOR_APPWORKSPACE;
    lpszMenuName  := nil;
    lpszClassName := wndClassName;
    // hIconSm       := 0;
    hInstance     := hInstance;
    hIcon         := LoadIcon(hInstance, MAKEINTRESOURCE(100));
    hCursor       := LoadCursor(0, IDC_ARROW);
  end;

  // Fenster registrieren
  RegisterClass(WndClass);

  // Fenster erzeugen
  hWndApp := CreateWindow(
      wndClassName,
      WndAppTitle,
      WS_OVERLAPPEDWINDOW,
      INTEGER(CW_USEDEFAULT),
      INTEGER(CW_USEDEFAULT),
      WndWidth,
      WndHeight,
      0,
      0,
      hInstance,
      nil);

  // Fenster anzeigen
  UpdateWindow(hWndApp);
  ShowWindow(hWndApp, SW_SHOW);

  // Nachrichtenschleife
  while GetMessage(msg,0,0,0) do
  begin
    TranslateMessage(msg);
    DispatchMessage(msg);
  end;

  UnRegisterClass(WndClassName, HInstance);

  ExitCode := msg.wParam;
END.

Die Grösse der Exec.-Datei beträgt nun nur ~12 Bytes.


Ist es nicht Notwendig ein Fenster zu erzeugen kann man sich auch mit einer Art
Misch aus beiden Programiervarianten behelfen:

Delphi-Quellcode:

program Project1;

uses
  Windows, SysUtils;

function Addiere(ValueA, ValueB: integer): integer;
begin
  Result := ValueA + ValueB;
end;

procedure Machwas;
begin
  MessageBox(0, PCHAR(IntToStr(Addiere(100, 23))), 'Hallo:', MB_OK);
end;

BEGIN
  Machwas;
  MessageBox(0, PCHAR(TimeToStr(now)), 'Die Uhrzeit ist:', MB_OK);
END.

Die Grösse der Exec.-Datei beträgt nun ca. 45 kBytes.


// Edit: Doppelmoppel entfernt.

[Hansa]

Zitat:

Zitat von turboPASCAL

Ist es nicht Notwendig ein Fenster zu erzeugen kann man sich auch mit einer Art
Misch aus beiden Programiervarianten behelfen:

Delphi-Quellcode:

program Project1;

program Project1;

uses
  Windows, SysUtils;

function Addiere(ValueA, ValueB: integer): integer;
begin
  Result := ValueA + ValueB;
end;

procedure Machwas;
begin
  MessageBox(0, PCHAR(IntToStr(Addiere(100, 23))), 'Hallo:', MB_OK);
end;

BEGIN
  Machwas;
  MessageBox(0, PCHAR(TimeToStr(now)), 'Die Uhrzeit ist:', MB_OK);
END.

Die Grösse der Exec.-Datei beträgt nun ca. 45 kBytes.

Dazu habe ich eine Frage (obwohl 500 kB heutzutage eigentlich uninteressant sind) : es heißt immer, die SysUtils würde viel Speicherplatz brauchen. Liegt das nicht daran, sondern nur an den Forms ? :shock: Was das nonVCL-Zeugs soll, das muss mir wohl sowieso Luckie erklären. :mrgreen:

[turboPASCAL]

Zitat:

Zitat von Hansa

Dazu habe ich eine Frage (obwohl 500 kB heutzutage eigentlich uninteressant sind) ...

Naja nicht jeder hat GB Ram es gibt Leute die haben "nur" 512 MB.
Ausserdem ist es heut zu Tage irgend wie Mode den Speicher zuzumüllen. :gruebel:

Zitat:

Zitat von Hansa

... es heißt immer, die SysUtils würde viel Speicherplatz brauchen. Liegt das nicht daran, sondern nur an den Forms ? :shock:

Jain. Die SysUtils schlägt mit ca. 38 Kbyte zu. Kommt darauf an was aus der Unit
verwendet werden soll. Das Was die Exec. aufbläht sind u.A. die Units Forms,
Classes, Variants. Andere Units wie zB. Graphics, Dialogs bedingen
die Units Classes, Forms, Sysutils etc.

Zitat:

Zitat von Hansa

Was das nonVCL-Zeugs soll, das muss mir wohl sowieso Luckie erklären. :mrgreen:

Na dann viel Spass. So schlimm ist das nicht.

Wer sich mit nonVCL auskennt weiss was bei der VCL programmierung im Hintergrund abgeht... :mrgreen:

[Hansa]

Zitat:

Zitat von turboPASCAL

..Naja nicht jeder hat GB Ram es gibt Leute die haben "nur" 512 MB.
Ausserdem ist es heut zu Tage irgend wie Mode den Speicher zuzumüllen. :gruebel:
...Die SysUtils schlägt mit ca. 38 Kbyte zu...

Ja gut, aber das wären doch nur lächerliche 0,000038 vom RAM ! Zahlen ohne Gewähr. 8) Warum macht sich denn da einer solche Mühen, das zu reduzieren ? :shock: Wenn da parallel noch Office läuft, dann ist das doch wohl höchstens für die Katz. :mrgreen:

[Der.Kaktus]

Hallo, ich nutze ASPACK...Exe um 30-50% kleiner! :-D

[Bernhard Geyer]

Zitat:

Zitat von turboPASCAL

..Naja nicht jeder hat GB Ram es gibt Leute die haben "nur" 512 MB.
Ausserdem ist es heut zu Tage irgend wie Mode den Speicher zuzumüllen. :gruebel:

Ein Exe-Packer ist dann aber kontraproduktiv, da die Exe anschließend mehr RAM benötigt. Ein Exe-Packer ist eigentlich m.E. vollkommen Sinnlos

1, Internet Übertragungskapazität spare ich sichere wenn ich die Exe mit einem 0815-Komprimierungstool komprimiere .
2, RAM kann ich durch einen Exe-Packer nicht aus den bekannten Gründen sparen (Exe wird im Speicher dekomprimiert). Ebenfalls sorgt Windows dafür das nicht benötigter Speicherbedarf aus der Exe bei bedarf neu geladen wird.
3, Will ich platz auf der Festplatte sparen, so kann ich doch die Festplatte als ganzes oder die entsprechenden Verzeichnisse als einzelnes komprimieren.

Was bleibt also übrig außer einer kleinere Zahl im Windows Explorer?

[Thomasl]

Wenn ich eine Exe per ISDN/Modem DFÜ Remote austausche und auf dem remote PC alles gesperrt ist(winzip etc.)
geht es schneller wenn ich die .exe mit UPX von 3mb auf 500kb verkleinere(Arbeitsspeicher ist egal weil es die einzigste Sofware auf dem PC ist(Visualisierungs PC)).

Eine andere Software die nur auf einem usbstick gespeichert ist verkleinert sich von 2mb auf 300kb

[Luckie]

Zitat:

Zitat von turboPASCAL

Zitat:

Zitat von Hansa

Dazu habe ich eine Frage (obwohl 500 kB heutzutage eigentlich uninteressant sind) ...

Naja nicht jeder hat GB Ram es gibt Leute die haben "nur" 512 MB.

Die Größe des Arbeuitsspeichers ist vollkommen unerheblich, da jedem Prozess 4 GB Adressraum zur Verfügung stehen. Festplattenkapazität ist heut zu Tage unerheblich.

Und wenn es auf den Transport ankommt, dann sind normale Packer wesentlich besser geeignet, da sie nicht wie UPX bei der Ausführung des Programmes, das Speichermanagment von Windows aushebeln. Und wenn kein Entpacker auf dem Zielsystem vorhanden ist, dann kann man immer noch selbstentpackende Archive erstellen.

[Bernhard Geyer]

Zitat:

Zitat von Thomasl

Wenn ich eine Exe per ISDN/Modem DFÜ Remote austausche und auf dem remote PC alles gesperrt ist(winzip etc.)
geht es schneller wenn ich die .exe mit UPX von 3mb auf 500kb verkleinere(Arbeitsspeicher ist egal weil es die einzigste Sofware auf dem PC ist(Visualisierungs PC)).

Dann nimm ich ein selbstentpackendes Archiv. Denn irgendwelche Exes darfst du ja kopieren und Ausführen.

[Dezipaitor]

Ich kenne schon wieder eine Menge Leute, die ExeArchive verabscheuen, weil es die Platte zumüllt. Also es gibt immer jemanden, der eine Art nicht gefällt.
Was ich aber garnicht empfehlen kann, ist die ausschließliche Verwendung von nonVCL für größere Projekte. Das kann zwar gut gehen, allerdings ist Entwicklungszeit deutlich länger und die Wartung wird auch komplizierter.
In C++ nutzt man CreateWindow auch nur noch selten direkt. Stattdessen ist ATL, WTL und MFC angesagt. Stichworte: OOP, Komponente, Schichtenmodell

Versteht mich nicht falsch. Einmal ein Projekt mit den C Funktionen geschrieben zu haben, trägt stark zum Verständniss der WinAPI bei. Mit Zeigerinhalten sich rumzuschlagen sollte aber nicht mehr zu der heutigen Programmierung/Entwicklung gehören. Deshalb bin ich auch so gegen C für Anwendungssysteme im Gegensatz zu Bereichen, die nahe der HW sind.

[Hansa]

Zitat:

Zitat von Dezipaitor

Ich kenne schon wieder eine Menge Leute, die ExeArchive verabscheuen, weil es die Platte zumüllt. Also es gibt immer jemanden, der eine Art nicht gefällt...

Das stimmt, jedem kann mans nicht recht machen. Aber das D bei den DAUs ist in den letzten Jahren etwas in der Bedeutung gemindert worden. :zwinker: Die wissen zumindest ungefähr, was ein "Ordner" ist. Und einige haben sogar schon das Wort "Registry" gehört. Wenn man denen bei der Installation dann auch noch erklärt, dass eben nichts an der Registry rumgeschraubt wird, der Rechner deshalb auch nicht neu gestartet werden muss etc. und dann noch eine Deinstallation durch löschen eines Ordners gewährleistet wird, dann fühlen die sich sicher. :mrgreen: Ich stelle sie sogar grundsätzlich vor die Wahl, ob das Programm nur von CD gestartet werden soll.