Laufzeit bpl Abhängigkeiten

[hanspeter]

Hallo,
Ich hatte mich gewundert, das meine unter D2010 kompilierten Programme fast 3 mal größer wurden.
Zwischenzeitlich habe ich festgestellt, das dafür einige externe Module verantwortlich sind.
Ich verwende z.B. die TMS - Module.
Dort gibt es eine 10 Mbyte große BPL tmsd2010. Verwende ich diese als Runtime bpl , dann wird mein Programm um fast 9 Mbyte kleiner.
Da scheint wohl der Linker nicht mehr sehr smart zu sein und linkt alles was er vor die Nase bekommt.
Also dachte ich, es ist eine gute Idee VCL,RTL und dieses Modul als Laufzeitpackage verwenden.
Das hat nicht ganz gereicht. Aufgrund interner Verbändelungen mußte noch TeeChart (obwohl nicht verwendet aber fehlen erzeugt Klassenfehler in rtl)
und IBDAC dazu.
Also eine hübsche kleine Liste :

Delphi-Quellcode:

Laufzeitpackages verwenden: vcl;ibdac140;rtl;tmsd2010;Tee

Jetzt habe ich das ganze mal auf einen Delphi-freien Rechner kopiert und ein böses Erwachen erlebt.
Zuerst beendet sich das Programm mit einer Fehlermeldung über fehlende Packages. Aufgrund irgendwelcher interner Abhängigkeiten mußten noch 14 weitere bpl
auf die Zielmaschine kopiert werden, obwohl sie nirgendwo als Laufzeit deklariert sind.
Darunter auch solche Exoten wie bdertl140.bpl oder vclactnband140.bpl. Weder die BDE noch Actionsbänder werden in dem Projekt verwendet.
Nach dem Hiunzufügen der geforderten BPL startet das Programm (im Taskmanager erkennbar) aber hängt sich auf.
Da es auf einen Delphi-verseuchten Rechner funktioniert, gehe ich davon aus, das noch weitere Laufzeitbpl notwendig sind.
Suche ich auf meinem Rechner nach *.bpl erhalte ich weit über 500 Referenzen.
Kennt wer ein Tool welches mir solche Abhängigkeiten auflistet oder muß ich nun ca. 500 bpl durchprobieren, bis das Programm startet?
Oder hat wer eine Liste der immer benötigten bpl?

Gruß
Peter

[hanspeter]

Hat sich erledigt.
Da ich nichts passendes finden konnte, habe ich mir schnell
selbst das benötigte Tool geschrieben.
Es ist beeindruckend, was ein Delphiprogramm beim Start an dll läd.
Warum aber manche mehrfach geladen werden? (z.B. ole32.ddl vier mal.)
Ich habe mal das Listing angehängt. Nur vcl und rtl sind runtime.
BPL mit * enthalten Debuginfo.

Peter

[Sherlock]

Also ich würde sowas nicht machen. Warum? Mehrer Gründe:
1) Es ist nur Augenwischerei. Deine exe ist zwar klein, aber Du lieferst einen Sack voll bpl mit...
2) bpl sind fast noch schlimmer als dll, bpl hell ist da ein gutes Stichwort.
3) Schau doch mal Deine Compilereinstellungen durch, eventuell ist da noch was zu optimieren.


Edit: ach, 3 ist ja gar kein Grund...nunja...egal. du verstehst schon was ich meine.
Sherloc

[Bernhard Geyer]

Zitat:

Zitat von hanspeter

Hat sich erledigt.
Da ich nichts passendes finden konnte, habe ich mir schnell
selbst das benötigte Tool geschrieben.

Dependency-Walker wäre das Tool der Wahl.

Zitat:

Zitat von hanspeter

Es ist beeindruckend, was ein Delphiprogramm beim Start an dll läd.
Warum aber manche mehrfach geladen werden? (z.B. ole32.ddl vier mal.)

Probier mal Dependency Walker. Der zeigt dir auf welche DLL welche andere DLL nachläd. Teiweise sind installierte Systemerweiterungen (NView, Office Groove, Virenscanner ...) die Schuldigen für viele geladenen DLL's. Ich tippe mal auch darauf das du WLAN aktiv hast und ACDSee installiert hast.

Delphi-Programme sind eigentlich immer sehr sparsam was DLL's betrifft.

[Stevie]

Bei Delphi wird ein Kommandozeilentool mitgeliefert, welches sich tdump.exe nennt. Damit kann man sich auch alle erforderlichen Libraries auflisten lassen.

[hanspeter]

Zitat:

Zitat von Sherlock

Also ich würde sowas nicht machen. Warum? Mehrer Gründe:
1) Es ist nur Augenwischerei. Deine exe ist zwar klein, aber Du lieferst einen Sack voll bpl mit...
2) bpl sind fast noch schlimmer als dll, bpl hell ist da ein gutes Stichwort.
Sherloc

Hatte ich ja schon oben geschrieben. Jede Exe die TMS verwendet wird um 6 bis 9 Mbyte kleiner.
Mein Projekt besteht aus 7 Exe-Files und 70Mbyte über Internet oder nicht, ist schon viel Holz.

