(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.
