hallo marthog,
besten dank funktioniert perfekt- und unabhängig von
#AutoIt3Wrapper_UseX64
ich war nicht drauf gekommen das mit @AutoItX64 zu kombinieren.
nochmals danke
vgun
hallo marthog,
besten dank funktioniert perfekt- und unabhängig von
#AutoIt3Wrapper_UseX64
ich war nicht drauf gekommen das mit @AutoItX64 zu kombinieren.
nochmals danke
vgun
hallo liebe community,
gibt es eine möglichkeit mit autoit die bitzahl einer dll zu ermitteln?
für auführbare dateien nutze ich momentan dazu
DllCall('kernel32.dll', 'int', 'GetBinaryTypeW', 'wstr', $sPath, 'dword*', 0)
viele grüße und danke im voraus
vgun
hallo liebe community,
ich brauche eure hilfe bei einem problem mit der nutzung der 7zip.dll in zusammenhang mit der udf von rasim aus dem englischen forum:
http://www.autoitscript.com/forum/topic/85…e__hl__%20rasim
(ich wende mich an euch, da rasim offensichtlich die entwicklung der udf nicht mehr weiterbetreibt.)
leider habe ich es bis jetzt u.a. nicht geschafft ein archiv zu erzeugen, welches im verzeichnis/ dateinamen zeichen enthält, die nicht ascii konform sind.
bis jetzt behelfe ich mir mit einem test des namens auf StringIsASCII und bei fehlschlagen dem ablehnen der operation.
schon die mitgelieferten beispiele zur udf funktionieren beispielsweise nicht mit verzeichnis/ dateinamen die umlaute enthalten.
beispiel die _7ZipAdd_Example
hier bitte als "new archive" irgend etwas mit umlauten auswählen
#include <7Zip.au3>
;Exampe #1
$ArcFile = FileSaveDialog("Create a new archive", @ScriptDir, "Archive Files (*.7z;*.zip;*.gzip;*.bzip2;*.tar)")
If @error Then Exit
$FileName = FileSelectFolder("Select a folder", "")
If @error Then Exit
$retResult = _7ZipAdd(0, $ArcFile, $FileName)
If @error Then
MsgBox(64, "_7ZipAdd", "Error occurred")
Else
MsgBox(64, "_7ZipAdd", "Archive created successfully" & @LF & _
$retResult)
EndIf
-> es werden zwar die dateien erzeugt jedoch in anderen neuen ordnern/ dateinamen mit entsprechend falschen buchstaben (aus ä wird beispielsweise ein õ).
in welcher form muss ich den verzeichnis/ dateinamen konvertieren, damit ihn die dll nimmt? (die grafische oberfläche von 7zip selbst hat keine probleme mit umlauten...)
viele grüße und danke im voraus
vgun
hallo dusg,
wenn du das programm als cui compilierst sollte es wie beschrieben funktionieren. dazu die zeile #AutoIt3Wrapper_Change2CUI=y am anfang vom script einfügen bzw. beim compilieren mit STRG+F7 "Create CUI instead of GUI EXE." anhaken.
z.B:
[autoit]
#AutoIt3Wrapper_Change2CUI=y
sleep(5000)
grüße
vgun
Hallo UEZ, hallo Alizame,
die Funktion _WinAPI_GetBinaryType aus der <WinAPIex.au3> von http://www.autoitscript.com/forum/topic/98712-winapiex-udf/ ist perfekt für mein Vorhaben. Ich danke euch beiden für die perfekten Denkanstöße.
viele grüße
vgun
Hallo UEZ,
danke für die schnelle Antwort.
Die includes <APIConstants.au3> und <WinAPIEx.au3> gibt es in meiner Autoit- Version (3.3.8.1) nicht. Daher konnte ich die Funktionalität auch (noch?) nicht testen. Gibt es in der 3.3.8.1 einen neue Funktion für "_WinAPI_GetBinaryType"?
Hallo funkey,
die IsWow64Process function benötigt meiner Meinung nach das Handle zum Prozess. Dazu müsste ich die *.exe aber starten oder? Das kann ich in dem Fall nicht.
viele grüße und danke
vgun
Hallo zusammen,
gibt es eine Möglichkeit, mit Autoit zu ermitteln ob eine *.exe (nicht mit AutoIt compiliert) für 64bit oder 32bit compiliert wurde, ohne das dabei die *.exe gestartet werden muss?
(im Startfall würde z.B. auf einem 32bit System die Meldung kommen: * ist keine zulässige Win32-Anwendung)
vgun
hallo alina,
was passiert, wenn du den eintrag zur registry hinzufügst:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa]
"LmCompatibilityLevel"=dword:00000001
siehe auch hier:
http://social.msdn.microsoft.com/Forums/de-DE/w…b-f40409bce684/
lg
vgun
OK, nur wie komme ich da ohne x64-BS dran? Kannst du mr die DLL bitte schicken? Dann kann ich sie ins Paket legen
Edit: OK, uniextract funktioniert ja auch mit x64-Paketen.
da das mit dem extract zu schwierig zuordenbaren dateinamen führen könnte habe ich eine mail an die admin - adresse geschickt.
grüße vgun
PS: Falls du 64bit hast, musst du als x86 (32bit) starten, da ich noch keine libmysql.dll für x64 gefunden habe.
wenn du die 64 bit version von mysql installierst z.b. mysql-5.1.45-winx64.msi von
http://dev.mysql.com/downloads/mirror.php?id=385574 befindet sich die libmysql.dll im bin unterordner der mysql - installation. z.b. hier: C:\Program Files\MySQL\MySQL Server 5.1\bin. diese ist etwas größer als die 32bit variante, lässt sich aber genauso verwenden.
grüße vgun
hi pretrojaner,
lame liefert in der mir verfügbaren version auf stdout kein ergebnis!
anders sieht die sache aus, wenn stderrread verwendet wird.
vielleicht löst das dein problem?
grüße vgun
hi subzero007,
da ich das häufiger brauchte, hatte ich mal eine func geschrieben die mit 1d/ 2d arrays umgehen kann und einen tab/ crlf separierten string zurückgibt.
Func _arraytostr($array)
Local $mkctemp, $mkctemp2, $mkctemp1, $mkcline
For $mkctemp = 0 To UBound($array) - 1
If UBound($array, 2) > 1 Then
For $mkctemp2 = 0 To UBound($array, 2) - 1
If $mkctemp2 = 0 Then
If $mkctemp = "" Then
$mkctemp1 = $array[$mkctemp][$mkctemp2]
Else
$mkctemp1 = $mkctemp1 & @CRLF & $array[$mkctemp][$mkctemp2]
EndIf
Else
$mkctemp1 = $mkctemp1 & @TAB & $array[$mkctemp][$mkctemp2]; & @CRLF
EndIf
Next
Else
If $mkctemp <> 0 Then
$mkctemp1 = $mkctemp1 & @CRLF & $array[$mkctemp]
Else
$mkctemp1 = $array[$mkctemp]
EndIf
EndIf
Next
Return $mkctemp1
EndFunc
den string könntest du auch in einer msgbox zurückgeben- sieht aber nicht so schön aus. andere möglichkeit wäre dann mit clipput + einfügen in tabellenkalkulation.
grüße vgun
hallo erax,
ich kenne certutil nicht. aber aus meiner sicht ist die zeile hier falsch
Run(@Comspec & ' /k certutil -p & $text -importpfx & $search ', @SW_HIDE)
die zeile müsste imho eher so aussehen:
Run(@Comspec & ' /k certutil -p' & $text & ' -importpfx ' & $search, @SW_HIDE)
vielleicht müsste man auch das stdout und stderr wegfangen (siehe hilfe bei StdoutRead ...)
mfg
vgun
hallo nooby,
leider kann ich wenig zu der lösung beitragen, ich habe aber ein vergleichbares problem mit der eraser.dll und dllopen siehe [ offen ] problem mit dllopen auf eraser.dll unter vista x64.
bei anderen dll's funktioniert dllopen unter vista 64 und unter vista 32 ohne, dass man eine spezielle dll oder spezielle befehle verwenden muss.
grüße vgun
edit1:
vielleicht hilft ja folgendes:
hier http://downloads.sourceforge.net/sevenzip/7z465-x64.msi die 64 bit variante herunterladen, das *.msi installieren und aus dem programmeordner die dll für diese zwecke nehmen? bei mir hat das funktioniert (vista x64 ultimate).
hallo johannes,
danke nochmal für deine meinung zu der selbstkonstruierten anfangsfunktion.
zurück zur eraser.dll; ich verstehe das nicht:
aus meiner sicht ist die eraser.dll keine 64bit-dll. unter xp, vista 32 funktioniert das ansprechen der selben dll ganz normal.
bei mir funktioniert derselbe eraser z.b. die portable version sowohl in der grafischen als auch in der command-line version unter 32 und 64 bit ohne das die dll oder programmteile getauscht werden müssen.
andere *.dll s ließen sich bisher relativ problemlos mit autoit in 64bit und 32bit vista ansprechen z.b. die myodbc5.dll.
grüße vgun
Edit: ich sehe gerade, dass nooby ein ähnliches problem hier im forum mit der 7zip- dll hat:
[ offen ] 7-zip dll auf Windows 64
vielleicht ergibt sich daraus ein ansatz für eine lösung
hallo greenhorn,
dankeschön für die geduld!!!
leider bringt auch das $DONT_RESOLVE_DLL_REFERENCES für LoadLibraryEx nichts. der rückgabewert bleibt null (0x0000000000000000).
andere werte für das dwFlags habe ich getestet- der rückgabewert bleibt gleich.
zu uac: das script wird mit adminrechten ausgeführt.
die vm unter vista business 32 gibt handles für dllopen zurück.
grüße vgun
unter vista 64 gibt es im \system32 die kernel32.dll, ebenso in \syswow64.
eine kernel64.dll gibt es nicht.
grüße vgun
unter vista64 gibt mir die funktion das hier zurück: 0x0000000000000000 ich nehme an, dass das mit der -1 von dllopen vergleichbar ist.
unter xp ist der rückgabewert so: 0x01140000.
hallo greenhorn,
ja die neueste version habe ich. eraser selbst läuft bei mir auch relativ problemlos unter vista 64 (mit adminrechten).
das problem ist aus meiner sicht der dllopen- befehl auf die eraser.dll unter vista64.
den habe ich mit den versionen 5.6- 5.8.7.0 getestet und der gab auf dem vista64 immer nur -1 zurück.
grüße vgun