Herzlich Willkommen, lieber Gast!
  Sie befinden sich hier:

  Forum » C / C++ (ANSI-Standard) » Auf Dlls zugreifen

Forum | Hilfe | Team | Links | Impressum | > Suche < | Mitglieder | Registrieren | Einloggen
  Quicklinks: MSDN-Online || STL || clib Reference Grundlagen || Literatur || E-Books || Zubehör || > F.A.Q. < || Downloads   

Autor Thread - Seiten: > 1 < [ 2 ] [ 3 ]
000
23.09.2003, 20:44 Uhr
~Einsteiger
Gast


Hallo!

Habe 2 Fragen zu DLLs:

1) In C(++) erhält man den Zugriff auf DLL ja durch Headerdateien. DLLs werden dann ja (wie der Name schon sagt) dynamisch eingebunden.
Wieso muss man trotzdem für den Linker noch statische Library-Dateien eintragen? Sollten nicht alle notwendigen Informationen für den DLL-Zugriff schon in der Headerdatei stehen?


2) Wie schon oben beschrieben wird in C(++) über Headerdateien auf DLLs zugegriffen. In VB wird aber die DLL selbst angegeben (mit der Declare Function-Anweisung).
Gibt es da (abgesehen von der Syntax) irgendwelche technischen Unterschiede, die mich als Programmierer interessieren sollten?

Danke!

mfg
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
001
23.09.2003, 21:15 Uhr
Windalf
Der wo fast so viele Posts wie FloSoft...
(Operator)


Dieser Thread sollte dir deine Frage beantworten
--
...fleißig wie zwei Weißbrote

Dieser Post wurde am 23.09.2003 um 21:15 Uhr von Windalf editiert.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
002
24.09.2003, 12:25 Uhr
RHBaum



Der referenzierte Thread "erklaert" Dir die Zusammenhaenge, naja auf ein sehr Einsteigerfreundlichen Niveau ! :-) Ist nicht Falsch, aber auch ned die ganze Wahrheit (aber wer will die Schon wissen )


Zitat:

Wieso muss man trotzdem für den Linker noch statische Library-Dateien eintragen?

Man muss nicht ! Man kann Dll aufrufe auch direkt ausm Code ohne Lib realisieren ! Nur ist das umstaendlich und nicht schoen. Die M$ Entwicklungsumgebung nimmt diese Last ab, und generiert Dir diese Lib, damit es einfacher verwenden kannst.
Ausserdem wirst du wissen, das dll's nur flache C-Funktionen Exportieren koennen, aber VS C++ ne "Objektorientierte Umgebung" ist. Vermutlich hauptsaechlichst Grund hat M$ diesen Mechanismus entwickelt, damit du "Klassen" in Dlls auslagern kannst, obwohl das eigentlich nicht gehen duerfte ! die Stubs in der Lib nehmen diese Transformation fuer dich dann vor.
Stichwort "Mfc Erweiterungs -Dll" !

so sehe COde aus, wenn du direkt ne Dll aufrufst !

C++:
typedef unsigned long (__stdcall DLLMAPISendMail)(LHANDLE lhSession,ULONG ulUIParam,lpMapiMessage lpMessage,FLAGS flFlags,ULONG ulReserved);
    DLLMAPISendMail * pMAPISendMail;
    HINSTANCE hi;
    hi = ::LoadLibrary("MAPI32.DLL");
    pMAPISendMail =  (DLLMAPISendMail * )::GetProcAddress(hi,"MAPISendMail");

    CMapiMessageAdapter MyMapiStruct;
    MyMapiStruct.set_Text(m_strText);
    MyMapiStruct.set_Subject(m_strSubject);
    MyMapiStruct.set_Recipients(m_plSendTo,m_plCC);
    FLAGS flFlags = MAPI_NEW_SESSION;
    if(m_bForceDialog)
    {
        flFlags = flFlags | MAPI_DIALOG ;
    }
    unsigned long lreturn = (*pMAPISendMail)(NULL,NULL,MyMapiStruct.GetMessageStructPtr(),flFlags,NULL);



Ciao ...
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
003
24.09.2003, 12:56 Uhr
virtual
Sexiest Bit alive
(Operator)



Zitat:

Man muss nicht ! Man kann Dll aufrufe auch direkt ausm Code ohne Lib realisieren ! Nur ist das umstaendlich und nicht schoen. Die M$ Entwicklungsumgebung nimmt diese Last ab, und generiert Dir diese Lib, damit es einfacher verwenden kannst.


