.exe Dateigröße

[1234588]

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 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 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 ? Was das nonVCL-Zeugs soll, das muss mir wohl sowieso Luckie erklären.

[turboPASCAL]

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.

Zitat von Hansa:

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

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 von Hansa:

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

Na dann viel Spass. So schlimm ist das nicht.

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

[Hansa]

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.
...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 ? Wenn da parallel noch Office läuft, dann ist das doch wohl höchstens für die Katz.

[Der.Kaktus]

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

[Bernhard Geyer]

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.

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 von turboPASCAL:

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.