Dll Projekt mit MEMMGR.LIB - BORLNDMM.dll wird nicht benötigt

[fruchtmixer]

Hallo,

ich habe eine Frage. Und zwar habe ich ein dll Projekt, erstellt mit C++ Builder XE. Folgende Konfiguration:

C++ Builder XE
"Mit dynamischer RTL linken" - false
"Laufzeit-Packages verwenden" - false

Aufgrund des bekannten Hinweises "...müssen Sie die Bibliothek MEMMGR.LIB dem DLL-Projekt ..." habe ich "MEMMGR.LIB" zu dem Projekt hinzugefügt (über Projekt->Dem Projekt hinzufügen).

Die Exe die die dll verwendet (ebenfalls erstellt mit C++ Builder XE, Konfiguration ist die gleiche (also keine dyn. RTL, keine Laufzeit-Packages, MEMMGR.LIB ebenfalls hinzugefügt).

Allerdings scheint MEMMGR.LIB nicht wirklich verwendet zu werden, weil:
- die exe läuft, auch wenn "BORLNDMM.dll" nicht im selben Verzeichnis liegt. Auch wenn BORLNDMM.dll im selben Verzeichnis liegt, wird diese nicht verwendet (ich kann sie während der Laufzeit der exe löschen)
- die erzeugte dll ist binär bis auf wenige Bytes identisch, egal ob mit oder ohne MEMMGR.LIB


Was mache ich falsch? Ich hätte erwartet dass die exe überhaupt nicht startet, wenn die BORLNDMM.dll nicht verfügbar ist?! Muss ich sonst noch irgendwo in den Projekteinstellungen was umsetzen um meiner dll bzw. dem Executable das die dll verwendet zu sagen dass sie BORLNDMM.dll verwenden sollen?

Danke.

[Fred Nest]

Salve,

das was geschrieben steht richtig lesen.
//---------------------------------------------------------------------------
// Wichtiger Hinweis zur DLL-Speicherverwaltung, falls die DLL die statische
// Version der Laufzeitbibliothek (RTL) verwendet:
//
// Wenn die DLL Funktionen exportiert, die String-Objekte (oder Strukturen/
// Klassen, die verschachtelte Strings enthalten) als Parameter oder Funktionsergebnisse übergibt,
// muss die Bibliothek MEMMGR.LIB im DLL-Projekt und anderen Projekten,
// die die DLL verwenden, vorhanden sein. Sie benötigen MEMMGR.LIB auch dann,
// wenn andere Projekte, die die DLL verwenden, new- oder delete-Operationen
// auf Klassen anwenden, die nicht von TObject abgeleitet sind und die aus der DLL exportiert
// werden. Durch das Hinzufügen von MEMMGR.LIB wird die DLL und deren aufrufende EXEs
// angewiesen, BORLNDMM.DLL als Speicherverwaltung zu benutzen. In diesem Fall
// sollte die Datei BORLNDMM.DLL zusammen mit der DLL weitergegeben werden.
//
// Um die Verwendung von BORLNDMM.DLL, zu vermeiden, sollten String-Informationen
// als "char *" oder ShortString-Parameter weitergegeben werden.
//
// Falls die DLL die dynamische Version der RTL verwendet, müssen Sie
// MEMMGR.LIB nicht explizit angeben.
//---------------------------------------------------------------------------

gruß fred

[fruchtmixer]

Hi,

danke für die Antwort. Habs mir jetzt ungefähr 100 mal +-10 durchgelesen und verstehe immer noch nicht was ich falsch mache. Meiner Meinung nach habe ich genau das gemacht, was in dem Text steht. Kannst du mir auf die Sprünge helfen? Danke.

[Fred Nest]

So lange du die oben genannten Dinge nicht zum export benutzt brauchst
du den memorymanager nicht.


Beispiel wo du ihn brauchst :
#ifdef __BUILDING_THE_DLL
#define __EXPORT_TYPE __export
#else
#define __EXPORT_TYPE __import
#endif

extern "C"
{
__declspec( dllexport ) bool starteMeinProgramm( AnsiString par );
}

mfg
Fred

[fruchtmixer]

Hi,

danke für die Antwort. Hatte zu dem Zeitpunkt tatsächlich noch keine Funktion exportiert, die z.B. eine Klasse mit verschachtelten Strings in der Parameterliste haben.

Mein Verständnis bzw. Schlussfolgerung:
- alleine das Hinzufügen von memmgr.lib macht noch nicht wirklich was
- erst, wenn tatsächlich Funktionen exportiert werden deren Parameter in die Kategorie z.B. verschachtelte Strings fallen, ändert sich die dll durch memmgr.lib, und auch nur dann muss ich auch die borlndmm.dll mit der dll weiter geben
- Grundsätzlich sollte es vermieden werden dass man die memmgr.lib hinzufügen muss, weil
1. schlechtere Performance
2. Executables die diese dll verwenden müssen die memmgr.lib auch bei ihren Projekteinstellungen hinzufügen

Noch zwei Fragen zum Schluss:
- Angenommen ich habe jetzt eine dll die zu Recht mit memmgr.lib gelinkt ist. Was ist, wenn ich diese dll von einer Applikation aus verwenden will die mit VS erstellt wurde? Also momentan sieht es halt für mich so aus als ob die dll, sobald sie memmgr.lib und damit auch borlndmm.dll benötigt, nur noch für Projekte verwendbar ist die auch aus dem C++Builder kommen. Oder sehe ich das falsch?

- Ist es dann besser, gegen die dynamische Version der RTL zu linken? Ich meine da tritt das Problem ja nicht auf, aber dafür läuft mein Programm nicht ohne weiteres auf jedem Rechner?

[Fred Nest]

Wenn Du dynamisch Linkst, mußt Du erst recht alle benötigten DLL's mitliefern.

VS vs Borland
Hier mal etwas dazu von mir zusammengetragen

MFC Library erstellen
<impdef patternfind.def patternfind.dll>
danach Unterstriche in der def entfernen
<LIB /DEFatternfind.def /OUTatternfind.lib>

MFC DLL in Borland tauglich umwandeln
<impdef patternfind.def patternfind.dll>

wenn lib von microsoft vorhanden ist dann so :
danach Unterstriche in der def entfernen
<LIB /DEFatternfind.def /OUTatternfind.lib>
danach
<coff2omf -lib:ms patternfind.lib patternfind_.lib>
ansonsten
<implib -a patternfind.lib patternfind.def patternfind.dll>

gruß Fred