Die geheimen #SPI: - Compiler-Direktiven

Moderator: MVogt

Post Reply
User avatar
Theo_Gottwald
Posts: 367
Joined: 03. Oct 2009, 08:57
Location: Herrenstr.11 * 76706 Dettenheim
Contact:

Die geheimen #SPI: - Compiler-Direktiven

Post by Theo_Gottwald » 09. Apr 2018, 10:16

Beim Test einer zukünftigen MPR Version fällt mir auf, daß in der Hilfe einige SPI:-Befehle nur mit dem Hinweis "Erläuterung auf Anfrage" versehen sind. Also so zusagen Geheimdirektiven.

Die Gruppe der #SPI:'s sind ja eigentlich keine Befehle sondern Direktiven für den Compiler.
Das erkennt man daran, dass diese stets mit einem Kommentarzeichen anfangen.
Und daher werden diese "Befehle" bzw. Direktiven vom eigentlichen, ausführenden "Robot" stets ignoriert.

Aber wozu sind sie dann gut?
Sie dienen dazu die EXE die man mit "Compile" erstellen kann, zu verändern.

Eines der undokumentierten Features ist hier

Code: Select all

#SPI:NoMutex
Ok, das bedeutet dass normalerweise alle EXE-Dateien die man mit dem MPR erstellt ein sogenanntes MUTEX haben.

Ein MUTEX ist ein "Ding" das beim Start einer Datei geprüft werden kann, um zum Beispiel festzustellen, ob diese Datei bereits läuft. Das ist nützlich, denn eine automatische Installation will man ja nur ein mal starten, und nicht noch ein zweites Mal.

Da geht es darum, daß man ja mit dem MPR auch zum Beispiel Help-Desk-Skripte machen kann.

Nun sendet man dem User so ein Skript - zum Beispiel über ein "shared Drive".
Und der User startet das Skript lokal.

Das ist kein Problem, denn MPR-Executables können ja auch Ihre eigenen Admin-Rechte mitbringen (via in der EXE verschlüsseltes Passwort). So ein Skript kann zum Beispiel die Druckerumgebung reparieren.
Dann muß der Helpdeskmitarbeiter nicht von 100 Supportfällen 80 Mal das Gleiche machen.

Nun sind User ungeduldig. Und starten das automatische Support-Skript (also die EXE).

Aber die entpackt sich erst und so passiert nicht sofort etwas. Aber User sind ungeduldig.
Sie wissen ja nicht was da alles im Hintergrund passiert.

Also klicken die User noch Mal und nochmal ... und am Ende würde das Skript dann 5 Mal laufen!
Damit das nicht passiert hat jede MPR-Exe automatisch ein "Mutex".

Wenn man also ein Skript das bereits läuft noch mal starten will, dann hört man nur ein "Bing" (Systemsound).
Das bedeutet, dass der MUTEX den erneuten Start des bereits laufenden Skriptes verhindert hat. Alles Gut.

In seltenen Fällen kann es nun sein, daß man ein Skript mehrfach starten will.
Zum Beispiel ein Backup-Skript mit Parametern, was wohin gesichert werden soll.

In diesem Fall gibt man dann einfach das

Code: Select all

'#SPI:NoMutex
oben im Skript an, und erstellt dann die EXE. Dadurch weiß der EXE-Compiler, dass er hier kein Mutex einbauen soll.
Und dann kann man das gleiche Skript beliebig oft starten!

Ein weiteres aktuell nicht dokumentiertes SPI: ist das

Code: Select all

'#SPI:ForceUpdate
Bitte nicht verwechseln mit dem

Code: Select all

'#SPI:ForceWrite
dieses legt fest, dass neu erstellte Executable bereits vorhandene überschreiben. Fehlt es werden neu erstellte EXE-Dateien aufnummeriert. EXE_001.exe ... EXE_002.exe usw.

Das

Code: Select all

'#SPI:ForceUpdate
hat nun eine ganz andere Aufgabe. Da geht es darum, dass das MPR Skript vor dem Start Dateien auf dem Zielsystem entpackt. Das hat den Sinn zum Beispiel Setup-Dateien auf dem Ziel-PC zur Verfügung zu stellen.
Man kann jedoch alle Arten von Dateien in so eine EXE-Paket einpacken bis zur maximalen Dateigröße für EXE-Dateien von 2 Gigabyte.

Meistens hat man die für eine Installation benötigten Dateien in "?path\" das ist der Projektordner.
Also der Ordner den wir bei der Erstellung des Skripts für alle benötigten Dateien verwenden.
Da liegt auch das eigentlich Skriptfile drin.

Im Zielsystem ist unser Projektordner jedoch nicht vorhanden, also muß er zunächst von der EXE dort nachgebaut werden.
Dann kann das Skript dort 1:1 - wie in der Testumgebung - laufen.
Das geschieht normalerweise in einem neuen Unterordner im TEMP-Ordner. Weil das fix eingebaut ist muß man sich darum nicht kümmern.

Man kann jedoch auch Dateien an beliebigen Stellen auf dem Ziel-PC ablegen.
Und zwar schon beim Entpacken des Skriptes. Dazu gibt es die

Code: Select all

'#INC:[?path\Dateiname.xyz]->[Zielpfad]
Option.

Nur, was passiert nun wenn auf dem Zielsystem die Datei bereits vorhanden ist?
Dann kommt eine manuelle Messagebox. Die fragt dann was sie tun soll.

Das will man aber in der Regel nicht. Und hier kommt nun das

Code: Select all

'#SPI:ForceUpdate
Ins Spiel. Wird es angegeben, werden Dateien, die im Zielsystem bereits vorhanden sind einfach mit der Version aus der EXE überschrieben "Update".

Und last not least kann man mit:

Code: Select all

'#SPI:Diskfree=<Zahl> (MB)
verhindern, daß ein Setup-Paket auf einem PC startet, der nicht mehr genug Festplattenplatz auf der Systemfestplatte zur Verfügung hat.

Post Reply

Return to “Package Robot”

Who is online

Users browsing this forum: No registered users and 10 guests