Beiträge von ahe
-
-
Hallo,
ich wollte doch noch eine Lösung übermitteln, wenn gefunden...
Es hat zwar etwas länger gedauert, dafür funktioniert es jetzt auch schon seit ein paar Wochen mit verschiedenen, großen Paketen (auch über 1.2 GB).
Wir haben unsere Installationsdateien in kleinere Häppchen unterteilt und binden sie jetzt, wie auch oben schon beschrieben, über den Wrapper als Resource File ein:
Code#AutoIt3Wrapper_Res_SaveSource=y #AutoIt3Wrapper_Res_File_Add=.\Source\Source.7z.001, 10, Source.7z.001 #AutoIt3Wrapper_Res_File_Add=.\Source\Source.7z.002, 10, Source.7z.002 #AutoIt3Wrapper_Res_File_Add=.\Source\Source.7z.003, 10, Source.7z.003 #AutoIt3Wrapper_Res_File_Add=.\Source\Source.7z.004, 10, Source.7z.004
Eingebunden haben wir für die Verarbeitung die resources.au3 aus einem Forum (welches weiss ich leider nicht, hat mein Kollege "gefunden", aber ProgAndy hat da wohl auch seine Finger unterstützend mit im Spiel :-), siehe angehängte Datei)
Mit der Funktion _ResourceSaveToFile aus der Lib können wir dann die Dateien speichern, um sie später expandieren und für das Setup nutzen zu können.
Code_ResourceSaveToFile($FCIA_WorkDir & "Source.7z.001", "Source.7z.001") _ResourceSaveToFile($FCIA_WorkDir & "Source.7z.002", "Source.7z.002") _ResourceSaveToFile($FCIA_WorkDir & "Source.7z.003", "Source.7z.003") _ResourceSaveToFile($FCIA_WorkDir & "Source.7z.004", "Source.7z.004")
Schönen Gruß
Axel
-
Sorry für meine späte Antwort, war viel unterwegs in letzter Zeit... aber habe das Thema nie aus den Augen verloren.
Die Ideen mit dem zentralen Speichern der Dateien und dem Starten eines kleinen Installationsskripts hatten wir auch schon, wurde auch z. T. schon umgesetzt. Leider haben wir das Problem, dass wir mehrere Standorte mit rel. schlechter Verbindung zum zentralen Server haben. D. h. wir verwenden sog. Repositories an diesen Standorten und müssen daher dort die Pakete synchron halten. Bei ein paar hundert oder tausenden Dateien, kein so großes Problem. Wir sprechen hier aber leider über ein paar hundert tausend Dateien... (wir haben viele umfangreiche Software Pakete... div. Office Versionen, SAP, etc.).
Ein Austausch des Skriptes ist nicht so einfach für einen Angreifer, da er im zentralen System dafür den Hash der Datei in einer Datenbank ändern müßte. Wenn er das geschafft hat, haben wir, glaube ich, ganz andere Sorgen
Wir haben inzwischen noch ein paar Dinge herausgefunden, die uns noch etwas mehr irritieren.
Wir testen und installieren die SW mit "Local System" Rechten (die SW Verteilung läuft als lokaler Dienst mit lokalen System rechten, daher). Dies funktioniert bei nahezu jeder Software ohne Probleme (klar, man muss etwas bei den Registry-Keys tricksen).
Nachdem jetzt ein Kollege meldete, er hätte keinerlei Probleme mit FileInstall und großen Dateien, haben wir analysiert, wie er testet und mussten feststellen, dass er die EXE mit "Run as admin" startet. Ein einfacher Test mit meinem kleinen FileInstall Skript brachte die Erkenntnis, es geht als lokaler Admin, nicht aber als Local System... ?!?
Es liegt also wohl nicht am RAM (wir reden seit Jahren darüber 32 Bit zu kicken ...), sondern eher an etwas Anderem.
Zur Zeit versuche ich mich an der "Res Add File" Funktondes Wrappers: #AutoIt3Wrapper_Res_File_Add="dateiname.zip", RT_RCDATA mit der Funktion _FileInstallFromResource
Komme aber nicht so recht weiter. Ich sehe via ProcMon, wie im Speicher etwas hochgezählt wird (was der Dateigröße entspricht), aber es wird nirgendwo etwas abgelegt.
Melde mich wieder, wenn ich eine Lösung habe...
.
-
-
Hallo Musashi,
danke, wir hatten auch schon überlegt, ob wir einen Installer verwenden, ob jetzt Inno Setup oder etwas kommerzielles.
Allerdings kam jedes Mal die Fragen auf, können wir daraus Meldungen verschicken, kann das Tool auch Logs schreiben, wie wir es wollen, etc. und v. a. was kostet das Tool an Geld, Zeit für die Einarbeitung, Schulung, etc.
Daher sind wir bei AutoIt geblieben... hat halt viele Vorteile und wir nutzen alle die gleiche Version + eine eigene Funktions-Lib... (macht das Debuggen einfacher)
Aber ich werfe das Thema noch mal in unserem Meeting in die Runde, wenn wir keine Lösung für die großen Pakete finden...
Meine Tests mit dem Aufsplitten der Source-Datei in mehrere kleine Dateien hat im Übrigen nix gebracht, sobald ich über 500 MB komme, war es das. (ist auch egal, was das für Dateien sind).
Wenn ich nur wüsste, warum das jetzt passiert, wir haben schließlich in den vergangenen Jahren schon deutlich größere Pakete erstellt die auf W7 32 Bit keine Probleme machen...
mfg
Axel
-
Hallo ihr,
ein Test ist mir noch eingefallen, den ich noch nicht ausprobiert hatte. In der Vergangenheit hatten wir etwas größere SW Pakete zu packen, allerdings haben wir da noch kein AutoIt verwendet, sondern noch gute alte Batches... Da es da doch etwas Probleme mit der Größe einer einzelnen Datei gab, haben wir diese per 7zip in kleinere Dateien aufgeteilt, diese auf das Ziel kopiert und anschließend über 7zip expandiert (oder war das noch pkunzip?).
Ich denke wir versuchen das jetzt erst einmal, nur blöd, wenn man anstelle von einer Datei dann 20 hat...
Eine weitere Alternative ist, wenn auch nicht so schön unabhängig vom Netz, wenn man die Installation aufteilt. Ein kleines Paket für die Installationslogik, welches dann die Source-Datei(en) vom Netzshare zieht. Dafür muss man natürlich von überall den Share erreichen und die Berechtigungen müssen entsprechend gesetzt sein.
Funktioniert sogar, nur dann habe ich nicht mehr beide Teile zusammen und könnte meinem Installationsscript einfach einen neuen Source unterschieben (hätte auch seinen Charme, aber aus Sicherheitsgründen...). Um dies zu verhindern müßte über diesen Source ein Hash gebildet werden, der dann im Installationsscript abgefragt wird...
Mmh, eigentlich eine Idee, sollte auch nicht so schwierig zu implementieren sein, nur wie lange dauert es einen Hash von einer großen Datei auf einem Netzwerkshare zu prüfen? Muss ja jedes Mal beim Start des Pakets über das Netz errechnet und anschließend (das sollte dann schnell gehen) mit dem Wert im Skript verglichen werden.
Ich denke ich probiere erst einmal das Aufsplitten... und melde mich wieder.
mfg
Axel
-
Hallo,
ich habe ein etwas seltsames Problem hier.
Wir nutzen AutoIt um Software zu installieren. Das klappt eigentlich auch schon seit Jahren recht gut und zuverlässig. Allerdings haben wir mit ein paar Paketen das Problem, dass die zu installierenden Sourcedateien unter Windows 7 32 Bit nicht kopiert werden bzw. nicht immer kopiert werden. Unter Windows 7 64 Bit oder Windows 10 64 Bit tritt das Problem nicht auf.
Beim Kompilieren befinden sich die Sourcen in einem Unterverzeichnis des Scriptes und werden auch eingebunden (ansonsten würden sie ja auch unter W7/W10 64 Bit nicht da sein...) und beim Starten des Pakets sollten sie in das existierende Verzeichnis C:\temp\packages\ kopiert werden. Die Datei "Source.7z" ist etwas über 600 MB groß.
Code$FCIA_WorkDir = C:\temp\packages\ . . . FileInstall(".\Source\7za.exe", $FCIA_WorkDir, 1) FileInstall(".\Source\Source.7z", $FCIA_WorkDir, 1) FileInstall(".\Source\Config.xml", $FCIA_WorkDir, 1) . . .
Zur Sicherheit haben wir den Parameter für den Target-Pfad aus dem obigen Beispiel-Source schon durch den eigentlichen Pfad ersetzt, den Virenchecker deaktiviert und sogar deinstalliert. Das komplette Paket unter W7 32 Bit als 32 Bit EXE kompiliert, um sicher zu gehen keine 64 Bit DLL eingebunden zu haben. Mit einem frisches W7 32 ohne jegliche Patche den Test gemacht, aber alles erfolglos.
(ach ja, den Source-Pfad habe ich auch schon vollständig angegeben, nur um sicher zu gehen, dass es mit den relativen Pfaden kein Problem gibt)
Jeweils haben wir die erstellte Version parallel auf einem 64 Bit System ohne Probleme installieren können, d. h. dort konnten wir sehen, wie die Dateien kopiert wurden.
Wenn wir jetzt die große Datei "Source.7z" nicht einbinden, funktioniert das Kopieren der übrigen Dateien. Die Datei "Source.7z" ist aber auch nicht defekt, da sie sich ohne Problem auf Kommandozeilen-Ebene kopieren und entpacken läßt. Wir haben auch schon andere, unregistrierte Dateiendungen ausprobiert und andere Packgrade, um das Kopieren zu testen, ohne Erfolg.
Kann es sein, das FileInstall unter Windows 7 32 Bit Probleme mit Dateien ab einer Größe von 500 MB hat? Wir nutzen die letzte AutoIt Version (keine Beta).
Bis vor zwei AutoIt Versionen kannten wir diese Probleme gar nicht, auch dort hatten wir schon Pakete im Einsatz, die weitaus größere Sourcedateien eingebunden hatten ... wir mußten nur wegen W8/W10 auf die neueren Versionen wechseln...
Vielleicht hat ja jemand von Euch eine Idee was der Grund sein könnte...
Mit freundlichen Grüßen
Axel
-
Eigentlich dachte ich, mit FileInstall wird das einfach zu kompliziert und es geht doch auch sicher ohne...
Damit geht es jetzt, Datei wird am Ende auch gelöscht...
Code
Alles anzeigenFileInstall("D:\mein_desd\logo.bmp", EnvGet("TEMP") & "\logo.bmp", 1) . . . $Pic1 = GUICtrlCreatePic(EnvGet("TEMP") & "\logo.bmp", 8, 7, 150, 60) While 1 $nMsg = GUIGetMsg() Switch $nMsg Case $GUI_EVENT_CLOSE FileDelete (EnvGet("TEMP") & "\logo.bmp") Exit EndSwitch WEnd
... und hat auch gar nicht weh getan... von wegen kompliziert ... getestet unter WinPE und den Server OSs.
Nochmal Danke für den Tritt alpines
Schönen Feiertag noch...
Axel
-
Danke alpines...
Grummel...
Oh man... und ich dachte der Binärteil in der von Koda erstellten kxf-Datei wäre das Bild... scheint aber nur das Icon zu sein...
<property name="Icon.Data" vt="Binary">
Wer lesen kann...
Ich bastel jetzt mal etwas weiter...
... also zuerst mit FileInstall das Bild in ein Tmp Verzeichnis legen und von dort dann via GUICtrlCreatePic einbinden...
-
Hallo,
vielleicht hat ja jemand schon etwas Ähnliches gesehen oder weiss woran es liegt und ob es eine Lösung gibt.
Ich habe eine GUI erstellt mit Eingabefeldern, Auswahlmenüs, Checkboxen und Buttons. Alles funktioniert tadellos, schon seit Jahren :-).
Jetzt wollte ich, zur Verschönerung, ein Logo einfügen und fand heraus, dass ich das wohl schon vor einer Weile gemacht habe (ich werde alt!).
Allerdings wird dieses Logo unter Windows PE (egal welche Version 3.x oder neuer und ob es 32 bit oder 64 bit ist) nicht angezeigt (ich fühl mich noch älter, dass ich das jetzt erst bemerke...).
Starte ich aber die gleiche GUI unter Windows 7 (32bit/64bit) oder Windows 10, so ist das Logo da.
Die Einbindung erfolgt über:
Es liegt auch nicht am Dateityp, da ich schon diverse Typen ausprobiert habe (JPG, PNG, BMP, in verschiedenen Kompressionsstufen und Farbtiefen)
Meine Vermutung ist, es fehlt irgendeine Lib (oder dessen Registrierung?) in Windows PE, jetzt ist nur die Frage, welche?
Aus Spass habe ich jetzt meine kleine GUI auch mal auf Servern gestartet W2K8 R2 und W2K12 R2 (mit und ohne "Run as admin"), auf beiden das gleiche Problem, auch hier wird das Logo nicht angezeigt.
Nebenbei interessant ist auch, dass sich die Dateigröße meiner EXE nicht ändert, wenn ich verschieden große Bilder einfüge. Ich nehme ich an, dass das Bild in irgendeiner festen Form in der EXE eingebunden ist, vermutlich, durch die Fenstergröße in GUICreate, egal, ob das Bild größer ist als das Fenster oder nicht, der Rest wird abgeschnitten.
C
Alles anzeigen#Region ;**** Directives created by AutoIt3Wrapper_GUI **** #AutoIt3Wrapper_UseX64=y #EndRegion ;**** Directives created by AutoIt3Wrapper_GUI **** #include <GUIConstantsEx.au3> $Form1 = GUICreate("Test-GUI", 619, 390, -1, -1) GUISetBkColor(0xFFFFFF) $Pic1 = GUICtrlCreatePic("C:\Windows\Microsoft.NET\Framework64\v4.0.30319\ASP.NETWebAdminFiles\Images\help.jpg", 8, 7, 0, 0) ; 2K groß ;$Pic1 = GUICtrlCreatePic("C:\Windows\Web\Wallpaper\Theme1\img13.jpg", 8, 7, 0, 0) ; 1,2 MB groß GUISetState(@SW_SHOW) While 1 $nMsg = GUIGetMsg() Switch $nMsg Case $GUI_EVENT_CLOSE Exit EndSwitch WEnd
mfg
Axel
-
Hallo donpascal
hast du schon eine Lösung dafür gefunden? Ich habe das gleiche Problem. Gerade mit den sehr hochauflösenden Tablets oder auch Notebooks werden die GUI's in Windows PE extrem klein dargestellt und die Fonts dagegen z. T. gegenteilig "verändert"...
Ich habe hier eine GUI (mit KODA erstellt), die bei einem PC oder auch normalem Notebook HD Display gut zu bedienen und die Schrift gut zu lesen ist.
Bei Full HD wird die GUI schon merklich kleiner (logisch, da die Größe des Fensters ja hardcodiert ist) und die Schrift wird proportional ebenfalls kleiner.
Wenn man jetzt bei einem Display mit WQHD (s. a. dein Surface im Screenshot oben) sich die GUI anschaut, ist sie jetzt auf Briefmarkengrösse geschrumpft, allerdings die Schriften nicht, diese sind deutlich vergrößert und unterschiedlich, je nachdem ob sie auf enem Button oder in einem Textfeld erscheint.
In Windows PE 3.x konnte man noch die Auflösung fest über eine Konfigdatei einstellen und diese wurde dann auch übernommen wenn man im Legacy Mode bootet.
Wenn man auch noch im UEFI Mode bootet (s. Surface) scheint die Firmware der entscheidende Punkt zu sein, der die Auflösung vorgibt, d. h. man müßte für jede Hardware eine Abfrage einbauen, der die GUI dynamisch (?) verändert...
mfg
Axel
-
Im Gegensatz zu Vista/W7 klappt das mit der Sicht auf Message-Boxen und Progress-Bars nur dann, wenn man auf der Admin-Konsole ist oder direkt am Server sitzt.
Ich installiere des Öfteren als "Local System" User (über einen Dienst), Software auch auf Servern. Bin ich dort aber nicht auf der Konsole angemeldet, so sehe ich keine meiner generierten Meldungen!
Falls ihr also per RDP auf dem Server seid, versucht einmal den Konsolen Parameter zu nutzen: Mstsc.exe /admin
Allerdings muss der Rollendienst Terminalserver dafür installiert/aktiviert sein. http://support.microsoft.com/kb/947723/de
(das hat uns auch schon Nerven gekostet...)
-
Muss ich am Montag mal ausprobieren. (wenn ich einen Test-Server finde, auf dem ich Office installieren darf...
Mit Local System gibt es aber immer etwas Probleme, meist dann, wenn es etwas zu bestätigen oder anzuzeigen gibt.
Im Taskmanager habt ihr ja sicher geschaut, ob die Excel.exe am Laufen ist...
Kleine Frage:
Ist es ein Server 2008 R2 oder noch ein älterer? (32bit/64bit?) -
Hi,
liegt vielleicht am Kontext des Taskplaners...
Läuft der Taskplaner nicht mit Systmerechten?
Hat das "System" (der Server selbst) Berechtigungen auf diese Excel-Dateien zuzugreifen?
Falls der Zugriff über einen (Netzwerk-)Share auf die Excel-Dateien erfolgen soll, muss der Server die Berechtigung bekommen darauf zuzugreifen.
Dafür ist es nötig den Gruppen Network und Domain Computers (in einer Domäne) zumindest Leserechte auf diesem Share zu erteilen.mfg
ahe -
Kleine Idee, wie man das Ganze auch per Batch implementieren könnte...
http://www.administrator.de/index.php?content=31727
Man erstellt einfach x-Minuten von jetzt an einen AT-Job, der dann eine Batch startet oder einen Befehl ausführt, z. B. einen Takskil...
Mittels der Batch wird die Uhrzeit in der Zukunft ermittelt und anschließend als Parameter für den AT-Job verwendet.
Der Aufruf sieht dann ungefähr so aus:Coderem start a AT-Job in the next minutes. rem With the command timeadd.cmd <minutes> you can set a time schedule in the next minutes rem from now, without knowledge of the actual time, here 2 minutes: call timeadd.cmd 2 echo %newtime% at %newTime% /interactive "MyFamousTaskkillBatch.cmd" REM oder ungetestet: REM at %newTime% /interactive taskkill /im cmd.exe /f
Die Batch timeadd:
Spoiler anzeigen
Code
Alles anzeigen@echo off & setlocal goto START ************************************************************************************ * Create a own time variable 'newTime'. * * * * You can add some minutes (0-59) to your local time, write this new time in a * * variable 'newTime' and use the variable as parameter for AT (or something else). * * * * Start: timeadd <min> * * minutes between 3 and 3600 * * * * Preparations: OS = Windows XP * * * * Creator: biber + ahe * * Creation date: 05.05.2006 * * * * Minor suggestions by Beaver 2006 / Biberware -- Placed in the Public Domain * ************************************************************************************ :START if "%1" == "" goto ask4DELAY set /a delayMins=%1 +0 echo. echo Input: %delayMins% echo. rem special setting to 1, normally is the value 3 better! rem if %delayMins% LSS 3 goto ask4DELAY if %delayMins% LSS 1 goto ask4DELAY goto TIMEADD :ask4DELAY set /P "delayMins=Input time delay between 3 and whatever in mins: " if %delayMins% LSS 3 goto START goto TIMEADD :TIMEADD For /F "Tokens=1,2 Delims=:" %%J In ("%time%") Do ( Set hour=%%J Set minutes=%%K ) set /a delayhours=0 set /a newMins=%delayMins% + %minutes% :: Stunden und Minuten errechnen if %newMins% GTR 59 set /a delayHours=%newMins%/60 if %newMins% GTR 59 set /a newMins=%newMins% %% 60 set /a newhour=(%hour%+%delayHours%) %% 24 :: führende "0" ergänzen, falls Stunde/Minute kleiner 9 If %newhour% LEQ 9 set newhour=0%newhour% If %newmins% LEQ 9 set newmins=0%newmins% set newTime=%newhour%:%newmins% echo. echo Time delay: %delayMins% echo OldTime / New Time: %hour%:%minutes% / %newTime% / %delayHours% / %newmins% Endlocal & set newTime=%newTime%
mfg
Axel -
Funktioniert soweit unter W7 32 Bit, allerdings funktioniert das Füllen von Ellipsen nicht, es fehlt der Parameter $BackColor in der GDE.au3:
So funktionierte auch das Füllen der Ellipsen:
[autoit]
[/autoit]
Func _GDE_Ellipse($hGraphics, $Left, $Top, $Width, $Height, $Color, $Size = 1, $BackColor = $GUI_GR_NOBKCOLOR)
GUICtrlSetGraphic($hGraphics, $GUI_GR_PENSIZE, $Size)
GUICtrlSetGraphic($hGraphics, $GUI_GR_COLOR, $Color, $BackColor)
GUICtrlSetGraphic($hGraphics, $GUI_GR_ELLIPSE, $Left, $Top, $Width, $Height)
GUICtrlSetGraphic($hGraphics, $GUI_GR_CLOSE)
EndFuncGDI+ Besipiel as der Hilfe zur Funktion "GUICtrlSetGraphic " funktioniert bei mir auch recht zügig...
In jedem Fall werde ich wohl jetzt etwas mit Grafiken herumspielen daher Danke für die UDF
mfg
Axel -
Hallo,
ich bin so ein Depp!
Die WMI Variante funktioniert doch! Wenn man den Check nicht aus SciTE heraus startet, sondern den Test der Attribute mit einem Kompilat durchführt.
Danke noch einmal für die Hilfe, das Problem ist gelöst.
mfg
Axel -
Hallo Aspirin,
habe jetzt die andere, nicht WMI-Methode, ausprobiert.
Diese funktioniert sowohl unter XP, als auch unter Vista.
Ich danke dir noch einmal für deine Hilfe. Jetzt muss ich mich erst einmal in diese Funktion einlesen, kapiert habe ich sie noch nicht, das war bei WMI einfacher
Allerdings wüßte ich schon gerne, wo das Problem bei der WMI Variante liegt...
mfg
Axel -
Hallo Aspirin,
habe die WMI Lösung getestet, weil sie genau dem entsprach, was ich mir vorgestellt hatte (kurz und gut). Funktioniert einwandfrei auf Vista, unter XP wird die CommandLine jedoch nicht angezeigt.
Ich habe daraufhin andere Attribute getestet, wie
- $oProc.Caption
- $oProc.Description
- $oProc.ProcessID
etc. diese funktionierten, nur CommandLine nicht... (beim SELECT habe ich "CommandLine, Name" durch * ersetzt. um dort evtl. Schreibfehler auszuschließen)
Jedes Mal wird mir die javaw.exe mit dem gewünschten Attribut angezeigt, nur bei CommandLine nix, s. Beispiel-Ergebnis für $oProc.ProcessID:
javaw.exe: 5992
javaw.exe: 5764Mit einem Codegenerator für VBS erhielt ich dieses funktionierende Skript:
[autoit]Set objWMI = GetObject("winmgmts:\\.\root\CIMV2")
[/autoit][autoit][/autoit][autoit]Set objTest = objWMI.ExecQuery("SELECT CommandLine, Name FROM Win32_Process WHERE Name='javaw.exe'", "WQL", 48 )
[/autoit]
For Each objFish2 In objTest
WScript.Echo objFish2.CommandLine
NextDort wird als Ergebnis das Gleiche ausgegeben, wie unter Vista mit AutoIT:
"C:\Program Files\Java\jre6\bin\javaw.exe" -Xms16m -Xmx256m -jar "C:\Program Files\GanttProject\eclipsito.jar" ganttproject-eclipsito-config.xml
javaw.exe -Xmx256M -jar "lib\freemind.jar"Wo liegt jetzt der Fehler? Hast du noch eine Idee?
mfg
Axel -
Wow..."nur" ist gut...
Ich habe deine Funktion ausprobiert und es funktioniert unter Vista 32, vielen Dank aber leider nicht unter XP Pro 32
Hier mein Aufruf...
[autoit]
[/autoit][autoit][/autoit][autoit]
$s_DisplayName = "FreeMind"$aProc = ProcessList("javaw.exe")
[/autoit]
For $i = 1 To $aProc[0][0]
While 1
If StringInStr(_WinAPI_GetCommandLineFromPID($aProc[$i][1]), $s_DisplayName) Then
;MsgBox(4096, "freemind", "[CLASS:SunAwtFrame]" & " zugeh. PID: " & $aProc[$i][1])
$response = MsgBox(32 + 4096, "Accept please...", $s_DisplayName & " is in use." & @CRLF & "Please close " & $s_DisplayName & " and click on OK to continue installation.")
Select
Case $response = 1
MsgBox(0,"msg","User select to check again.")
Case Else
MsgBox(0,"msg","Response is not managed.")
Exit 1000
EndSelect
Else
ExitLoop
EndIf
WEnd
Next
MsgBox(0,"msg","Application is not longer running.")Hast du eine Idee, was falsch sein könnte? Könnte es sein, dass die kernel32.dll unter XP nicht die gleichen Funktionen enthält?
Unter XP ist der Rückgabewert für $aProc[$i][1] leer, für $aProc[$i][0] kommt javaw.exe heraus...
[autoit]2:
[/autoit]
javaw.exe:
javaw.exe:mfg
Axel