DLL mit Visual Basic erzeugen

Du kannst sie dann per ActiveX einbinden, aber nicht als "normale"
DLL in dem Sinn, daß du ihre Funktionen mit GetProcAdress holst und
direkt mit Parametern aufrufst, weil die Aufrufkonventionen von
BASIC sicher anders sind als bei anderen Sprachen wie C.

Der Prozentsatz wird hoch sein, aber was hat das mit Deiner 
Fragenstellung zu tun?

Der Prozentsatz unter den Windows-Programmierern, die VB6 nutzen, der 
dürfte allerdings immer geringer werden, VB6 ist mit bald 13 Jahren 
Alter etwas angestaubt.

ActiveX ist glaube ich auch schon etwas in die Jahre gekommen.
Am universellsten funktionieren meines Wissens nach einfache Win32 MFC 
DLLs, also alles ohne schnick schnack, müsste mit Visual Basic machbar 
sein.
Die brauchen kein ActiveX und kein .net zum Laufen, vlt laufen die dann 
sogar mit Java usw., hab ich noch nie probiert.

Leonard Doyle schrieb:
> Am universellsten funktionieren meines Wissens nach einfache Win32 MFC
> DLLs, also alles ohne schnick schnack, müsste mit Visual Basic machbar
> sein.

Das dürfte ein Missverständnis sein. "MFC DLLs" sind in C++ geschriebene 
DLLs, die die MFC-Klassenbibliothek nutzen. C++-DLLs sind, wenn man 
keinen zusätzlichen Aufwand treibt, bereits mit einem anderen 
C++-Compiler nur schwer zu nutzen, da das "name mangling" der 
Symbolnamen sich auch auf die Prozedureinsprungpunkte der DLL auswirkt. 
Sofern nicht eine Klassenimplementierung exportiert wird, sondern nur 
statische Memberfunktionen, dann kann mit einer in C++ geschriebenen DLL 
auch aus anderen Programmiersprachen heraus gearbeitet werden, wichtig 
ist aber die Verwendung einer Definitionsdatei, um verständliche Namen 
für die Prozedureinsprungspunkte in der DLL ohne "name mangling" zu 
erhalten.

Das mit den C/C++-Compilern von MS gelieferte Tool dumpbin ist zur 
Untersuchung dieser Sachverhalte sehr praktisch.

Mit VB können solche DLLs überhaupt nicht erzeugt werden, da VB keinen 
C++-Compiler enthält.

Um eine möglichst universell verwendbare DLL zu erzeugen, muss darauf 
geachtet werden, daß sowohl die verwendeten symbolischen Namen keine 
Probleme bereiten als auch, daß von den üblichen Programmiesprachen 
nutzbare Datentypen verwendet werden. Bereits die unterschiedliche 
Handhabung von Strings zwischen C und VB macht die Angelegenheit nicht 
einfach.

Die Verwendung von ActiveX/COM vereinfacht dies, da hier die 
Aufrufkonventionen und auch zu verwendenden Datentypen klar und 
sprachunabhängig definiert sind, nur bringt ActiveX/COM andere Probleme 
mit sich; es macht überhaupt keinen Spaß, so etwas aus C heraus zu 
nutzen.

Rufus Τ. Firefly schrieb:
> C++-DLLs sind, wenn man
> keinen zusätzlichen Aufwand treibt, bereits mit einem anderen
> C++-Compiler nur schwer zu nutzen, da das "name mangling" der
> Symbolnamen sich auch auf die Prozedureinsprungpunkte der DLL auswirkt.
> Sofern nicht eine Klassenimplementierung exportiert wird, sondern nur
> statische Memberfunktionen, dann kann mit einer in C++ geschriebenen DLL
> auch aus anderen Programmiersprachen heraus gearbeitet werden, wichtig
> ist aber die Verwendung einer Definitionsdatei, um verständliche Namen
> für die Prozedureinsprungspunkte in der DLL ohne "name mangling" zu
> erhalten.

Ergänzuung:
Solange man nicht wirklich bereits in der Schnittstelle C++ mit
Objektorientierung braucht, sondern ggf. nur innerhalb der DLL,
reicht die Deklaration aller von außen sichtbaren Funktionen
mit extern "C". Dann findet auch kein name mangling statt.

Bleibt noch die Frage, warum überhaupt Du eine DLL erzeugen willst. 
Was soll die tun, und was für Programme sollen die nutzen?