Moin,
ich habe eine DLL mit der ich arbeiten möchte, mir fehlt dazu aber der Header, ich kenne also die enhaltenen Funktionen und deren Übergabeparameter nicht. Wenn ich sie so in LV einbinde habe ich schonmal die Möglichkeit die Funktion auszuwählen. Wie oder woher bekomme ich nun die Parameter? Gibt es da irgendwie eine Möglichkeit? (Ich bin mir dessen bewusst das man eine DLL nicht öffnen kann, das wäre zu einfach)
Gruß
Daniel
Edit: Ups, hab mich im Unterforum verklickt, bitte verschieben!
Hallo Daniel,
einfach den Programmierer der DLL fragen? Der sollte es schließlich wissen...
Ja ... das is mir klar, geht aber um eine Windows DLL. Mcirosoft verät aber nicht so wirklich viel darüber.
Hallo Daniel,
wenn µSoft nicht soviel darüber verrät, werden sie ihre Gründe dafür haben (heißt: die DLL ist quasi "privat"). Oder du hast nicht tief genug im MSDN gebuddelt
Ja aber kann man das nicht mittracen oder sowas? Also ich kann die DLL über ein VB-Skript aufrufen, jetzt müsste ich mir nur noch die Kommunikation zwischen diesem Skript und dem DLL Aufruf an sich beobachten. GIbt es dafür nen Tool? Ich weiß das Excel zumindestens VB beherrscht... betonung liegt dabei allerdings auf "Excel beherrscht das".
Hallo Daniel,
ich glaube, es wird Zeit, dass du uns den Namen dieser µSoft-DLL nennst und würde damit an den DLL-Spezialisten rolfk übergeben
Es geht um die w3svc.dll die ich momentan nur über das adsutil.vbs (und das über das cscript) öffne.
Gibt es vielleicht die Möglichkeit via .NET auf die Klassen der DLL zu zugreifen, solange diese public sind natürlich?
(20.10.2011 09:23 )M@rRy schrieb: [ -> ]Es geht um die w3svc.dll die ich momentan nur über das adsutil.vbs (und das über das cscript) öffne.
Also grundsätzlich gibt es keine Möglichkeit um eine DLL anzurufen, von der man nicht zumindest die Funktionsinterfaces kennt. Die einzige Art und Weise um diese Informationen zu erhalten, wenn man keine Dokumentation oder Header dazu hat, ist die DLL zu dissassemblieren. Das ist ein ziemlich arbeitsintensiver Prozess und im Zeitalter der Informationsfreiheit meistens auch eine illegale Aktion. Zumindest fúr jemanden der in Amerika wohnt oder in nächster Zeit dorthin reisen möchte ist davon nur abzuraten.
Das alles gesagt ist natürlich auch der Nutzen abzuschätzen. Undokumentierte DLL Interfaces sind dies manchmal aus Konkurrenzüberlegungen, aber Microsoft wird sich in dieser Hinsicht wohl etwas zurückhalten da solche Machenschaften in der Vergangenheit ziemlich schwer bebüsst wurden. Ein anderer und viel häufiger vorkommender Grund ist dass das Interface privat ist, weil es kein festes Interface ist, sondern konstant verändern kann. Da es privat ist kann man das tun ohne andere Programmierer zu verärgern. Hat ein Aussenstehender dieses Interface reverse engineered dann hat er halt einfach Pech gehabt.
In diesem spezifischen Fall geht es um eine DLL die Bestandteil der Internet Information Services ist und einen Service implementiert. Ein Service hat meist kein klassisches DLL Interface, sondern wird über COM/DCOM angesprochen. Das sieht man bei einer DLL auch daran, dass DLLRegisterServer() und DLLUnregisterServer() exportiert sind. COM/DCOM ist die Technologie auf der ActiveX aufgebaut ist, aber ist nicht genügend um eine DLL als ActiveX Componente anzusprechen. Das heist das Interface dieser DLL ist NUR durch ein C/C++ Program anzusprechen und auch dann nur wenn man die entsprechenden Interface Definitions (meist IDL Files und daraus generierte C Headers und RPC Proxy Source Files) hat. Diese werden üblicherwiese in einem entsprechendem SDK geliefert, so sie nicht Bestandteil des Microsoft Platform SDKs sind. Oder auch nicht, wenn die DLL als Teil eines grösseren Ganzen aufgefasst wird, das die Funktionen mittels eines übergeordneten Interfaces zur Verfügung stellt.
Die einzigen anderen Funktionen die von dieser DLL exportiert werden sind C++ Objectmethoden, etwas das man mit der LabVIEW Call Library Node grundsätzlich nicht gut aufrufen kann.
Also kann man zusammengefasst sagen: Direkt ansprechen dieser DLL von LabVIEW aus ist ein sinnloses Unterfangen. Sehr wahrscheinlich stellt Microsoft Teile der Funktionalität mittels eines ActiveX Interfaces in einer höher liegenden Komponente zur Verfügung. Welche das ist kann ich Dir nicht sagen, aber es hat sicher mit Internet Information Services (IIS) zu tun. Auch möglich ist das dieser Service nicht nur über ein ActiveX Interface sondern auch über ein Funktions-API ansprechbar ist. Dieses API würde aber meistens ebenfalls durch eine andere Komponente bereitgestellt und nicht die Service DLL selber.
Wow vielen Dank für diese ausführliche Erläuterung, ist immer wieder interessant und lehrreich deine posts zu lesen und zu verstehen! Danke Rolf und natürlich auch Gerd
Gruß
Daniel