Mir sind die Punkte 1 .. 3 durchaus bekannt und bewußt.
Ich selbst halte das BPL Konzept für Schwachsinn und versuche die bpl Hölle zu vermeiden, wo es geht.
Leider komme ich in dem vorliegenden Projekt nicht darum herum, da ich einige Teile in dll ausgelagert habe.
(z.B. der Reportgenerator des Projektes mit Fastreport, der in allen Exe gebraucht wird.)
Hier fliege ich zur Laufzeit sonst über die mehrfache Registrierung mit RegisterClass.
Ein Teil hatte ich als OutofProcess-Server realisiert. Wo sich aber wer an der notwendigen Registrierung störte.
(Die erfolgt zwar automatisch, braucht aber Administratorrechte.)
Inzwischen meine ich aber, das eine Com-Lösung doch der bessere Weg ist.

Peter

[hanspeter]

Zitat:

Zitat von Bernhard Geyer

Probier mal Dependency Walker. Der zeigt dir auf welche DLL welche andere DLL nachläd. Teiweise sind installierte Systemerweiterungen (NView, Office Groove, Virenscanner ...) die Schuldigen für viele geladenen DLL's. Ich tippe mal auch darauf das du WLAN aktiv hast und ACDSee installiert hast.

Nein WLAN ist nicht aktiv und ACDSee ist ebenfalls nicht installiert.

[messie]

Mich hat es bisher auch immer gewundert, das die bpl komplett gelinkt werden, auch wenn ich nur einen kleinen Teil verwende. Das macht nicht nur bei TMS, sondern auch bei den Alphaskins recht große exen.

Kann man das nicht irgendwie optimieren? Im Prinzip müsste man für jede Komponente ein eigenes Package machen, um nur das zu linken, was man benutzt.

Grüße, Messie

[Bernhard Geyer]

Zitat:

Zitat von hanspeter

Nein WLAN ist nicht aktiv und ACDSee ist ebenfalls nicht installiert.

Die Dateinamen haben es nahegelegt.

Aber probier trotzdem mal Dependency Walker. Damit bekommst du auch schön die Liste der delayed Loaded DLL's.

[schöni]

Hallo,

Das Eingangsposting in diesem Thread erschüttert mich total. Intelligentes Linken (Nur, was wirklich im Code verwendet wird, wird auch eingebunden, der übrige Code bleibt draußen, war zu Zeiten von Turbo Pascal 7.0 schon mal da. Warum jetzt nicht mehr?

Die Technologie dafür haben die doch schon seit Turbo Pascal 7.0. Braucht doch somit bloß wieder verwendet zu werden.

Zitat:

Zitat von Bernhard Geyer

Probier mal Dependency Walker. Der zeigt dir auf welche DLL welche andere DLL nachläd. Teiweise sind installierte Systemerweiterungen (NView, Office Groove, Virenscanner ...) die Schuldigen für viele geladenen DLL's. Ich tippe mal auch darauf das du WLAN aktiv hast und ACDSee installiert hast.

Welche Dll's von anderen Dll's noch nachgeladen werden, kann natürlich der Compiler wiederum nicht wissen.

Zitat:

Ich selbst halte das BPL Konzept für Schwachsinn und versuche die bpl Hölle zu vermeiden, wo es geht.

Hmmm, ja, bei Lazarus muss bei Installation neuer Komponenten die IDE neu übersetzt werden, was auch nicht so die optimale Lösung ist. Wenn dann noch im Compilerlauf irgendwas nicht gefunden wird, geht die Komponente nicht zu installieren, weil die IDE danach nicht neu übersetzt werden kann. Baue grd ne eigene IDE. Vielleicht sollte ich da einen Designer konzipieren. Vielleicht geht da mit Interfaces was besseres um Fremdkomponeten zu installieren. Mal schauen. Erst mal die IDE in den Basisfunktionen.

Fazit aus diesem Thread wäre:

Für jede Komponente ein eigenes Package!.

[Bernhard Geyer]

Zitat:

Zitat von schöni

Das Eingangsposting in diesem Thread erschüttert mich total. Intelligentes Linken (Nur, was wirklich im Code verwendet wird, wird auch eingebunden, der übrige Code bleibt draußen, war zu Zeiten von Turbo Pascal 7.0 schon mal da. Warum jetzt nicht mehr?

Die Technologie dafür haben die doch schon seit Turbo Pascal 7.0. Braucht doch somit bloß wieder verwendet zu werden.

Das macht der Compiler schon. Jedoch ist es fraglich was TMS hier "verpfuscht". Evtl. irgendwelche Funktionen im initialisation-Abschnitt was dazu führt das alles gezogen wird.

[hanspeter]

Zitat:

Zitat von schöni

Fazit aus diesem Thread wäre:

Für jede Komponente ein eigenes Package!.

Bringt auch nicht viel außer einen Haufen Arbeit.
So man das Programm modular anlegen will, kommt man an Laufzeitbibliotheken nicht vorbei.
Je mehr man davon hat um so gefährlicher wird die Sache.
Entweder man liefert immer alle bpl bei einem Update mit aus oder sitzt schnell in der Falle
"xyz wurde mit anderer Version von abc compiliert."
dll ohne Laufzeit geht nicht, da die dll in den gleichen Processraum wie das Programm geladen wird.
Viele VCL Komponenten können aufgrund von Registerclass nur einmal im gleichen Adressraum verwendet werden.
Ich hatte es weiter oben bereits gesagt, keine Laufzeitbibliotheken und Comserver statt dll entschärft das Problem fast total.
Obwohl auch eine Comserver-dll in den gleichen Processraum geladen wird, tritt hier interessanter Weise das
RegisterClass- Problem nicht auf.

Peter