Ja, kann man, nur ist das kein Existentzgrund für die Lib Dateien. Das ist einfach das dynamische Laden einer DLL gegensatz zum statischen referenzieren.

Zitat:

Ausserdem wirst du wissen, das dll's nur flache C-Funktionen Exportieren koennen, aber VS C++ ne "Objektorientierte Umgebung" ist. Vermutlich hauptsaechlichst Grund hat M$ diesen Mechanismus entwickelt, damit du "Klassen" in Dlls auslagern kannst, obwohl das eigentlich nicht gehen duerfte ! die Stubs in der Lib nehmen diese Transformation fuer dich dann vor.
Stichwort "Mfc Erweiterungs -Dll" !


Klar kannst Du auch Klassen exportieren bzw Funktionen mit C++ Linkage, warum sollte das nicht gehen? Da wird auch nicht mehr transformiert als bei einer normalen C Funktion auch, weil die Namen der Methoden den Namemangling unterliegen (was allerings nichts mit DLLs zu tun hat, sondern mit Linken im Allgemeinen). Bei VC (vielleicht auch BCB) muß man halt das dll-import bzw. export in der Klassendeklaration verwenden:

C++:
class __declspec(...) Klasse
{
};


Du kannst auf die ImportLibraries komplett verzichten und nur mit DLLs arbeiten, wenn du unter Windows zB den gcc Port verwendest (der braucht auch diesen import/export Kram nicht, wenn ich mich recht entsinne).

Ich denke daher, daß sich MS die ImportLibs ausgedacht hat, um explizit spezifieren zu können, was zum Interface gehört und was nicht. Denn wenn Du zB mit dem gcc eine DLL baust, wird gnadenlos alles exportiert, was verfügbar ist; im Zusammenhang mit Klassen kannst Du also keine Klassen verbergen, die nur für Interne Zwecke gedacht sind.
--
Gruß, virtual
Quote of the Month
Ich eß' nur was ein Gesicht hat (Creme 21)
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
004
24.09.2003, 13:19 Uhr
FloSoft
Medialer Over-Flow
(Administrator)


was haben DLL's eigentlich mit ANSI zu tun?
--
class God : public ChuckNorris { };
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
005
24.09.2003, 13:37 Uhr
RHBaum



Aehhh ?
Wie bitte Exportiere ich ne Klasse aus ner DLL ?

Du meinst also, zb eine Funktion mit der Signatur int ToUpper(std::string s) koenntest ueber die Schnittstelle Schicken. Vorausgesetzt dein Programm und auch die DLL kennt die STL ?

Oder DU definierst und implementierst ne Klasse CMyclass in ner dll, und exportierst die Klasse, so dass in deinem Programm nur die Dll einbinden (LoadLibrary) und die H.Datei includieren musst ?
Und Du dann nur noch nen new auf die Klasse aufrufst, wo der komplette Konstruktur und Destruktor in der Dll sind ?

Ohne verwendung einer Stub-Lib ?

Oder reden wir hier grad aneinander vorbei ?

Meiner Meinung nach kann man keine Klassen ueber C-Schnittstellen schicken ! normal wuesste der Compiler meckern, wenn in ner __declspec deklarierten Function ne Klasse vorkommt. Weil du keine Verbindung von Code und Daten in C definieren kannst ! Also muesst dich mit reinen Pointern oder Handlern behelfen.


Zitat:

Ich denke daher, daß sich MS die ImportLibs ausgedacht hat, um explizit spezifieren zu können, was zum Interface gehört und was nicht.


Jede Exportierte Funktion in ner Dll muss nen eintrag in der Export map haben, mit namen / ID. Fuer funktionen die dem Anwender nicht goennen magst, legst einfach keinen an ... dann kann er sich mit GetProcAdress dämlich suchen :-)

Dlls haben nix mit ANSI zu tun, deshalb gehoert dieses Posting auch in nen Windows Aber nicht Mfc Only forum ! WinAPI forum waer passend !

Ciao ...

Dieser Post wurde am 24.09.2003 um 13:47 Uhr von RHBaum editiert.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
006
24.09.2003, 14:04 Uhr
virtual
Sexiest Bit alive
(Operator)


@RHBaum.

Bei Klassen, die ich mit dem VC Kompilieren muß, und als DLL verwende schreibe ich:

