Hallo,
ich hätte mal eine Frage hinsichtlich DLL.
Ich habe mich schon oft gefragt, warum eigentlich viele bzw. alle Entwickler die DLL benutzen.
Nun habe ich einiges schon darüber gelesen. Ich kann z.B. Funktionen dort "auslagern", Formulare ect.

Ich würde auch Funktionen auslagern. Aber das kann ich doch in eigenen Units doch auch machen.

Welchen Vorteil hat das nun, wenn ich Funktionen in DLL erstelle? Ist z.B. der Zugriff schneller?

Vielleicht könnte mir jemand weiterhelfen.

Vielen Dank im Voraus.

MarcRB1975 hat folgendes geschrieben:

Hallo, ich hätte mal eine Frage hinsichtlich DLL. Ich habe mich schon oft gefragt, warum eigentlich viele bzw. alle Entwickler die DLL benutzen. Nun habe ich einiges schon darüber gelesen. Ich kann z.B. Funktionen dort "auslagern", Formulare ect. Ich würde auch Funktionen auslagern. Aber das kann ich doch in eigenen Units doch auch machen. Welchen Vorteil hat das nun, wenn ich Funktionen in DLL erstelle? Ist z.B. der Zugriff schneller? Vielleicht könnte mir jemand weiterhelfen. Vielen Dank im Voraus.

Ich glaube du wirfst hier etwas durcheinander.
Eine Unit als Programm-Modul hast du immer.
Du meinst wahrscheinlich eine BPL?

Eine dll ist eine Standardlösung und kann prinzipiell von allen Programmiersprachen aufgerufen werden.
Eine BPL ist eine Borland-Speziallösung die zu nichts, außer sich selbst in der gleichen Version, kompatibel ist.
Der Vorteil der BPL ist, das sie mit Objecten umgehen kann und es hier keine Probleme beim gesenseitigen Aufruf von
Objecten gibt.
Jedes dieser Verfahren hat Vor- und Nachteile.

DLL enthält intern eine Kopie des Delphi - Laufzeitsystems und wird damit stark aufgebläht.
Bietet dabei natürlich eine gute Kapselung. Es sind ein paar Besonderheiten bei der Parameterübergabe (Stringhandling)
zu beachten. Bekommt man aber gut in den Griff, wenn man mit Interfaces arbeitet.

BPL erzeugt eine versionsabhängige BPL Hölle, die bei größeren Projekten kaum mehr beherschbar ist.
Ohne ein Versionierungssystem (und da ist mir kein brauchbares kommerzielles System bekannt) sind BPL ein Dauerfrust für Anwender und Entwickler.
BPL kann nur mit Delphi und hier nur mit der gleichen Version verwendet werden.

Einer der wesentlichen Vorteile der MS NET Implementierung ist hier eine saubere Konzeptlösung.
Das Laufzeitsystem ist Bestandteil des Betriebssystems und die Assemblys sind versionierbare dll.

Eine weitere Möglichkeit zur Modularisierung ist die Verwendung mehrerer Exe-Files und die Parameterübergabe mittels Kommandozeile.

Zum heutigen Zeitpunkt würde ich BPL als Borland Sonderweg nicht mehr verwenden.
Ich bin gerade dabei ein Programm auf der Basis von Dll zu modularisieren.
Über PInvoke kann ich so eine Dll auch aus Net heraus aufrufen. Damit ist ein gleitender Übergang von Win32 zu net
möglich.
Win32 und damit Delphi sind leider ein Auslaufmodell und das was VCL.Net bisher geboten hat, kann konzeptionell nicht überzeugen.

Gruß
Carla

Hallo Carla,
wow... Danke für die Antwort.
Ich glaube, ich sollte mich wirklich ernsthaft mit der Thematik auseinandersetzen. Denn so wie Du ja schreibst, ist eine DLL nur von Vorteil. Vor allem auch dann, wenn man an die Zukunft und so auch an die Weiterentwicklung der Developer denkt.
Du hast schon Recht!!

Nochmal vielen Dank für Deine Antwort!!

Carla hat folgendes geschrieben:

MarcRB1975 hat folgendes geschrieben: Hallo, ich hätte mal eine Frage hinsichtlich DLL. Ich habe mich schon oft gefragt, warum eigentlich viele bzw. alle Entwickler die DLL benutzen. Nun habe ich einiges schon darüber gelesen. Ich kann z.B. Funktionen dort "auslagern", Formulare ect. Ich würde auch Funktionen auslagern. Aber das kann ich doch in eigenen Units doch auch machen. Welchen Vorteil hat das nun, wenn ich Funktionen in DLL erstelle? Ist z.B. der Zugriff schneller? Vielleicht könnte mir jemand weiterhelfen. Vielen Dank im Voraus. Ich glaube du wirfst hier etwas durcheinander. Eine Unit als Programm-Modul hast du immer. Du meinst wahrscheinlich eine BPL?

