1.) Mit Icarus kann man bei Delphi-Projekten nach ungenutzen Units suchen und diese anschließend entfernen, um dadurch die Exe zu verkleinern:

http://www.peganza.com/products_icarus.htm

2.) Eine weitere Möglichkeit ist die Relocation-Tabelle aus einer Exe zu löschen, die in den meisten Projekten nicht benötigen wird. Delphi packt diese immer in die Exe rein.
Hierfür kann man z.B. StripReloc benutzen:

http://www.innosetup.com/striprlc.php

3.) Natürlich kann man auch die BPL-Dateien auslagern.
Diese werden dann beim Start des Projekts geladen und sind nicht in der Exe-Datei mit reingepackt.
Vor allem, wenn man mit vielen verschiedenen Komponentensammlungen arbeitet, ist dies eine gute Möglichkeit die Exe-Datei kleiner zu bekommen.

4.) Image-Dateien extern auslagern und erst in den Speicher laden, sobald sie angezeigt werden sollen.

Eine von uns bisher eingesetzte Methode, die ich allerdings inzwischen nicht mehr empfehle, wäre Exe-Packer wie ASPack oder UPX zu verwenden.
Dies ist zwar sehr effektiv um die Exe-Datei kleiner zu bekommen, bringt aber auch Nachteile ( gefunden bei dem Link von StripReloc ):

• Upon startup of a compressed EXE/DLL, all of the code is decompressed from the disk image into memory in one pass, which can cause disk thrashing if the system is low on memory and is forced to access the swap file.
  In contrast, with uncompressed EXE/DLLs, the OS allocates memory for code pages on demand (i.e. when they are executed).

• Multiple instances of a compressed EXE/DLL create multiple instances of the code in memory.
  If you have a compressed EXE that contains 1 MB of code (before compression) and the user starts 5 instances of it, approximately 4 MB of memory is wasted.
  Likewise, if you have a DLL that is 1 MB and it is used by 5 running applications, approximately 4 MB of memory is wasted.
  With uncompressed EXE/DLLs, code is only stored in memory once and is shared between instances.

Hier gelangt Ihr zum Sneak Peek Video mit David I:

http://dn.codegear.com/article/38383

Dies lohnt sich, dann wenn man mehre Applikationen hat, die dieselben Komponenten verwenden,
da die Anwendung dann viel kleiner wird.

Wichtig ist dabei, dann man nicht nur die Dateien mit der Endung .bpl sondern auch die Sprachdatei mit der Endung .de zur Applikation packt, sondern kann es passieren, dass z.B. Standard Dialoge beim Button “Ja” plötzlich “Yes” schreiben.

Bei Packages von Fremdherstellern kann das allerdings schwierig werden

Wenn man wissen möchte, welche Dateien von einer Applikation verwendet werden, kann man das Tool Dependency Walker verwenden.

http://dependencywalker.com/

type
  TeqObject = class( TPersistent )

In meiner eigenen Entwicklung leite ich nun alle meine benötigten Klassen von TeqObject ab.
Ein einfaches Beispiel soll die Anwendung und den Nutzen demonstrieren.

type TMitarbeiter = class( TeqObject )
  private
    M_Vorname : String;
    M_Nachname : String;
    M_Alter : Integer;
  published
    property Vorname : String read M_Vorname write M_Vorname;
    property Nachname : String read M_Nachname write M_Nachname;
    property Alter : Integer read M_Alter write M_Alter;
end;
 
procedure ErzeugeMitarbeiter;
var
  mitarbeiter : TMitarbeiter;
begin
  mitarbeiter := TMitarbeiter.Create;
  with mitarbeiter do begin
    Vorname  := 'Pascal';
    Nachname := 'Potrafke';
    Alter    := 24;
    SaveAsXML( 'mitarbeiter.xml' );
  end;
  FreeAndNil( mitarbeiter );
end;

Was habe ich nun gemacht? Ich habe ein Klasse erstellt, von dieser ein Objekt instanziiert und dieses einfach als XML gespeichert. Das ergebnis sieht wie folgt aus.

  24
  Potrafke
  Pascal

Die Delphi RTTI erlaubt es nur auf Eigenschaften zuzugreifen die im published Block definiert sind. Es werden also nicht alle Member Eigenschaften serialisiert. Das ist auch der Grund dafür, dass in dem Beispiel nur die Properties in der XML Datei zu sehen sind.
Was serialisiert wurde kann natürlich auch wieder deserialisiert werden. Dafür gibt es das obligatorische Gegenstück zur allen Save() Methoden in Delphi, nämlich die Load() Methoden.

mitarbeiter.LoadFromXML( 'mitarbeiter.xml' );

Soweit so gut, allerdings gibt es auch die ein oder andere Einschränkung. Im Detail bedeutet das, dass nicht für alle Typen von Borland RTTI Informationen zur Laufzeit erzeugt werden.
Dazu gehören tkRecord, tkArray, tkDynArray (bedingt) und Pointer jeglicher Art.

tkArray: Delphi brauch hier keine Informationen, da normale (statische) Arrays kein Cleanup brauchen.

tkDynArray: Für tkDynArray wird zwar eine RTTI Information zur Laufzeit erzeugt, diese dient Delphi jedoch nur um bei dem Speicher Management die Infos zu bekommen wieviele Einträge es von welchem Typ aufräumen muss.

Ein kurzer Ausschnitt aus der TypeInfo.pas (Delphi 2007 Version 11) soll die fehlenden Implementationen zeigen.

  TTypeData = packed record
    case TTypeKind of
      tkUnknown, tkLString, tkWString, tkVariant: ();
      tkInteger, tkChar, tkEnumeration, tkSet, tkWChar: (
        OrdType: TOrdType;
        case TTypeKind of
          tkInteger, tkChar, tkEnumeration, tkWChar: (
            MinValue: Longint;
            MaxValue: Longint;
            case TTypeKind of
              tkInteger, tkChar, tkWChar: ();
              tkEnumeration: (
                BaseType: PPTypeInfo;
                NameList: ShortStringBase;
                EnumUnitName: ShortStringBase));
          tkSet: (
            CompType: PPTypeInfo));
      tkFloat: (
        FloatType: TFloatType);
      tkString: (
        MaxLength: Byte);
      tkClass: (
        ClassType: TClass;
        ParentInfo: PPTypeInfo;
        PropCount: SmallInt;
        UnitName: ShortStringBase;
       {PropData: TPropData});
      tkMethod: (
        MethodKind: TMethodKind;
        ParamCount: Byte;
        ParamList: array[0..1023] of Char
       {ParamList: array[1..ParamCount] of
          record
            Flags: TParamFlags;
            ParamName: ShortString;
            TypeName: ShortString;
          end;
        ResultType: ShortString});
      tkInterface: (
        IntfParent : PPTypeInfo; { ancestor }
        IntfFlags : TIntfFlagsBase;
        Guid : TGUID;
        IntfUnit : ShortStringBase;
       {PropData: TPropData});
      tkInt64: (
        MinInt64Value, MaxInt64Value: Int64);
      tkDynArray: (
        elSize: Longint;
        elType: PPTypeInfo;       // nil if type does not require cleanup
        varType: Integer;         // Ole Automation varType equivalent
        elType2: PPTypeInfo;      // independent of cleanup
        DynUnitName: ShortStringBase);
  end;

Das hat zur Folge, das wenn man dieses Feature verwenden möchte, sich von Records und (dynamischen) Arrays verabschieden muss.
Anstelle von Records werden nun Klassen verwendet. Was bereits beim Mitarbeiter Beispiel gemacht wurde. Denn für solch einfache Strukturen hätte es eigentlich auch ein normaler Record getan.
Dennoch denke ich das dieser geringe Mehraufwand bei der Definition in hinsicht auf das (de)serialisieren kaum ins Gewicht fällt.
(Dynamische) Arrays werden nun durch eine weitere Classroot ersetzt.

type TDyneqObjectList = array of TeqObject;
 
type
  TeqObjectList = class( TeqObject )
  private
    M_List : TDyneqObjectList;
...
...
...

Mit dieser Listenklassen können Array Strukturen abgebildet werden und das (de)serialisieren Feature weiterhin bequem verwendet werden. Folgendes Beispiel soll die Listenklasse demonstrieren.

type TUnternehmen = class( TeqObject )
  private
    M_Firmenname : String;
    M_Internetadresse : String;
    M_Mitarbeiter : TeqObjectList;
  public
    constructor Create; override;
  published
    property Firmenname : String read M_Firmenname write M_Firmenname;
    property Internetadresse : String read M_Internetadresse write M_Internetadresse;
    property Mitarbeiter : TeqObjectList read M_Mitarbeiter write M_Mitarbeiter;
end;
 
type TMitarbeiter = class( TeqObject )
  private
    M_Vorname : String;
    M_Nachname : String;
    M_Alter : Integer;
  published
    property Vorname : String read M_Vorname write M_Vorname;
    property Nachname : String read M_Nachname write M_Nachname;
    property Alter : Integer read M_Alter write M_Alter;
end;
 
constructor TUnternehmen.Create;
begin
  inherited Create;
 
  Self.M_Mitarbeiter := TeqObjectList.Create;
end;
 
procedure ErzeugeUnternehmen;
var
  unternehmen : TUnternehmen;
begin
  unternehmen := TUnternehmen.Create;
  with unternehmen do begin
    Firmenname      := 'EQUITANIA Software GmbH';
    Internetadresse := 'http://www.equitania.de';
    with ( Mitarbeiter.Item[ Mitarbeiter.Add( TMitarbeiter.Create ) ] as TMitarbeiter ) do begin
      Vorname  := 'Pascal';
      Nachname := 'Potrafke';
      Alter    := 24;
    end;
    with ( Mitarbeiter.Item[ Mitarbeiter.Add( TMitarbeiter.Create ) ] as TMitarbeiter ) do begin
      Vorname  := 'Paul';
      Nachname := 'Exler';
      Alter    := 24;
    end;
    SaveAsXML( 'unternehmen.xml' );
  end;