C++:
/* Klasse.h */
#ifndef KLASSE_INCLUDED_H
#define KLASSE_INCLUDED_H

#ifdef MYDLLPREFIX
#    undef MYDLLPREFIX
#endif

#ifdef _WIN32
#    ifdef IMPLEMENT_MYDLL
#        define MYDLLPREFIX __declspec(dllexport)
#    else
#        define MYDLLPREFIX __declspec(dllimport)
#    endif
#else
#        define MYDLLPREFIX
#endif

class MYDLLPREFIX Klasse
{
...
};

#endif


und

C++:
/* Klasse.cpp */
#define IMPLEMENT_MYDLL
#include "Klasse.h"
....


Das ganze als DLL bauen und du bekommst eine DLL, wo alle Methoden in der ImportLib stehen (in der DLL natürlich auch) und du kannst sie normal dazu linken, wie jede andere Lib auch. Der ganze define Kram im Header wird natürlich einfacher, wenn Du nur unter Windows arbeitest, dann kannst du auf den switch "#ifdef _WIN32" und den else branch verzichten.

Nur ist das wie gesagt kein muß: andere Kompiler/Linker brauchen den ganzen Quatsch nicht und kommen sogar ohne ImportLib aus. Ist ja bei näherer betrachtung auch nicht notwendig:

Der Linker merkt anhand der Linkliste, welcher Art die Library ist (statisch oder dynamisch) und der Header enthält die Signatur der Funktion/Methode. Damit sind eigentlich alle notwendigen Daten vorhanden, um einen Call in der obj-Datei richtig aufzulösen. Alles andere ist Redundanz, wozu auch immer gedacht.
--
Gruß, virtual
Quote of the Month
Ich eß' nur was ein Gesicht hat (Creme 21)

Dieser Post wurde am 24.09.2003 um 14:06 Uhr von virtual editiert.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
007
24.09.2003, 14:29 Uhr
RHBaum



Hab ich jetzt nen Blackout ?

[Quote]
Der Linker merkt anhand der Linkliste, welcher Art die Library ist
[/Quote]
Noe, dem Linker und dem Compiler musst schon sagen, Ich kompilier jetzt eine DLL ... dann legt er die Export map an ... die DLL hat etwas mehr Inhalt als ne Lib. Die lib(Statisch) benutzt Symbole, wo deine Funktionen drauf verweisen ... und die lib ist ja mit deinem Binary gelinkt, also soweiso immer geladen ....

Ne DLL ist meist nicht geladen, das ist ja auch der SInn. ALso musst du die DLL erst mal laden, oder wenn jemand anders die Schon angezogen hat, dir die Startadresse (wird vom BS festgelegt, gibt nen richtwert, denn bei der Erstellung der DLL angibst, ist aber nicht sichergestellt, das die dann dort auch eingeblendet ist) holen. Die Exportmap startet auch an ner ganz bestimmten stelle ... und du musst dir mit getProcAdress uber den namen oder der ID erst mal die Startadresse deiner Funktion holen .... weil die sich ja geaendert haben kann (dll neu kompiliert, programm nicht, abwaertskompatiblitaet. ) also kann das Programm keine Festen Symbole verwenden, wie bei der Festverlinkten Lib.
deshalb musst auch die verenkungen machen, um ne Dll geladen zu bekommen.

Und ich behaupte immer noch, eine Klasse bekommst nicht ueber ne DLL Schnittstelle Rueber.
Zum ersten, weil es keine GetClassAdress fuer DLLS gibt .... Und getProcAdress gibt dir immer nur nen Pointer auf ne Function zrueck. Und das ist das einzigste was dir die Dll Schnittstelle bietet !

In ner LIB und in deinem binary verweist du auf ne Klassendefinition mittels den Symbolen. Also Instanz = adresse der Daten + Symbol der Klassendefinition. Bei ner DLL geht das ned, weil Binary und Library getrennt kompiliert werden. Also ne Klassendefinition mit selben Symbol unterschiedliche Signaturen in Binary und Dll haben kann. Und, die Selbe Klassendefinition kann in Binary und Dll ne unterschiedliches Symbol haben ...

Ne Ubergabe von DatenAdresse + Klassensymbol kann also chaos verursachen, und ist nicht gewollt, weil dll version und programm version sonst fest miteinander Verknuepft werden muessten ....

