Ich möchte mit Visual Basic 6.0 eine DLL erzeugen die in möglichst vielen Programmiersprachen eingebunden werden kann. Nun habe ich herausgefunden, dass ich mit VB6 ActiveX-DLLs erzeugen kann und dass eine ActiveX-DLL mehr Fähigkeiten besitzt als eine "normale" DLL. Aber heißt das, dass man ActiveX-DLLs ohne den Extraschnickschnack auch wie "normale" DLLs einbinden kann? Mit "normal" meine ich zum Beispiel die Windows API DLLs.
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.
Hm schade... Wie hoch mag der Prozentsatz unter den Windows-Programmierern sein, die mit Visual Studio arbeiten? Visual Studio enthält Microsoft Visual Basic, C, C++, C#, F#, J#. 50%? Ich habe keinen Schimmer...
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.
Rufus Τ. Firefly schrieb: > Der Prozentsatz wird hoch sein, aber was hat das mit Deiner > Fragenstellung zu tun? Wenn ich mit VB6 eine ActiveX-DLL erstelle, dann kann die in allen Programmierumgebungen eingebunden werden die ActiveX unterstützen. Ich nehme an, es handelt sich da hauptsächlich um Visual Studio. 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. Machbar? Meinst du mit externer Software oder von Haus aus? Habe noch nichts dazu gefunden. Ich könnte wohl in VB6 eine ActiveX-DLL schreiben und dann mit Visual C++ eine Art Wrapper-DLL schreiben die nur die Funktionsaufrufe an die ActiveX-DLL weitergibt. Aber abgesehen davon dass ich kein C++ kann ist das nicht wirklich schön.
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.
Klingt alles doch halbwegs kompliziert für mich, da muss ich mir wohl mal Zeit zum Einarbeiten nehmen. Habe eben mal bei PowerBasic geguckt. Damit kann man angeblich super einfach super kompatible DLLs erzeugen: "If you use PB/Win or PB/DLL to create a DLL, virtually any computer language can use it. The DLLs that you create with PowerBASIC can be used by Visual Basic, C++, Delphi, and so on. DLLs are the one standard that virtually everybody supports!" http://www.powerbasic.com/support/technote/dlls.asp http://www.powerbasic.com/support/help/pbwin/index.htm -> Creating Dynamic Link Libraries Allerdings werden auf der Seite zugunsten der Einfachheit die technischen Hintergründe verschwiegen. Zur Aufrufkonvention steht da nichts.
Bleibt noch die Frage, warum überhaupt Du eine DLL erzeugen willst. Was soll die tun, und was für Programme sollen die nutzen?
Ein Messgerät mit USB via FTDI und D2XX Treiber soll konfiguriert und ausgelesen werden können. Ansich steht die D2XX.dll schon zur Verfügung, allerdings ist das Übertragungsprotokoll sehr kompliziert und es werden Dinge kommuniziert (z.B. Prüfsummen) mit denen sich der Nutzer nicht rumschlagen müssen soll. Meine DLL vereinfacht das und stellt direkt Funktionen zur Verfügung um Messungen durchzuführen. Das ganze soll möglichst kompatibel sein, da ich noch nicht weiß, wer das mal womit nutzen möchte. Labview z.B. sollte später mal möglich sein. Damit habe ich mich aber noch nicht mit beschäftigt.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.