in VBS auf C++-Libraries zugreifen?

Hi,
ich befasse mich seit kurzen mit der API-Programmierung und habe so schon mit einem Script auf installierte Programme zugreifen können.
Ich habe mal aufgeschnappt, dass es auch möglich sei, DLL-Dateien die C++ Befehle oder Routinen enthalten in VBS einzubinden um so über das Script eben auch die Möglichkeit zu haben, C++ zu programmieren...

Im Netz habe ich zu diesem Thema noch nichts treffendes gefunden und ich frage mich ehrlichgesagt auch, wie das gehen soll...
C++ ohne Interpreter?
Oder is der dann auch in der DLL drin?

So wie ich diese ganze Sache verstanden habe kopiere ich das Script zusammen mit der DLL auf jeden beliebigen Win-XP Rechner und kann dann eben das Script aufrufen, welches in Zusammenarbeit mit der DLL die Befehle ausführt.

Ist es irgendwie möglich, C++ Befehle aus VBS heraus aufzurufen und zu verwenden?

Danke für die Hilfe!

Chris

Du kannst Quellcode in der Programmiersprache C++ schreiben und dann von einem C++-Compiler in Maschinencode übersetzen lassen. Als Endprodukt hast Du dann z.B. exe- oder dll-Dateien. Diese enthalten keine spezifischen C++-Befehle, sondern Code, den der Prozessor ausführen kann.

um so über das Script eben auch die Möglichkeit zu haben, C++ zu programmieren...

Zum Vergrößern anklicken....

Nein, das macht keinen Sinn. Was eine Programmiersprache ausmacht, sind ja Syntax und Konzepte. Du kannst weder direkt noch indirekt in VBS C++ programmieren, ebensowenig wie umgekehrt.

Ist es irgendwie möglich, C++ Befehle aus VBS heraus aufzurufen und zu verwenden?

Zum Vergrößern anklicken....

Vielleicht hast Du eine falsche Vorstellung von C++-Befehlen. Du könntest z.B. in C++ eine Funktion schreiben, die eine Berechnung durchführt und dann eine DLL erzeugen. Aus einem Anwendungsprogramm (geschrieben z.B. in C++, VB (ohne S), Delphi) heraus könntest dann diese Funktion aufrufen. Deswegen hast Du aber in Deinem Anwendungsprogramm keinen C++-Befehl ausgeführt. Genau genommen kann es Dir als Aufrufer sogar ziemlich egal sein, in welcher Programmiersprache die DLL geschrieben wurde, solange bestimmte Konventionen eingehalten werden, z.B. was Parameter angeht.
In VBS kann man allerdings ohnehin keine Funktionen in Standard-(also nicht-COM-)DLLs verwenden, wenn man nicht zu speziellen Hilfsmitteln (*) greift. Aber selbst wenn man es könnte, würdest Du deswegen nicht in C++ programmieren. Wenn Du das möchtest, musst Du Dir einen C++-Compiler besorgen.

// (*) Nachtrag: Falls Du allgemein am Zugriff auf Standard-DLLs von VBS aus interessiert bist und keine Wrapper schreiben willst (Standard-DLL -> COM), suche mal nach DynaCall.

Hey Dings!

Ich danke Dir für Deine ausführliche Erklärung, Du hast einiges Falschwissen in mir korrigieren können. So wie Du es darstellst macht das ganze auch wieder Sinn...

Dh ich erstelle in einer höheren Sprache (sei's jetzt C++ oder Delphi oder VB6.0) eine DLL nach dem COM-standard (kann man das so sagen?) auf die ich dann aus VBS heraus verweisen kann?
Also angenommen (ob das Sinn macht oder nicht sei mal völlig dahin gestellt) ich hätte eine DLL, die einen integer übergeben kriegt, diesen inkrementiert und das Ergebnis zurückgibt, dann könnte ich sagen So, hör mal Du DLL, ich geb Dir hier mal ne 5... was machsten damit? und bekomme eine 6, mit der ich im VBS dann weiterarbeiten kann?

Wenn dem so is scheine ich es endlich verstanden zu haben

Nochmals besten Dank für die Unterstützung!

Chris

Chris08/15 schrieb:

Dh ich erstelle in einer höheren Sprache (sei's jetzt C++ oder Delphi oder VB6.0) eine DLL nach dem COM-standard (kann man das so sagen?) auf die ich dann aus VBS heraus verweisen kann?

Zum Vergrößern anklicken....

Ja, das kann man so sagen.

und bekomme eine 6, mit der ich im VBS dann weiterarbeiten kann?

Zum Vergrößern anklicken....

Genau. Berechnungen, Datenbankzugriffe oder was immer Deine DLL kann.

kopiere ich das Script zusammen mit der DLL auf jeden beliebigen Win-XP Rechner

Zum Vergrößern anklicken....

Kopieren reicht bei COM-DLLs übrigens nicht (im Gegensatz zu Standard-DLLs). Informationen über die COM-Komponente müssen in sich in der Registry befinden. Das kann man unter anderem über das Tool regsvr32 erreichen. Davon hast Du sicher schon öfter im Zusammenhang mit der Lösung von Windows-Problemen gelesen. Dieses Tool ruft einfach eine Funktion in der DLL auf, welche dann die nötigen Daten in die Registry schreibt (sofern die DLL diese spezielle Funktion enthält, was aber bei COM-DLLs die Regel ist) oder die Einträge wieder entfernt. Wenn Du in VBScript mit->CreateObject' ein Objekt erzeugst, weiss Windows wegen eben dieser Einträge, wo es nach der Komponente suchen muss.
Klappe mal in RegEdit HKEY_CLASSES_ROOT auf und scrolle runter. Dort siehst Du COM bis zum Abwinken ... Allerdings stehen die Namen der DLLs nicht direkt in diesen Root-Einträgen; die CLSIDs (welche z.B. so aussehen: {A6A6F92B-26B5-463B-AE0D-5F361B09C171}) darin verweisen auf - um das Wort Einträge nicht so zu strapazieren - Schlüssel in HKEY_CLASSES_ROOT/CLSID.

meines wissens geht das nicht mit dlls sondern nur mit ocx (activex-elemente).

Wow.... so langsam wird mir EINIGES klar...
Ich glaub, ich hab das alles jetzt schon recht gut verstanden... nur noch eine Sache...
Wenn ich ein Create Object in VBS mache nenne ich dieses Objekt ja beim Namen und nicht bei der CLSID... dh ich muss meine DLL benennen und muss dafür Sorge tragen, dass dieser Name auch in der Registry steht...
Meine Vermutung wäre jetzt, dass der Name des Objektes (logischerweise) in der DLL steht und beim Regsvr32 mit in die Registry übernommen wird... und der Rechner dann weiß, wo er gucken muss, wenn ich ein Objekt createn will... aber was, wenn ich mein Objekt so nenne wie eins, dass es schon gibt? Wird das alte dann überschrieben?

1000 Dank!

Chris