end;

Die List funktioniert wie eine StringList und besitzt Methode wie Add(), Remove(), Item, etc.
Das Ergebnis sieht nun wie folgt aus.

  EQUITANIA Software GmbH
  http://www.equitania.de
 
      24
      Potrafke
      Pascal
 
      24
      Exler
      Paul

Von der Komplexität der Klassenstrukturen gibt es keinerlei Einschränkungen.
Auch das Einlesen dieses XML Gebildes ist kein Problem. Einzige Schwierigkeit war hier, das beim einlesen die Objekte IN der Liste von dem jeweiligen Typ instanziiert werden müssen damit zur Laufzeit drauf zurückgegriffen werden kann. Aber auch darum muss man sich nicht mehr kümmern.
Was man jedoch derzeit noch von Hand machen musst ist das registrieren der Klassen. Ohne dem werden bzw. können die Objekte nicht instanziiert werden.

initialization
  RegisterClasses( [ TUnternehmen, TMitarbeiter ] );

So, nun wünsche ich viel Spass beim ausprobieren.
Eines möchte ich noch sagen. Der Code kann Fehler enthalten. Daher ist die Benutzung auf eigene Gefahr. Verbesserungsvorschläge und Anregungen gerne gesehen.
Sourcecode zum Download

Bei meinem Beispiel gehe ich davon aus, dass bereits eine Excel-Datei existiert, die wir auslesen oder bearbeiten wollen.

Hier ein Codeschnipsel zu Öffnen und Auslesen der Datei:

Excel := CreateOleObject('excel.application');
Excel.Visible := false;  //Macht das Excel-Fenster sichtbar
Excel.Workbooks.Open('C:\daten\testexcel.xls');
strFeldA1 := Excel.ActiveSheet.Cells[1,1].Value; // Ließt das Feld A1
Excel.DisplayAlerts := false;  //Deaktiviert Nachfrage beim Beenden
Excel.quit;  //Beendet Excel (Wichtig sonst bleibt es immer offen im Hintergrund)

Um ein Feld zu ändern erweitern wir das ganze ein wenig:

Excel := CreateOleObject('excel.application');
Excel.Visible := false;   //Macht das Excel-Fenster sichtbar
Excel.Workbooks.Open('C:\daten\testexcel.xls');
Excel.ActiveSheet.Cells[1,1].Value := 'Test'; // Beschreibt das Feld A1
Excel.DisplayAlerts := false;    //Deaktiviert Nachfrage beim Beenden
Excel.ActiveWorkbook.SaveAs('C:\daten\testexcel2.xls');
Excel.quit;   //Beendet Excel (Wichtig sonst bleibt es immer offen im Hintergrund)

Wichtig ist allerdings, dass Excel auf dem jeweiligen Rechner installiert ist, damit diese Lösung funktioniert.

Das Objekt “Excel” ist dabei eine Variable vom Typ Variant und als zusätzliche Unit muss ComObj eingebunden werden.

Delphi Resource-Editor

In meinem Beispiel habe ich 2 Icons in die Resourcedatei hinzugefügt, wodurch mein Resultat schlussendlich folgendermaßen aussieht:

Wichtig ist hierbei, dass es ein Icon mit der Bezeichnung “MAINICON” gibt. Dieses wird als Standard-Icon der Applikation verwendet.

Als nächstes speichert man die Resource als z.B. “Test.res” in das Projektverzeichnis der Applikation.

Um die Resourcedatei in das Programm einzubinden genügt:

{$R Test.res}

Schlussendlich genügt dann folgender Code (bei meinem Beispiel) um das Icon zu ändern:

  Icon.Handle := LoadIcon(HInstance, 'ICON2');

Um das Standardicon wieder herzustellen reicht demnach:

  Icon.Handle := LoadIcon(HInstance, 'MAINICON');

Weitere Bücher zu IT Themen findet man ebenfalls unter http://de.wikibooks.org/wiki/Regal:Programmierung

Man öffnet ein Formular mit “frmBeispiel.Show;” und schließt es mit “frmBeispiel.Close;”.

Dabei geht man davon aus, dass der Speicher wieder freigegeben wird. Irrtum!

Gleiches gilt für alle Objekte!

Deshalb mit “FreeAndNil(objekt);” freigeben.

Dynamische Arrays gibt man mit “SetLength(array,0);” frei.

Falls jemand vor dem gleichen Problem steht, beschreibe ich meinen Weg, mit dem ich die Applikationen in kürzester Zeit umgeschrieben hatte (Voraussetzung hierfür ist, dass keine linuxspezifischen Befehle verwendet wurden):

Nun sollte alles geschafft sein. Erstellen Sie nun Ihr Projekt neu.