Intern innerhalb der Dll kannst ne Klasse verwenden, weil innerhalb die dll in sich auch mit symbolen arbeitet.
Wenn die Klasse in deiner .H zu der DLL definierst und implementierst, kannst die Klasse auch im aufrufenden Porgramm verwenden, klar, aber die Klasse selber darf niemals Teil einer Funktionssignatur sein !!! Dann knallts !

Ciao ...

Dieser Post wurde am 24.09.2003 um 14:40 Uhr von RHBaum editiert.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
008
24.09.2003, 14:57 Uhr
virtual
Sexiest Bit alive
(Operator)



Zitat:
RHBaum postete
Hab ich jetzt nen Blackout ?



Offenbar,


Zitat:
RHBaum postete
Noe, dem Linker und dem Compiler musst schon sagen, Ich kompilier jetzt eine DLL ... dann legt er die Export map an ... die DLL hat etwas mehr Inhalt als ne Lib. Die lib(Statisch) benutzt Symbole, wo deine Funktionen drauf verweisen ... und die lib ist ja mit deinem Binary gelinkt, also soweiso immer geladen ....


Zum dritten mal: Die Welt betseht aus mehr als nur der VC. Es gibt Compiler/Linker, die benötigen unter Windows importLibs. ja. Der VC gehört dazu. Auch ja.
Aber: es gibt compiler, die ohne auskommen, ohne den Ganzen quatsch. Ein Beispiel zum Mitmachen? - Okay (sehr vereinfacht, aber funtionierend, wenn man den cygwin Port des gcc hat):

C++:
/* dll.h */
class A
{
public:
    A();
};



C++:
/* dll.cpp */
#include "dll.h"
#include<iostream>

A::A()
{
    std::cout<<"A::A"<<std::endl;
}


Das ganze so zusammenbauen:

Code:
g++ -odll.dll -shared dll.cpp


Kommt ne DLL raus, ohne ImportLibrary. Der Dependency Wolker wird dir bestätigen, daß der ctor exportiert wurde. Nun testen obs klappt:

C++:
/*testprg.cpp */
#include "dll.h"

int main()
{
    A a;
}


Und zusammenlinken:

Code:
g++ -ldll -L. -otestprg testprg.cpp


Fertig. Im Dependency walker siehst du, daß testprg aus dll.dll seinen ctor holt.

Zitat:
RHBaum postete
Ne DLL ist meist nicht geladen, das ist ja auch der SInn. ALso musst du die DLL erst mal laden, oder wenn jemand anders die Schon angezogen hat, dir die Startadresse (wird vom BS festgelegt, gibt nen richtwert, denn bei der Erstellung der DLL angibst, ist aber nicht sichergestellt, das die dann dort auch eingeblendet ist) holen. Die Exportmap startet auch an ner ganz bestimmten stelle ... und du musst dir mit getProcAdress uber den namen oder der ID erst mal die Startadresse deiner Funktion holen .... weil die sich ja geaendert haben kann (dll neu kompiliert, programm nicht, abwaertskompatiblitaet. ) also kann das Programm keine Festen Symbole verwenden, wie bei der Festverlinkten Lib.
deshalb musst auch die verenkungen machen, um ne Dll geladen zu bekommen.


Quatsch. Wie gesehen, Du musst Verrenkungen machen, weil du den VC benutzt.

Zitat:
RHBaum postete
Und ich behaupte immer noch, eine Klasse bekommst nicht ueber ne DLL Schnittstelle Rueber.
...


Ich fände es gut, wenn du diese Behauptung untermauern könntest. Bereits im Post zuvor habe ich dir sogar schon ein Beispiel genannt, wie man es mit dem VC schafft (nämlich über ImportLib, was beim VC immer gebraucht wird).
--
Gruß, virtual
Quote of the Month
Ich eß' nur was ein Gesicht hat (Creme 21)
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
009
24.09.2003, 21:37 Uhr
~(un)wissender
Gast


Hat eine dll eigentlich Performancenachteile?
Doch zumindest in der extra Ladephase, oder?
Ansonsten ist das Icon cool in WinXp für .dll-Dateien, alleine deshalb sollte man alles zudlln
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
Seiten: > 1 < [ 2 ] [ 3 ]     [ C / C++ (ANSI-Standard) ]  


ThWBoard 2.73 FloSoft-Edition
© by Paul Baecher & Felix Gonschorek (www.thwboard.de)

Anpassungen des Forums
© by Flo-Soft (www.flo-soft.de)

Sie sind Besucher: