#requireadmin
[/autoit]
sollte am Anfang im Script die Erlaubnis einholen und dann die Installation durchführen.
ggfs. die Compile Optionen mal durchtesten
Gruß Dietmar
vermutlich ist Win8 die "WinME-Variante" von Win7 
@Shadow normalerweise musst du nur den alten Bootloader wiederherstellen,
zumindest war es so wenn man win7 wieder entsorgt hat.
Und wegen Wechsel zu 8 (Server8 kann durchaus vorkommen, Windows8 Client - eher nicht)
Leider ist das so fest vorgegeben.
keytext=2
keytext=3
dann ändere es halt 
keytext=2|3
und dann mit stringsplitt zerlegen
Gruß Dietmar
ich habe immer ne vmware genutzt und da die exe des jeweiligen Programms gestartet und dann dlls etc nachgereicht bis das Programm lief.
Die meisten Programme die da mitziehen, also ohne Installation funktionieren, werden bei mir auch nicht wieder installiert.
Läuft ja auch ohne, das sind halt so Kandidaten die dann auch gut auf so einer CD funktionieren.
Dann müssen die ja nur noch passend für die CD abgelegt werden ggf. irgendwo eingetragen werden wenn ein Programm die CD Erstellung übernimmt.
Gruß Dietmar
@Christoph
[autoit]$ini = @ScriptDir & "\tst.txt"
[/autoit][autoit][/autoit][autoit]If not FileExists($ini) Then
fileinstall("d:\tst.txt",$ini)
Else
MsgBox(0,"","Programm wurde schon mal gestartet.")
EndIf
Exit
Funktioniert einwandfrei, beim ersten Aufruf wird die Datei abgelegt beim zweiten kommt die Meldung.
Es muss beim ersten Aufruf ja nicht gleich das Programm zuende sein.
Was Du sagst trifft jedenfalls so nicht zu. fileinstall wird nicht IMMER ausgeführt, sondern nur wenn die Datei nicht da ist.
Ansonsten würde der Inhalt der Textdatei trotz einer Änderung ja immer wieder auf Auslieferungszustand gesetzt wenn das Programm erneut gestartet werden würde. Dem ist aber nicht so.
Gruss Dietmar
Ich steig nich mehr durch
Warum? Solltest Du für Dein Programm irgendwann ne Ini brauchen dann kannst Du diese mit fileinstall includieren/auspacken.
Sollte die Ini noch nicht da sein wurde das Programm noch nicht gestartet.
Gruß Dietmar
Außerdem kannst Du ja am Anfang prüfen ob die Ini da ist.
[autoit]If not FileExists($ini) Then
fileinstall(.....)
Else
MsgBox(0,"","Programm wurde schon mal gestartet.")
EndIf
würde es evtl. erst mal wieder auf "offen" setzen. 
C:\PROGRA~1\ISN
ist dein Problem UAC und was da noch so dranhängt von daher hat er ja auch geschrieben ,
es wird nun nach c:\ installiert (sofern kein anderes Setup gefunden wurde).
Dann liegen die Projekte die ja vom regulären Benutzer geändert werden, halt nicht im sensiblen Bereich.
Evtl. hat er jauch nur die alte Config/Ini angewandt.
Ich hatte ähnliche Probleme unter Programme mit UAC aktiv.
ich denke auch das 64 Bit Office ist das Problem, da steht MS ja auch nicht so zu 100% dahinter,
ich glaube das haben die nur versucht weil die einer damit geärgert hat, von wegen:" Wie habt Ihr nicht :)"
Wir haben ähnliche Probleme auf der Arbeit wegen den 64Bit DSN-Treibern und unsere Anwendung (32Bit) soll damit Daten austauschen....
Und das Mailgeraffel, aus unserer Anwendung mit Outlook kommunizieren, klappt mit der 64Bit Version so auch nicht mehr wie früher. Auf 32Bit Office umgestellt alle Probleme beseitigt.
Und hier, ist zwar alt aber .... http://www.chip.de/news/Office-20…b_43428002.html
Btw. das DOS-Zeitalter ist schon seit XP im Grunde vorbei. Von daher sich darauf zu beziehen wirkt eher wie eine mangelte Windowskenntnis von deiner Seite aus.
Nö, ich vergleiche nur nicht Äpfel mit Birnen, mir ging es darum welche Werkzeuge praktisch immer da sind und wie funktionell diese sind.
Und wenn ich nun Linux (Konsole) mit Windows + Scripting Tools (VBS WSH) vergleiche hinkt es imho etwas.
Btw. den Linux date Befehl finde ich besser lesbar, wenn hast Du denn für den DOS Synthax wiederbelebt.
Und z.B. solche lächerlichen Sachen wie in crontab eine Leerzeile nach dem letzten Cron nenne ich nicht komfortabel sondern unnötiger Blödsinn.
Touche, solchen Blödsinn findet man sicher in beiden Welten.
Es geht ja nicht um LinuxFanboy, klar ich nutze es aber aus einem bestimmten Grund. Ich versuche halt für das jeweilige Vorhaben das passende OS zu wählen.
Und da komme ich auch oft gut ohne Windows aus.
Jeder wie er mag, wollte ja nur daruaf hinaus, das sein Vorhaben mit (ba)sh im Prinzip Kleinkram ist und
es sicher auch nicht unpraktisch ist sich etwas in dem Linux/Unix Umfeld auszukennen. Und das wäre sicher nen guter Einstieg.
Gruß Dietmar
Was für ein Wiederspruch in sich.
ohne hier nen Flamewar loszutreten, hast Du Dich mal mit Datumsformatierungen unter DOS rumgequält
und Dir dann neidisch die Möglichkeiten des Linux "date" Befehls angesehen.
Nur weil Linux keine Maus benötigt ist es noch lange nicht unkomfortabel [PUNKT].
Oder bei >5000 Dateien multiple Datumsänderungen (je Datei) vornehmen in unter 12sec in einer virtuellen Maschine mit nem sed Einzeiler...Fragen?
Die Shell ist so mächtig, da hat Windows lange Zeit (und mit Bordmitteln schon gar nicht) nichts entgegen zu setzten gehabt.
Wie gesagt.. will ihn ja nicht von AuoIt abbringen aber manchmal ist es schon praktischer mit den nativen Möglichkeiten zu arbeiten.
Gruß Dietmar
Dann kann es ja fast nur eine Timinggeschichte sein, das die VM länger braucht als relle Hardware.
Mal nen paar großzügigere Pausen testweise einbauen...
Auch wenn es nicht zur Lösung direkt beträgt, befass Dich mit Linux
Da vieles, was unter Win mit Bordmitteln kaum machbar und mit AutoIt/Powershell/VBS funktional wurde,
unter Linux schon immer sehr komfortabel gewesen ist. --> Shellscripte
Google nach: cron(tab -e), date, tar & chmod +x ( <-- dein Script ausführbar machen)
vermutlich findest Du schon fertige Scripte weil Dein Wunsch nicht wirklich ungewöhnlich ist.
Gruß Dietmar
z.B.: http://www.jarrodgoddard.com/linux-web-host…-the-bash-shell
Wer wird Millionär?!
Na der Jauch,oder? 
Erst wenn man sich auf der VM per Remote anmeldet wird das entsprechende Fenster geschlossen.
Lässt Du Dein Script als geplanten Task laufen also also nicht zwingend nach der Anmeldung.
Dann ist das fast normal. Da Windows wenn der Desktop gesperrt ist, bzw. der User noch nicht angemeldet ist Tastatur- Mauseingaben blockiert.
Eine mögliche Lösung: Windows vmware mit automatischen Login auf einen ESX (-I), dann kann man mit der Konsole immer schön nachschauen.
Eine Alternative wäre vnc, da dort die Session auch offen bleibt, RDP geht nicht wenn man die Sitzung trennt ist wieder die Eingabe blockiert.
P.S.: Das ist allerdings kein vm Problem, sondern ein Feature von MS.
Gruß Dietmar
Jo stimmt.
Zuvor funktionelle Datei umbenannt und dann ist auch die inhaltlich hinüber.
Besten Dank, Problem verstanden.
Dietmar
Interessanter Denkansatz und vermutlich auch richtig, ich hatte eine ältere Liste auf "c:\" mit der klappte es. Allerdings hatte die den Namen "system_files.ini"
Im Prinzip darf man also keine Dateien nehmen die es schon namentlich für Windows gibt win.ini etc. oder Windows unmittelbar bekannt sind?
Euch vermutlich auch....aber seht selbst.
[autoit]
$abc = IniReadSectionNames("C:\Users\Dietmar\Desktop\SYSKomp\system.ini")
_ArrayDisplay($abc)
Exit
Kann mir jemand erklären wo die Einträge vor 11 - 15 herkommen,
keyboard etc stehen nicht in der Datei drin und ich vermute "system32",
Habe aber keine Ahnung wie er auf das schmale Brett kommt, da zu suchen.
Btw.: AutoIt Version: 3.3.6.1
Gruß Dietmar