Ich glaube, er wirft nichts durcheinander. Seine Frage war, ob es sinnvoller ist, Funktionen in seperate Units oder gleich außerhalb der EXE in DLLs auszulagern. Aber du hast seine Frage trotzdem beantwortet...
Nochmal kurz: Units sind zur Gliederung des Quelltextes gut. DLLs lagern Funktionen komplett aus deiner EXE aus, was erstens den Vorteil hat, dass sie von anderen Programmen aufgerufen werden können, und zweitens kannst du sie dynamisch hinzuladen, während eine EXE AFAIK immer komplett geladen wird. Wenn du also eine 800MB große EXE hast, wäre es sinnvoll, einen großen Teil davon in externe DLLs auszulagern.

Weiterer Vorteil: Kleinere Updates.

Beispiel: Du hast nur an einem Modul deines Programmes etwas geändert. Wenn du keine DLLs verwendest, muss der User über eine entsprechende Updatefunktion die komplette *.exe neu herunterladen. Falls es sich um ein großes Projekt handelt, kann dies bei einer langsamen Internetverbindung frustrierend sein.

Verwendest du nun eine DLL für jedes Modul, so reicht es, diese eine DLL upzudaten und das geht dann wesentlich schneller, als die komplette *.exe neu herunterzuladen.

GTA-Place hat folgendes geschrieben:

Weiterer Vorteil: Kleinere Updates. Beispiel: Du hast nur an einem Modul deines Programmes etwas geändert. Wenn du keine DLLs verwendest, muss der User über eine entsprechende Updatefunktion die komplette *.exe neu herunterladen. Falls es sich um ein großes Projekt handelt, kann dies bei einer langsamen Internetverbindung frustrierend sein. Verwendest du nun eine DLL für jedes Modul, so reicht es, diese eine DLL upzudaten und das geht dann wesentlich schneller, als die komplette *.exe neu herunterzuladen.

Was sich aber sofort wieder durch das bpl Problem von Delphi relativiert.
Entweder ich schleppe alle benötigten BPL zusätzlich als Laufzeitumgebung mit. Dann habe ich die BPL Hölle.
Gerade D2007 compiliert nahezu willkürlich irgendeine BPL mit und die muss dann zusätzlich ausgeliefert werden.

Ich arbeite gerade an einem praktischen Problem und stelle ein Programm auf Dll um, um
längerfristig von Delphi wegzukommen.

Das Gesamtprojekt als monolitische Exe ist etwa 8,5 Mbyte groß.
Ein einzelner Dialog von etwa 200 schlägt als getrennte Exe mit 4 MByte zu buche.
Compiliere ich mit Laufzeit BPL (nur Delphi RTL und VCL), ist die Exe noch 3 Mbyte groß.


Gruß
Carla

Carla hat folgendes geschrieben:

Das Gesamtprojekt als monolitische Exe ist etwa 8,5 Mbyte groß. Ein einzelner Dialog von etwa 200 schlägt als getrennte Exe mit 4 MByte zu buche. Compiliere ich mit Laufzeit BPL (nur Delphi RTL und VCL), ist die Exe noch 3 Mbyte groß.

Und wie groß ist das Gesamtprojekt mit allen ausgeliefrten BPLs und DLLs? Nicht zu vernachlässigen der Speicheroverhead der beim Ausführen der anwendung dazu kommt.

Luckie hat folgendes geschrieben:

Und wie groß ist das Gesamtprojekt mit allen ausgeliefrten BPLs und DLLs? Nicht zu vernachlässigen der Speicheroverhead der beim Ausführen der anwendung dazu kommt.

Ist doch mein Reden.
Die Dll Lösung bringt gegenüber der monolitischen Lösung einen Overhead etwa um den Faktor 10.
Das trifft zu, wenn in der Dll intensiv Gebrauch von der VCL und hier Forms gemacht wird.
Eine reine funktionale Dll bringt kaum Overhead.
Das wir diesen Weg trotzdem gehen, ist einzig dadurch begründet, das wir für den Übergang von Win32 auf
Net einen sanften Weg mit einem durchgängig funktionsfähigen Programm gehen wollen.
Aber demnächst erscheint ja BDS 2007, das endlich Net 2.0 unterstützt. Vielleicht bietet sich hier noch ein anderer Weg an.

Gruß
Carla

Ohhh vielen Dank!!
Ich bin ja echt fasziniert von den ganzen Antworten.
Aber ihr habt recht! Wenn mein Programm X MB hat, so kann man auch niemanden zumuten bei jedem Update die gesamte EXE z.B. durch Internet zu downloaden.

Nochmal VIELEN Dank, Ihr hab mir echt bei meiner Entscheidung weitergeholfen.
Naja... jetzt werd ich mich mal damit beschäftigen. Aber was ich da so schon vorab gesehen und gelesen habe, ist diese Thematik nicht sooo schwer. Bin ja mal gespannt.

Lieben Gruß an alle die mitgewirkt haben!