Einbinden einer DLL in AutoIT (VMware VIX)

  • Moin Moin,

    nachdem ich bereits einiges mit AutoIT lösen konnte wollte ich nun mehr mit VMware (konkret ESX Host's) machen. Natürlich könnte ich die schon diversen Kommandozeilenbefehle wie z.B. "vmrun.exe" einfach fernsteuern - aber für kompliziertere Abfragen und Prüfungen taugt das nichts.

    VMware stellt für alle Produkte die "VMware VIX API" zur Verfügung: http://www.vmware.com/support/developer/vix-api/

    Die API stellt einige DLL Dateien zur Verfügung - und die Funktionen darin sind scheinbar gut Dokumentiert.

    Ich habe versucht mir das ganze bei anderen UDF's ab zu schauen (GDIPlus z.B.) ... aber im Moment stürzt die AutoIT Engine beim Testen einfach ab ...

    Was habe ich bisher gemacht:
    - In der API ist eine "vix.dll" in der die Funktionen sind
    - in der "vix.h" stehen die Aufrufe dazu
    - die ganzen Konstanten aus der "vix.h" habe ich einfach übernommen:


    vorher:

    Spoiler anzeigen
    [autoit]


    typedef int VixServiceProvider;
    enum {
    VIX_SERVICEPROVIDER_DEFAULT = 1,
    VIX_SERVICEPROVIDER_VMWARE_SERVER = 2,
    VIX_SERVICEPROVIDER_VMWARE_WORKSTATION = 3,
    VIX_SERVICEPROVIDER_VMWARE_PLAYER = 4,
    VIX_SERVICEPROVIDER_VMWARE_VI_SERVER = 10,
    };

    [/autoit]

    nacher (also in AutoIT)

    Spoiler anzeigen
    [autoit]


    ;typedef int VixServiceProvider;
    Dim Const $VIX_SERVICEPROVIDER_DEFAULT = 1
    Dim Const $VIX_SERVICEPROVIDER_VMWARE_SERVER = 2
    Dim Const $VIX_SERVICEPROVIDER_VMWARE_WORKSTATION = 3
    Dim Const $VIX_SERVICEPROVIDER_VMWARE_PLAYER = 4
    Dim Const $VIX_SERVICEPROVIDER_VMWARE_VI_SERVER = 10

    [/autoit]

    Nun wollte ich die DLL Funktionen in eine AutoIT Funktion packen:

    vorher:

    Spoiler anzeigen
    [autoit]


    VixHandle VixHost_Connect(int apiVersion,
    VixServiceProvider hostType,
    const char *hostName,
    int hostPort,
    const char *userName,
    const char *password,
    VixHostOptions options,
    VixHandle propertyListHandle,
    VixEventProc *callbackProc,
    void *clientData);

    [/autoit]

    Die Beschreibung hierzu laut Hilfe:

    Spoiler anzeigen
    [autoit]


    Parameters
    apiVersion Must be VIX_API_VERSION.

    hostType With vCenter Server, ESX/ESXi hosts, and VMware Server 2.0, use VIX_SERVICEPROVIDER_VMWARE_VI_SERVER.
    With VMware Workstation, use VIX_SERVICEPROVIDER_VMWARE_WORKSTATION.
    With VMware Player, use VIX_SERVICEPROVIDER_VMWARE_PLAYER.
    With VMware Server 1.0.x, use VIX_SERVICEPROVIDER_VMWARE_SERVER.

    [/autoit] [autoit][/autoit] [autoit]

    hostName Varies by product platform.
    With vCenter Server, ESX/ESXi hosts, and VMware Server 2.0, use a URL of the
    form "https://<hostName>:<port>/sdk" where <hostName> is either the DNS name or IP address.
    If missing, <port> may default to 443 (see Remarks below).
    In VIX API 1.10 and later, you can omit "https://" and "/sdk" specifying just the DNS name or IP address.
    Credentials are required even for connections made locally.
    With Workstation, use NULL to connect to the local host.
    With VMware Server 1.0.x, use the DNS name or IP address for remote connections, or the same as Workstation for local connections.

    [/autoit] [autoit][/autoit] [autoit]

    hostPort TCP/IP port on the remote host. With VMware Workstation and VMware Player, use zero for the local host.
    With ESX/ESXi hosts and VMware Server 2.0 you specify port number within the hostName parameter, so this parameter is ignored (see Remarks below).

    [/autoit] [autoit][/autoit] [autoit]

    login Username for authentication on the remote machine. With VMware Workstation, VMware Player, and VMware Server 1.0.x, use NULL to authenticate as the current user on local host.
    With vCenter Server, ESX/ESXi hosts, and VMware Server 2.0, you must use a valid login.

    [/autoit] [autoit][/autoit] [autoit]

    password Password for authentication on the remote machine. With VMware Workstation, VMware Player, and VMware Server 1.0.x, use NULL to authenticate as the current user on local host.
    With ESX/ESXi and VMware Server 2.0, you must use a valid login.

    [/autoit] [autoit][/autoit] [autoit]

    options Should be zero. The option VIX_HOSTOPTION_USE_EVENT_PUMP has been deprecated and may be removed from future versions of the VIX API.

    [/autoit] [autoit][/autoit] [autoit]

    propertyListHandle Must be VIX_INVALID_HANDLE.

    [/autoit] [autoit][/autoit] [autoit]

    callbackProc Optional callback of type VixEventProc.

    [/autoit] [autoit][/autoit] [autoit]

    clientData Optional user supplied opaque data to be passed to optional callback.

    [/autoit] [autoit][/autoit] [autoit][/autoit] [autoit]

    Return Value A job handle. When the job completes, retrieve the Host handle from the job handle using the VIX_PROPERTY_JOB_RESULT_HANDLE property.

    [/autoit]

    In einem Funktionsaufruf habe ich es so versucht: (2 Funktionen)

    Spoiler anzeigen
    [autoit]


    Dim Const $VIX_PROPERTY_NONE = 0
    Dim Const $VIX_API_VERSION = -1
    Dim Const $VIX_INVALID_HANDLE = 0
    Dim Const $VIX_PROPERTY_JOB_RESULT_HANDLE = 3010

    [/autoit] [autoit][/autoit] [autoit]

    Func _vmware_VixHost_Connect($hostType, $hostName, $hostPort, $userName, $password, $options)
    Local $HostHandle = DllCall("vix.dll","INT_PTR","VixHost_Connect", "INT_PTR", $VIX_API_VERSION, "int", $hostType, "str", $hostName, "int", $hostPort, "str", $userName, "str", $password, "int", 0, "int", $VIX_INVALID_HANDLE, "int", 0, "int", 0)
    If @error Then Return SetError(-65535)
    Return SetExtended(0,$hostHandle)
    EndFunc

    [/autoit] [autoit][/autoit] [autoit]

    Func _vmware_VixJob_Wait($jobHandle,$hostHandle)
    Local $VixError = DllCall("vix.dll","INT_PTR","VixJob_Wait","INT_PTR",$jobHandle,"INT",$VIX_PROPERTY_JOB_RESULT_HANDLE,"INT_PTR",$hostHandle,"int",$VIX_PROPERTY_NONE)
    If @error Then Return SetError(-65535)
    Return SetExtended(0,$VixError)
    EndFunc

    [/autoit]

    Im Beispiel von denen sieht der Aufruf so aus:

    Spoiler anzeigen
    [autoit]


    Example
    #include "vix.h"
    int main(int argc, char * argv[])
    {
    VixHandle hostHandle = VIX_INVALID_HANDLE;
    VixHandle jobHandle = VIX_INVALID_HANDLE;
    VixError err;
    // Connect as current user on local host.
    jobHandle = VixHost_Connect(VIX_API_VERSION,
    VIX_SERVICEPROVIDER_VMWARE_VI_SERVER,
    "https://viserver.example.com/sdk", // hostName
    0, // hostPort
    "Administrator", // userName
    "adminpass", // password,
    0, // options
    VIX_INVALID_HANDLE, // propertyListHandle
    NULL, // callbackProc
    NULL); // clientData
    err = VixJob_Wait(jobHandle,
    VIX_PROPERTY_JOB_RESULT_HANDLE,
    &hostHandle,
    VIX_PROPERTY_NONE);
    if (VIX_OK != err) {
    // Handle the error...
    goto abort;
    }
    Vix_ReleaseHandle(jobHandle);
    // Other code goes here...
    abort:
    Vix_ReleaseHandle(jobHandle);
    VixHost_Disconnect(hostHandle);
    }

    [/autoit]

    ich versuche nun es so:

    Spoiler anzeigen
    [autoit]


    Dim $ESXHostHandle = $VIX_INVALID_HANDLE
    Dim $ESXjobHandle = $VIX_INVALID_HANDLE
    Dim $fehler
    $ESXjobHandle = _vmware_VixHost_Connect($VIX_SERVICEPROVIDER_VMWARE_VI_SERVER, "https://vcenter.testdom.local/sdk", 443, "administrator", "passwort", 0)
    $fehler = _vmware_VixJob_Wait($ESXjobHandle,$ESXHostHandle)

    [/autoit] [autoit][/autoit] [autoit][/autoit]

    und scheitere nun .... ich bräuchte einfach mal einen Denkansatz oder einen Stoß in die richtige Richtung. Um C / C++ /C# hatte ich mich bisher immer gedrückt. Die API kann ich zwar auch mit VB nutzen - aber ich will nichts bauen was hinter her ein ganzes .NET Framework braucht.

    Mit besten Dank im vorraus,

    BLinz

  • Hi, meiner Meinung nach sollten die Typen so übersetzt werden:

    Code
    int apiVersion,                  --> int
    VixServiceProvider hostType,     --> int
    const char *hostName,            --> str
    int hostPort,                    --> int
    const char *userName,            --> str
    const char *password,            --> str
    VixHostOptions options,          --> int oder dword
    VixHandle propertyListHandle,    --> handle
    VixEventProc *callbackProc,      --> ptr
    void *clientData                 --> ptr
  • Jetzt weis ich nicht ob ich lachen oder weinen soll ....

    Danke Greenhorn - getestet ist die aber noch nicht, oder?

    Und mein eigenes Projekt eine UDF hierfür zu bauen kann ich damit fast auf's Eis legen ...

    Ich probiere es heute / morgen mal aus

    Danke noch mal,

    BLinz

  • Welche vix.dll nimmst Du
    für ESX sehe ich da nicht direkt eine hört bei mir bei V2 auf wenn ich das richtig sehe.
    Welche ist kompatibel und reicht die eine DLL?

    Gruß Dietmar

    Achtung Anfänger! :whistling:

    Betrachten des Quellcodes auf eigene Gefahr, bei Übelkeit,Erbrechen,Kopfschmerzen übernehme ich keine Haftung. 8o

  • VMware stellt für alle Produkte die "VMware VIX API" zur Verfügung: http://www.vmware.com/support/developer/vix-api/

    Da kannst du die jeweils aktuellest Version herunterladen - du musst einen VMware Account haben oder erstellst dir eben einen (genau wie ESXi oder VMware Server alles frei verfügbar, aber halt nur mit Account).
    Nach der Installation (Dabei werden eigentlich nur jede Mengen Dateien kopiert) hat du (Windows 7 64 Bit) unter

    C:\Program Files (x86)\VMware\VMware VIX

    jede menge Unterordner wo die DLL für alle Systeme liegt (Pro VMware Produkt, z.B. ESX oder Workstation) ein Unterordner. Die Vix.h liegt im Hauptordner.
    Da liegt auch die vmrun.exe mit der du auch alles machen kannst (und scheinbar Produktunabhängig ist) - aber die ist äusserst schweigsam was Feedback angeht.

    Alles was ich mit der dll machen will könnte ich auch direkt an die Systeme senden - aber ich habe bisher nur Telnet mit AutoIT hinbekommen und keine SSH Verbindungen.

    Ich konnte auch noch nicht testen - deshalb ist es auch noch offen.

    BLinz

  • Zitat

    Da kannst du die jeweils aktuellest Version herunterladen - du musst einen VMware Account haben oder erstellst dir eben einen (genau wie ESXi oder VMware Server alles frei verfügbar, aber halt nur mit Account).

    Versteht sich von selbst, Account ist vorhanden (sind ja auch Kunde :) ) und privat auch vorhanden. Ist auch bereits heruntergeladen.

    Zitat

    Nach der Installation (Dabei werden eigentlich nur jede Mengen Dateien kopiert) hat du (Windows 7 64 Bit) unter
    C:\Program Files (x86)\VMware\VMware VIX

    jede menge Unterordner wo die DLL für alle Systeme liegt (Pro VMware Produkt, z.B. ESX oder Workstation) ein Unterordner. Die Vix.h liegt im Hauptordner.
    Da liegt auch die vmrun.exe mit der du auch alles machen kannst (und scheinbar Produktunabhängig ist) - aber die ist äusserst schweigsam was Feedback angeht.

    Ist mir schon aufgefallen, ich hatte aber zuvor direkt nach der datei gesucht. Und wurden unter "C:\Program Files (x86)\VMware\VMware VIX" viele davon gefunden.
    Die wiederum in Unterordnern je System (Workstation 3- 7, Vmwareserver 1 & 2 usw.) je einmal vorhanden war leider auch unterschedlich groß,
    daher die Frage welche für Esx oder funzt die aktuelle mit den aktuellen Systemen und für die älteren braucht man die andere Ersatz DLL ?

    Zitat

    Alles was ich mit der dll machen will könnte ich auch direkt an die Systeme senden - aber ich habe bisher nur Telnet mit AutoIT hinbekommen und keine SSH Verbindungen.

    Das hier kennst Du? So kannst Du zur Not die telnet Sitzung tunneln. (plink etc, da gibt es hier ja auch Beispiele)
    4.0 http://blog.festplatte.ch/index.php/ssh-aktivieren-esx4i
    4.1 http://blog.festplatte.ch/index.php/ssh-aktivieren-esxi-4-1

    Gruß Dietmar

    Achtung Anfänger! :whistling:

    Betrachten des Quellcodes auf eigene Gefahr, bei Übelkeit,Erbrechen,Kopfschmerzen übernehme ich keine Haftung. 8o

  • Zitat

    Ist mir schon aufgefallen, ich hatte aber zuvor direkt nach der datei gesucht. Und wurden unter "C:\Program Files (x86)\VMware\VMware VIX" viele davon gefunden.
    Die wiederum in Unterordnern je System (Workstation 3- 7, Vmwareserver 1 & 2 usw.) je einmal vorhanden war leider auch unterschedlich groß,
    daher die Frage welche für Esx oder funzt die aktuelle mit den aktuellen Systemen und für die älteren braucht man die andere Ersatz DLL ?

    Genau das probiere ich gerade noch aus. Wenn du allerdings mal in die "vixwrapper-config.txt" schaust siehst du da die Zuordnungen:

    [autoit]

    # ESX/vSphere/Server2.0 support
    viserver 12 none 2.0.0 VSphere-4.1
    esx 12 none 4.0.0 VSphere-4.1

    [/autoit]

    Die aus dem VSphere-4.1 soll also für alle ESX ab Version 4 funktionieren.
    Unter
    VMware VIX\doc\index.html

    Ist die Hilfe / Beschreibung aller Funktionen mit Beispielen - und bei jeder Funktion steht auch noch mal bei was Unterstützt wird bzw. seit wann diese Unterstützt wird. (Die C Beschreibung hat genau die Befehlsnamen)

    Mit plink.exe arbeite ich schon länger - auf meiner Hompage gibt es eine Batch-Lösung für das Herunterfahren von VM's über das VMware CLI. Die ESX-Host selber (was ich weggelassen habe weil es komplizierter ist) habe ich dann mit plink.exe heruntergefahren.

    plink.exe hat aber den Nachteil, das bei neuen ESX Hosts immer die Warnung über den unbekannten Schlüssel kommt. Klar, einmal wegklicken und gut .... aber bei einem automatisierten Script was ggf. unter einem anderem Benutzerkontext läuft ... ich habe in meinen Scripten dazu einene Export der Registryschlüssel von plink.exe / putty.exe eingebaut und einen Import als aktueller Benutzer der das Script ausführt. Das ist aber Fehlerträchtig.

    Natürlich könnte ich neben SSH auch das normale Telnet auf den ESX / ESXi Servern freischalten .... aber dann läuft die Sache wieder nicht ohne Vorbereitung.

    Mit der vix.dll hoffe ich davon weg zu kommen - abgesehen davon das man alles in ein Tool packen könnte - ohne das etwas installiert sein muss auf dem Rechner der es ausführt.

    Alternativ würde ich mir noch mal die VMware-vSphere-CLI ansehen - aber das ist alles in Python, die CLI muss dann installiert sein und die Beispiele sind auch nicht immer Fehlerfrei gewesen in der Vergangenheit. Die habe ich bisher nur in Batch Dateien missbraucht: http://znil.net/index.php?titl…ei_Stromausfall

    Nene, die vix.dll Geschichte erscheint ir im Moment am besten. Eine SSH Lösung mit AutoIT wäre genauso schön - aber ich möchte es nicht mit plink.exe im Hintergund lösen (auch wenn AutoIT das wunderbar kann) sondern "nativ" oder mittels einer .dll / UDF Lösung

  • Also ....

    ich habe die VixH.au3 von greenhorn überarbeitet (Es etwas viele _ Verbindungen, ich habe nur öfter Global Enum eingefügt sowie das #include-once)

    autoit.de/wcf/attachment/13395/

    Das Beispiel aus der Hilfe (C):

    Spoiler anzeigen
    [autoit]

    #include "vix.h"
    int main(int argc, char * argv[])
    {
    VixHandle hostHandle = VIX_INVALID_HANDLE;
    VixHandle jobHandle = VIX_INVALID_HANDLE;
    VixError err;
    // Connect as current user on local host.
    jobHandle = VixHost_Connect(VIX_API_VERSION,
    VIX_SERVICEPROVIDER_VMWARE_VI_SERVER,
    "https://viserver.example.com/sdk", // hostName
    0, // hostPort
    "Administrator", // userName
    "adminpass", // password,
    0, // options
    VIX_INVALID_HANDLE, // propertyListHandle
    NULL, // callbackProc
    NULL); // clientData

    [/autoit] [autoit][/autoit] [autoit]

    err = VixJob_Wait(jobHandle,
    VIX_PROPERTY_JOB_RESULT_HANDLE,
    &hostHandle,
    VIX_PROPERTY_NONE);

    [/autoit] [autoit][/autoit] [autoit]

    if (VIX_OK != err) {
    // Handle the error...
    goto abort;
    }
    Vix_ReleaseHandle(jobHandle);
    // Other code goes here...
    abort:
    Vix_ReleaseHandle(jobHandle);
    VixHost_Disconnect(hostHandle);
    }

    [/autoit] [autoit][/autoit] [autoit][/autoit]

    Habe ich wie folgt umgesetzt:

    Spoiler anzeigen
    [autoit]

    #cs ----------------------------------------------------------------------------

    [/autoit] [autoit][/autoit] [autoit]

    AutoIt Version: 3.3.6.1
    Author: myName

    [/autoit] [autoit][/autoit] [autoit]

    Script Function:
    Template AutoIt script.

    [/autoit] [autoit][/autoit] [autoit]

    #ce ----------------------------------------------------------------------------

    [/autoit] [autoit][/autoit] [autoit]

    ; Script Start - Add your code below here

    [/autoit] [autoit][/autoit] [autoit]

    #include "VixH.au3"

    [/autoit] [autoit][/autoit] [autoit]

    Global $MyhostHandle = $VIX_INVALID_HANDLE
    Dim $MyjobHandle = $VIX_INVALID_HANDLE
    Dim $MyERR

    [/autoit] [autoit][/autoit] [autoit]

    MsgBox(4096,"","Es folgt VixHost_Connect")

    [/autoit] [autoit][/autoit] [autoit]

    $MyjobHandle = VixHost_Connect($VIX_API_VERSION, _
    $VIX_SERVICEPROVIDER_VMWARE_VI_SERVER, _
    "https://192.168.209.131/sdk", _
    0, _
    "root", _
    "test1234", _
    0, _
    $VIX_INVALID_HANDLE, _
    0, _
    0)

    [/autoit] [autoit][/autoit] [autoit]

    MsgBox(4096,"","Es folgt VixJob_Wait")

    [/autoit] [autoit][/autoit] [autoit]

    $MyERR = VixJob_Wait($MyjobHandle, _
    $VIX_PROPERTY_JOB_RESULT_HANDLE, _
    $MyhostHandle, _
    $VIX_PROPERTY_NONE)

    [/autoit] [autoit][/autoit] [autoit]

    MsgBox(4096,"","VixJob_Wait beendet")

    [/autoit] [autoit][/autoit] [autoit]

    ;if (VIX_OK != err) {
    ; // Handle the error...
    ; goto abort;
    ; }

    [/autoit] [autoit][/autoit] [autoit]

    MsgBox(4096,"","Es folgt Vix_ReleaseHandle")
    Vix_ReleaseHandle($MyjobHandle);

    [/autoit] [autoit][/autoit] [autoit]

    MsgBox(4096,"","Es folgt VixHost_Disconnect")

    [/autoit] [autoit][/autoit] [autoit]

    VixHost_Disconnect($MyhostHandle);

    [/autoit]


    autoit.de/wcf/attachment/13396/

    Es kommt noch die erste MsgBox - dann folgt der AutoIT Absturz. Ich gehe doch richtig davon aus das das ganze auch ohne kompelieren funktionieren sollte?

    So ganz habe ich am Beispiel auch nicht verstanden woher der hostHandle plötzlich einen Wert hat ( &hostHandle) ????

    noch viel Arbeit ....

  • Ja, nun kommt der spannendste Teil: das Debuggen. ;) :D

    Ich würde lieber ConsoleWrite anstatt MsgBox zum Debuggen verwenden.
    Und du solltest die Dokumentation zur DLL, bzw. des SDK studieren (denke aber das hast du sicherlich schon getan).

    Führst du das Skript mit Administratorrechten aus ?

    Füge ein ConsoleWrite in den Funktionsrumpf von VixHost_Connect ein, um zu überprüfen wann der Absturz eintritt, vor dem Aufruf von DllCall, oder danach ... ?

    Hier noch eine Funktion um Arrays in der Konsole auszugeben, damit kannst du $aRes prüfen ...

    Spoiler anzeigen
    [autoit]

    ;««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««

    [/autoit] [autoit][/autoit] [autoit]

    Func ConsoleWriteArray (ByRef Const $array, $sArrayName = "")

    [/autoit] [autoit][/autoit] [autoit]

    Local $cnColumns
    Local $cnDimension
    Local $cnRows
    Local $cnElements

    [/autoit] [autoit][/autoit] [autoit][/autoit] [autoit]

    If (not IsArray ($array)) Then
    ConsoleWrite (StringFormat ("!--- ConsoleWriteArray - Fehler: %s ist kein Array!\n", $sArrayName))
    Return 0
    EndIf

    [/autoit] [autoit][/autoit] [autoit]

    $cnDimension = UBound ($array, 0)

    [/autoit] [autoit][/autoit] [autoit]

    If ($cnDimension > 3) Then
    ConsoleWrite (StringFormat ("!--- ConsoleWriteArray - Fehler: %d\n", $sArrayName, $cnDimension))
    ConsoleWrite (StringFormat ("!--- Max. Anzahl Dimensionen: %d\n", 3))
    ConsoleWrite (StringFormat ("!--- %s - Anzahl Dimensionen: %d\n", $sArrayName, $cnDimension))
    Return 0
    EndIf

    [/autoit] [autoit][/autoit] [autoit]

    ConsoleWrite (StringFormat ("--- Arrayvariable %s\n--- Anzahl Dimensionen: %d\n", $sArrayName, $cnDimension))

    [/autoit] [autoit][/autoit] [autoit]

    $cnRows = UBound ($array, 1)
    $cnColumns = UBound ($array, 2)
    $cnElements = UBound ($array, 3)

    [/autoit] [autoit][/autoit] [autoit]

    Switch ($cnDimension)

    [/autoit] [autoit][/autoit] [autoit]

    Case 1
    ;...
    ConsoleWrite (StringFormat ("--- Anzahl Elemente: %d\n", $cnRows))

    [/autoit] [autoit][/autoit] [autoit]

    For $i = 0 To $cnRows - 1

    [/autoit] [autoit][/autoit] [autoit]

    ConsoleWrite (StringFormat ("; %s [%d] = %s\n", $sArrayName, $i, $array[$i]))
    Next
    Case 2
    ;...
    ConsoleWrite (StringFormat ("--- Anzahl Elemente: %d\n", $cnRows))

    [/autoit] [autoit][/autoit] [autoit]

    For $i = 0 To $cnRows - 1

    [/autoit] [autoit][/autoit] [autoit]

    For $j = 0 To $cnColumns - 1

    [/autoit] [autoit][/autoit] [autoit]

    ConsoleWrite (StringFormat ("; %s [%d][%d] = %s\n", $sArrayName, $i, $j, $array[$i][$j]))
    Next
    Next
    Case 3
    ;...
    ConsoleWrite (StringFormat ("--- Anzahl Elemente: %d\n", $cnRows))

    [/autoit] [autoit][/autoit] [autoit]

    For $i = 0 To $cnRows - 1

    [/autoit] [autoit][/autoit] [autoit]

    For $j = 0 To $cnColumns - 1

    [/autoit] [autoit][/autoit] [autoit]

    For $k = 0 To $cnElements - 1

    [/autoit] [autoit][/autoit] [autoit]

    ConsoleWrite (StringFormat ("; %s [%d][%d][%d] = %s\n", $sArrayName, $i, $j, $k, $array[$i][$j][$k]))
    Next
    Next
    Next
    Case Else
    ;...
    EndSwitch

    [/autoit] [autoit][/autoit] [autoit]

    ConsoleWrite (StringFormat ("----------------------------\n\n", 0))

    [/autoit] [autoit][/autoit] [autoit]

    EndFunc

    [/autoit] [autoit][/autoit] [autoit]

    ;«««««««««««««««««««««««««««««««« End Of File «««««««««««««««««««««««««««««««««

    [/autoit]


    Gruß
    Greenhorn


  • Ich habe mir die Datei jetzt nicht angesehen, aber zwei häufige Fehlerquellen sind:
    1. Falsche Aufrufkonvention (stdcall statt cdecl oder umgekehrt)
    2. Die DLL besitzt eine Startup-Funktion und darf zwischen den DLLCalls nicht entladen werden. Also als erstes ein DllOpen und dann mit der Rückgabe statt dem Dateinamen weitermachen.

    Edit: Ich wette, es liegt an 1. Die vix.h fängt mit extern "C" an, aber bei den Funktionen fehlt :cdecl im Rückgabetyp.
    Nummer 2 trifft nicht zu, da die DLL am Anfang geöffnet wird. Ich würde jedoch eine _Vix_Startup-Funktion verwenden, sodass der Benutzer den Dll-Pfad selbst fetlegen kann.

  • Ja, das könnte auch gut sein. ;)
    Jedoch ist "extern C" kein eindeutiger Hinweis. Die WinAPI-Header z.B. enthalten fast nur stdcall als Aufrufkonvention, bzw. fastcall für x64.

    Naja, wie auch immer, BLinz hat nun alle Hände voll zu tun, mit der Fehlersuche ...
    Viel Spaß dabei und möglichst wenig Frust. :)


    Gruß
    Greenhorn


  • Führst du das Skript mit Administratorrechten aus ?

    Jepp - ich bin mutig und immer Admin ... :D

    mhh ich stelle mal um auf ConsoleWrite ... Es wird wie sonst auch sein - irgendeine Kleinigkeit - wenn der Schalter/Bit etc gefunden ist wird der Rest rutschen ....