Sinn von DLL-Formularen

[alcaeus]

Moin Martin,

ich wuerde aber davon abraten, die Borland-BPLs ins Programmverzeichnis zu kopieren. Wenn du 2 Anwendungen hast, die die Borland-Packages zur Laufzeit einbinden, dann muessen die Packages in beiden Anwendungsverzeichnissen vorhanden sein (ausser der Trick mit der PATH-Variable funktioniert), und der Vorteil der Platzersparnis ist erstmal weg.

Greetz
alcaeus

[mschaefer]

Hallo Andres,

die Begründung macht Sinn. Ist im Moment auch kein aktuelles Problem (dafür stehen heute noch einige Hashlisten auf demn Programm). Was ich bei Gelegenheit doch noch mal ausprobieren werde ist, ob ich die Borland-Packages per Fußweg im Projektquelltext aus einem anderen Verzeichnis laden kann, bevor die Formulare erstellt werden. Die Frage die dahinter steht ist: Wann wird die VCL geladen, bei Erstellen von TApplication oder bei dem Aufbau der Forms. Naja mal sehen vielleicht bekommt man das auch mit einem dll-Sniffer heraus. Man braucht dann wohl nur eine Application ohne Forms...

Grüße in den Süden

// Martin






PS: 20 Grad / Sonne / blauer Himmel / Überstunden :-(

[negaH]

Zitat:

Wann wird die VCL geladen, bei Erstellen von TApplication oder bei dem Aufbau der Forms.

Das hängt davon ab wie die Abhängigkeiten sind.

Normalerweise werden die Grundlagen Packages wie VCL,DB etc. statisch in die EXE gelinkt. Sie werden damit also beim Laden der EXE ebenfalls geladen.

Hat man nun weitere Packages die zb. nur anwendungspezifisch sind, und auf spezielle Formulare aus Modulen bezogen benötigt werden, dann werden diese Packages immer dann geladen und entladen wenn ein solchen Formular Modul geleden und entladen wird.

Diesen Fakt nutzen wir in unserem Modulsystem aus. Wir erzeugen Formulare erst bei Bedarf, sprich Nutzeraufruf, und laden dann das dazugehörige Modul ebenfalls dynamisch. Sollte dieses Formular aber auf ein eigenes mehrfach benutztes Packages statisch zugreifen, so wird dieses Packages ebenfalls dynamisch geladen. Logisch, wenn du mal tiefer darüber nachdenkst.

Einige Packages, besonders 3'rd Party Packages wie ReportBuilder, sollten aber schon statisch mit der EXE geladen werden und dann permanent im Speicher verbleiben. Denn diese Packages wurden nicht korrekt auf ein dynamsiches Entladen hin programmiert. Sie installieren Hooks oder allozieren Objekte etc. pp. und deinstallieren sie aber nicht mehr korrekt beim Entladen der Packages. Das kann dann zu Fehlern beim dynamischen Entladen führen.

Gruß Hagen

[negaH]

Zitat:

ich wuerde aber davon abraten, die Borland-BPLs ins Programmverzeichnis zu kopieren. Wenn du 2 Anwendungen hast, die die Borland-Packages zur Laufzeit einbinden, dann muessen die Packages in beiden Anwendungsverzeichnissen vorhanden sein

Bei heutigen Festplattengrößen und automatischen Setups halte ich diesen Vorschlag für nicht Support freundlich. Ich würde also genau das Gegenteil vorschlagen da so gewährleistet ist das andere Anweendungen einem nicht die Basis durch andere Packages unter dem Hintern wegreisen können. Zb. liefert Borland gepatchte Packages aus, je nach Compiler Version, die dann wenn man eine ungepatchte Delphi Version benutzt, zu massiven Problemen führen können falls diese Packages im SYSTEM liegen.

Besser also alles zur Anwendung zu speichern was möglich ist und nicht auf Speicherplatz zu schauen. Das oberste Prinzip bei kleinen Softwarefirmen heist "es muß stabil laufen". Reduziert man also unnnötige Abhängigkeiten zu Treibern, DLL's so reduziert man Probleme.

In diesem Punkt haben Linux/Unix Systeme ihren klaren Vorteil. Was sind schon 5-15 Mb Platz heutzutage ?

Gruß Hagen