Schuld daran ist, dass Prozesse die von einer 32 bit Applikation aus gestartet werden standardmäßig auf das windir\SysWow64 Verzeichnis umgeleitet werden, wenn Sie eigentlich auf windir\system32 zugreifen wollen. Dadurch starten Sie den vbscript Host als 32 bit Applikation und nicht als 64 bit.
Es gibt aber eine einfache Lösung: Zumindest unter Windows 7. Windows stellt einen Alias bereit der sich "sysnative" nennt und auch unter 32 bit Prozessen Zugriff auf das 64 bit system32 Verzeichnis erlaubt. Man kann also ein 64 bit vbscript in einem Javaagenten einfach auf folgende Art aufrufen:
// Aufruf mit dem sysnative bewirkt, dass Script in // 64 bit ausgeführt wird auch wenn der Hostprozess ein // 32bitiger ist. Process p = Runtime.getRuntime().exec(System.getenv("WINDIR") + "\\sysnative\\cscript.exe\script.vbs") p.waitFor();
Genauere Infos erhält man auf MSDN
Oder gleich ganz Java nehmen? http://stackoverflow.com/questions/62289/read-write-to-windows-registry-using-java
ReplyDeleteInteressante Klasse, aber es gibt 2 Probleme damit. Erstens kannst du da die jvm von Notes natürlich auch 32 bitig ist, auch mit dieser Klasse nicht auf die 64 bit Schlüssel in der Registry zugreifen. Zweitens verwende ich interne nicht dokumentierte Klassen nur im äußersten Notfall wenn alle anderen Mittel scheitern, weil der JVM Anbieter bei jedem kleinen Update Änderungen in der internen Implementierung der Preferencesklase durchführen kann. Ich weiß jetzt auch gar nicht, ob der Code auf einer andern JVM als Oracles lauffähig ist, da solche internen Details jeder JVM Anbieter anders handhabt. Hast du es schon einmal unter Notes probiert?
ReplyDeleteMeine Platformen haben keine Registry :-D
ReplyDelete(Stell Dir den Tonfall vor wie der Italiener in der Webung: 'Ich habe gar keine Auto')