Startseite   |  Site map   |  A-Z artikel   |  Artikel einreichen   |   Kontakt   |  
  


informatik artikel (Interpretation und charakterisierung)

Die syntax der vorlagedateien


1. Java
2. Viren

4.2.1. Das Schlüsselwort CLASSr / r /> Den Anfang jeder Vorlagedatei bildet der Schlüsselbegriff CLASS . Dieser wird im Zusammenhang mit einem Parameter aufgerufen, der entweder MACHINE (Computerrichtinie) oder USER (Benutzerrichtlinie) lautet. Angegeben wird dabei nur, welcher Hauptschlüssel der Registrierung bearbeitet werden soll. Wird so beispielsweise das Schlüsselwort USER verwendet, so weiß der Systemrichtlinieneditor, dass die Änderungen den Registrierungsschlüssel HKEY_CURRENT_USER betreffen. Gleiches gilt für den Parameter MACHINE, der Zugriffe auf den Schlüssel HKEY_LOCAL_MACHINE kennzeichnet.

Weiters ist es möglich, das Schlüsselwort CLASS mehrmals in ein und derselben Vorlagedatei zu verwenden. Hier erfolgt jedesmal eine Neudefinition des zu bearbeitenden Hauptschlüssels. Dies kann auch anhand des vorliegenden Quellcodes demonstriert werden, in dem in Zeile 1 das Schlüsselwort CLASS mit dem Parameter MACHINE aufgerufen wird. Dabei handelt es sich anfangs um eine Computerrichtlinie, die den Hauptschlüssel HKEY_LOCAL_MACHINE betrifft. In Zeile 78 erfolgt jedoch die abermalige Verwendung des Schlüsselbegriffes CLASS, diesmal im Zusammenhang mit dem Parameter USER. Von dieser Stelle an handelt es sich um eine Benutzerrichtlinie.

Darüber hinaus sollte dem Leser nun auch aufgefallen sein, dass das Schlüsselwort CLASS kein END-Statement benötigt, welches normalerweise einzelne Abschnitte einer Vorlagedatei abschließt. Hier genügt, wie schon erwähnt, eine Neudefinition von CLASS.

4.2.2. Das Schlüsselwort CATEGORY

Nachdem mit dem Schlüsselbegriff CLASS der erste Abschnitt definiert wurde, gilt es nun, diesen in einzelne Kategorien zu zerlegen. Dabei hilft einem das Schlüsselwort CATEGORY , welches den Anfang einer Kategorie kennzeichnet.

Auch der Schlüsselbgriff CATEGORY benötigt einen Parameter, nämlich , welcher entweder eine ganz normale Zeichenkette darstellt oder als ein Platzhalter für eine Zeichenkette, die in einem anderen Bereich definiert werden muss, fungiert.
Die Möglichkeit, die einem Kategorien bieten, ist jene der Unterteilung. So ist es beispielsweise möglich, dass einzelne Kategorien weitere Kategorien oder Sammlungen von Systemrichtlinien beinhalten. Im Idealfall sind jene so geordnet, dass sie entweder Änderungen im selben Registrierungsschlüssel betreffen, oder dass sie einen thematischen Zusammenhang bilden.

Die Verwendung von mehreren CATEGORY Abschnitten ist kein absolutes Muß, hat jedoch oft eine selbsterklärende Wirkung. An diesem Punkt möchte ich auf Zeile 3 des Quellcodes hinweisen, wo man den Schlüsselbegriff CATEGORY im Einsatz erlebt. Als Parameter wird in diesem Fall ein Platzhalter eingesetzt, der in einem anderen Bereich definiert ist.


4.2.3. Das Schlüsselwort END CATEGORY

Der Schlüsselbegriff CATEGORY verhält sich nicht so wie sein Pendant CLASS. Ein großer Unterschied zwischen den beiden ist, dass CATEGORY ein weiteres Schlüsselwort zum Beenden einer Kategorie benötigt. Somit wird der Einsatz von END CATEGORY notwendig, welches einzelne Kategorien schließt.


4.2.4. Das Schlüsselwort POLICY

Der Ausdruck POLICY wird verwendet um eine Systemrichtlinie zu kennzeichnen. Diese kann ein oder mehrere Einstellungen oder direkte Wertvorgaben enthalten und erscheint im Systemrichtlinieneditor als Checkbox. Wie auch der Schlüsselbegriff CATEGORY muss POLICY in Verbindung mit einem Parameter aufgerufen werden. Dieser beinhaltet die gleiche Funktion wie jener des Schlüsselwortes CATEGORY.


4.2.5. Das Schlüsselwort END POLICY

Das Schlüsselwort END POLICY hat die gleiche Aufgabe wie END CATEGORY. Der einzige Unterschied ist, dass END POLICY nicht eine Kategorie sondern eine Systemrichtlinie beendet.


4.2.6. Das Schlüsselwort KEYNAME

Durch das bereits bekannte CLASS-Statement ist der zu bearbeitende Hauptschlüssel schon festgelegt. Leider kann der Systemrichtlinieneditor anhand dieser spärlichen Information noch keine Werte in der Registrierung verändern. Eine genauere Definition ist hier notwendig. Dazu wird der Schlüsselbegriff KEYNAME eingesetzt, der den kompletten untergeordneten Pfad von diesem Hauptschlüssel zum Schlüssel der Registrierung, auf den sich die Richtlinie bezieht, bezeichnet. Der Parameter, der dem Statement folgt, gibt den Pfad an, der zu dem gewünschten Registrierungseintrag führt.

Verwendet wird das Schlüsselwort KEYNAME meistens in einem CATEGORY-Abschnitt, wie es das Beispiel in Zeile 24 demonstriert. Eine weitere Möglichkeit ist es, den Schlüsselbegriff innerhalb eines POLICY-Abschnittes einzusetzen, wie man es anhand der Programmiertechnik aus Zeile 5 erkennen kann.

Wie auch das Schlüsselwort CLASS verlangt KEYNAME kein abschließendes Statement, welches den Definitionsbereich schließt.


4.2.7. Das Schlüsselwort PART

Mit dem Statement PART wird ein Abschnitt definiert, der Einstellungen für eine Systemrichtlinie kennzeichnet. Dieser kann im Vergleich zu Abschnitten, die mit den Schlüsselbegriffen CATEGORY und POLICY erzeugt wurden, keine weiteren Unterabschnitte mehr enthalten. So dient der mit PART erzeugte Bereich zum Manipulieren von Registrierungseinträgen und zum Ausgeben eines Erklärungstextes für die aktuelle Richtlinie.

Aufgrund des vorliegenden Quellcodes kann das Verhalten des Schlüsselwortes PART besser verstanden werden. In Zeile 7 wird beispielsweise ein PART-Abschnitt erzeugt. Auffallend ist, dass er eine ähnliche Funktion ausübt wie die Schlüsselbegriffe CATEGORY und POLICY. Ein PART-Bereich ist aber der kleinste Abschnitt, den man in Vorlagedateien erzeugen kann. Innerhalb eines PART-Abschnittes folgen danach Anweisungen, die zum Bearbeiten der Registrierung oder zur Ausgabe eines Informationstextes dienen.


4.2.8. Das Schlüsselwort END PART

Immer wenn in einer Vorlagedatei ein Abschnitt definiert wird, so muss dieser am Ende wieder geschlossen werden (Ausnahme: CLASS-Bereiche). Dies ist auch bei dem Schlüsselwort PART der Fall, welches zum Beenden das Statement END PART einsetzt.


4.2.9. Das Schlüsselwort EDITTEXT

Das EDITTEXT Statement erzeugt ein Eingabefeld für Zeichenketten, welches zur Bearbeitung von Werten des Datentyps REG_SZ vorgesehen ist.
Weiters ist zu sagen, dass es nur in einem vom Schlüsselwort PART definierten Abschnitt eingesetzt werden kann. Außerhalb dieses Bereiches ist EDITTEXT nicht einzusetzen.

4.2.10. Das Schlüsselwort VALUENAME

Mit dem Schlüsselbegriff VALUENAME kann man den Wertnamen innerhalb eins Registrierungsschlüssel definieren, der von der Richtlinie betroffen ist. Der Hauptschlüssel und die Unterschlüssel selbst müssen jedoch vorher von einem KEYNAME-Statement festgelegt werden. Der Parameter, den VALUENAME verlangt, stellt den Wertnamen dar, der dann von der Richtlinie verändert werde kann.
Dies kann man auch anhand des Beispiels erkennen, wo das KEYNAME-Statement beispielsweise in Zeile 5 steht. Darauf folgt die Definition eines PART-Abschnittes (Zeile 7), der wiederum das Schlüsselwort VALUENAME (Zeile 8) enthält.


4.2.11. Das Schlüsselwort NUMERIC

Der Befehl NUMERIC erzeugt ein Feld mit einem Stellrad für die Eingabe numerischer Zeichen. Dieser Typ erlaubt das Ändern von Werten der Typen REG_DWORD und REG_SZ. Das Schlüsselwort NUMERIC arbeitet daher ähnlich wie das EDITTEXT-Statement. Daher kann es auch nur innerhalb eines PART-Abschnittes verwendet werden.




4.2.12. Das Schlüsselwort MIN

Mit dem Befehl MIN kann man den Minimalwert eines Eingabefeldes setzen. Bei jenen Eingabefeldern, bei denen dieses optionale Attribut nicht verwendet wird, ist der Minimalwert standardmäßig 0. Weiters ist es auch möglich den Minimalwert mit einer negativen Zahl zu belegen, was jedoch nur bei wenigen Richtlinien gebraucht wird. Der Parameter, der dem Statement übergeben wird, legt den Minimalwert fest.

4.2.13. Das Schlüsselwort MAX

Das Schlüsselwort MAX legt den Maximalwert eines Eingabefeldes fest. Ist dieses Attribut nicht gesetzt, so wird als Standardwert 9999 verwendet. Ebenso wie der Befehl MIN erwartet MAX einen Parameter, der den Maximalwert des Eingabefeldes entgegennimmt. Diesem können jedoch nicht nur Zahlen übergeben werden, die kleiner als 9999 sind, sondern auch solche, die um ein Vielfaches größer sind.

4.2.14. Das Schlüsselwort SPIN

Das SPIN -Statement gibt das Intervall an, mit dem der Wert im Eingabefeld steigt beziehungsweise sinkt, wenn auf das Stellrad geklickt wird. Das Standardintervall ist 1. Wird dem Befehl SPIN als Parameter der Wert 0 übergeben, so werden die Einstellregler auf der Seite des Eingabefeldes entfernt.

Ein Beispiel für die Verwendung der Befehle NUMERIC, MIN, MAX und SPIN kann man in der Zeile 28 finden. Das Ergebnis ist ein Eingabefeld mit Einstellreglern, welches als Minimalwert 0 erhalten kann, als Maximalwert 1000, und welches bei Betätigung der Regler den Wert um jeweils 1 vergrößert oder verringert.

4.2.15. Das Schlüsselwort VALUEON

Ist das Kontrollkästchen einer Systemrichtlinie im Systemrichtlinieneditor aktiviert, so wird dem aktuellen Registrierungseintrag, der vorher durch den Befehl VALUENAME festgelegt wurde, dieser Wert zugewiesene. VALUEON verlangt einen Parameter, der bei Aktivierung einer Richtlinie in die Registrierung eingetragen wird.

Im Quellcode kann man ein solches Beispiel in Zeile 40 finden. Dort wird es in Verbindung mit dem Parameter Schlüsselwort NUMERIC eingesetzt. Das Ergebnis ist, dass bei Aktivierung der Richtlinie der Wert 1 als Datentyp REG_DWORD in der Registrierung eingetragen wird.

4.2.16. Das Schlüsselwort VALUEOFF

Der Schlüsselbegriff VALUEOFF arbeitet ähnlich wie VALUEON. In diesem Fall wird der als Parameter übergebene Wert aber nur eingetragen, wenn die Richtlinie im Systemrichtlinieneditor deaktiviert wird. Natürlich muss man auch hier darauf achten, dass vorher mit dem Befehl VALUENAME ein Wert definiert wird, den es zu verändern gilt.
Verwendung findet das VALUEOFF-Statement in Zeile 41 des Quellcodes. Wiederum ist es mit dem Schlüsselwort NUMERIC gekoppelt, was bedeutet, dass bei Deaktivierung der Richtlinie der Wert 0 in der Registrierung unter dem vorgegebenen Eintrag gespeichert wird. Darüber hinaus sollte man erwähnen, dass dem VALUEOFF Befehl meistens der Schlüsselbegriff VALUEON vorangeht.


4.2.17. Das Schlüsselwort CHECKBOX

Mit dem CHECKBOX Befehl kann ein Kontrollkästchen erzeugt werden, welches Datentypen des Wertes REG_SZ manipulierbar macht. Wie es auch schon bei dem Statement EDITTEXT der Fall ist, kann das Schlüsselwort CHECKBOX nur in einem Abschnitt verwendet werden, der mit dem Schlüsselbegriff PART erzeugt wurde.


4.2.18. Das Schlüsselwort DROPDOWNLIST

Das Schlüsselwort DORPDOWNLIST stellt eine Drop-Down-Liste dar, bei der die Eingabe eines Textes nicht möglich ist.

Der Datentyp der Werte, die dieses Element bearbeiten kann, hängen von der näheren Definition der Auswahlliste ab. Weiters ist anzumerken, dass der Befehl DROPDOWNLIST nur innerhalb eines PART-Abschnittes eingesetzt werden kann.


4.2.19. Das Schlüsselwort REQUIRED

Mit dem Schlüsselbegriff REQUIRED lässt sich eine Eingabe des Benutzers erzwingen. Steht kein Wert in diesem Eingabefeld, so lässt sich die Richtlinie nicht aktivieren.


4.2.20. Das Schlüsselwort NOSORT

NOSORT ist ein spezieller Bezeichner, der nur in Verbindung mit dem Schlüsselwort DROPDOWNLIST eingesetzt werden kann. Es bewirkt, dass die Einträge, die in der Drop-Down-Liste aufscheinen, nicht alphabetisch sortiert werden.


4.2.21. Das Schlüsselwort ITEMLIST

Wie der Schlüsselbegriff NOSORT ist das ITEMLIST-Statement eng mit dem Erzeugen einer Drop-Down-Liste verbunden. Das Schlüsselwort ITEMLIST erzeugt eine Liste von Vorgaben, die dann in der Auswahlliste angezeigt werden. Vor dieser Aufzählung muss der zu ändernde Werte per VALUENAME bezeichnet sein (zwischen dem Schlüsselwort DROPDOWNLIST und ITEMLIST). Eine Vorgabe ist immer nach dem Muster NAME VALUE aufgebaut. Der Parameter Name ist dabei die Zeichenfolge, die in der Drop-Down-Liste erscheint. Den dazugehörigen Wert legt das Schlüsselwort VALUE über den Parameter Wert fest. Dabei werden Datentypen vom Typ REG_SZ in der Registrierung verändert oder eingetragen, es sei denn, es wird der Befehl NUMERIC vorangestellt, dann ist der Datentyp vom Wert REG_DWORD.

Ein Beispiel für eine Drop-Down-Liste findet sich im Quellcode von Zeile 99 bis Zeile 110. Dort wird zuerst mittels DROPDOWNLIST eine Liste erzeugt, die weiters mittels Gebrauch von REQUIRED eine verpflichtende Eingabe erwartet, ansonsten kann die Richtlinie nicht aktiviert werden. Der Befehl NOSORT verbietet der Drop-Down-Liste die Einträge nach dem Alphabet zu ordnen. Danach wird mit Hilfe des Schlüsselwortes VALUENAME der Registrierungseintrag definiert, der von der Richtlinie betroffen ist. Zu guter Letzt wird die Vorgabenliste mit Einträgen durch das ITEMLIST-Statement erzeugt, die dann in der Drop-Down-Liste aufscheinen.


4.2.22. Das Schlüsselwort END ITEMLIST

Das END ITEMLIST-Statement ist für das Beenden von Abschnitten, die mit dem Befehl ITEMLIST erzeugt wurden, zuständig. Dies kann man in der Zeile 110 sehen, wo eine Vorgabenliste mit einigen Einträgen geschlossen wird.


4.2.23. Das Schlüsselwort LISTBOX

Mit dem Schlüsselbegriff LISTBOX können Werte-Listen erstellt werden. Dazu wird ein eigenes Dialogfeld angezeigt, in dem man mittels der Schaltflächen Hinzufügen und Entfernen verschiedene Werte verändern kann. Das Schlüsselwort VALUENAME darf nicht in Verbindung mit LISTBOX verwendet werden, da der Werte-Name innerhalb der Liste zugeordnet wird.


4.2.24. Das Schlüsselwort VALUEPREFIX

Der Befehl VALUEPREFIX legt fest, ob die Wertnamen für die Liste fest vorgegeben und durchnummeriert werden. Es können dann nur diese Werte geändert werden. Lautet das Präfix zum Beispiel Daten, so erscheinen die Werte als Daten1, Daten2 und so weiter. Der Präfix kann dabei je nach Bedarf gewählt werden und wird dem Befehl VALUEPREFIX als Parameter übergeben.

Das Beispiel zu diesem Schlüsselwort findet man in Zeile 124. Vorher aber wird innerhalb eines PART-Abschnittes noch eine Werte-Liste durch das LISTBOX-Statement erzeugt. Danach muss der Schlüssel definiert werden, wo der Eintrag bearbeitet werden soll, was mittel KEYNAME ausgeführt wird. Erst jetzt kann man den Präfix, der die Daten durchnummeriert, mittels des Befehles VALUEPREFIX hinzufügen. Das Resultat dieser Vorgangsweise ist eine Werte-Liste, in der man einzelne Werte ändern, eintragen oder herauslöschen kann.


4.2.25. Das Schlüsselwort TEXT

Der Schlüsselbegriff TEXT kann ausnahmslos nur innerhalb eines PART-Abschnittes operieren. Dabei liefert er den Text, der als PART-Name angegeben wurde, ohne ein Eingabefeld im unteren Teil des Systemrichtlinieneditors. Der Begriff TEXT dient daher vor allem zum Einfügen von Erläuterungstexten.


4.2.26. Die Verwendung von Platzhaltern

Nachdem nun alle Schlüsselworte, die in dieser Vorlagedatei Verwendung finden, genau erklärt wurden, so stellt sich wahrscheinlich doch noch eine letzte Frage: "Was sind diese komischen Zeichen (z.B.: !!LaufwerkeWegschalten1), die anstatt einiger Parameter gebraucht werden?".

Dabei handelt es sich um sogenannte Platzhalter oder Variablen, die anstatt der Zeichenketten eingesetzt werden. Definiert werden diese aber erst zum Schluß der Vorlagedatei, nämlich im Bereich nach dem Eintrag [strings]. Ist die Vorlage nun im Systemrichtlinieneditor eingebunden, so erscheinen anstatt der Platzhalter jener Text, der der Variablen im [strings]-Abschnitt zugewiesen wird.
Eine andere Möglichkeit wäre es die Zeichenketten direkt nach den Schlüsselwörtern einzusetzen. Da aber einige von ihnen sehr lang sind würde die Vorlagedatei unübersichtlich und unlesbar werden. Deshalb ist es besser das System mit den Platzhaltern zu verwenden.

4.2.27. Das Einfügen von Kommentaren

Ein weiteres wichtiges Feature, welches die Skriptsprache von Microsoft unterstützt, ist das einbinden von Kommentaren in den Quelltext. Dazu muss man in einer Zeile nur einen Strichpunkt (;) einfügen, womit die ganze Zeile für eine Anmerkung zur Verfügung steht. Eine Kommentarzeile symbolisiert das folgende Beispiel:

; Dies ist ein Kommentar, welcher Richtlinien übersichtlicher gestaltet

Ist eine Vorlagedatei erst einmal in den Systemrichtlinieneditor eingebunden so werden die Kommentare entfernt und sind daher nicht mehr sichtbar. Dies ist der Grund warum Kommentare entweder nur während der Programmierung einer ADM-Datei nützlich sind oder nur das Verstehen der Syntax bzw. des Quellcodes erleichtert.

 
 

Datenschutz
Top Themen / Analyse
indicator Ausnahmebehandlung (Exception Handling) in C++
indicator TCP/IP-Netzwerke
indicator Moeglichkeiten des Internets
indicator Spyware
indicator Was ist Visual Basic:
indicator Keine Zeit für Nostalgie - Der Weg ins digitale Zeitalter
indicator Speicher:
indicator Mehr Sicherheit durch Verschlüsselung
indicator Das Risiko abschätzen
indicator Ein Beispiel


Datenschutz
Zum selben thema
icon Netzwerk
icon Software
icon Entwicklung
icon Windows
icon Programm
icon Unix
icon Games
icon Sicherheit
icon Disk
icon Technologie
icon Bildung
icon Mp3
icon Cd
icon Suche
icon Grafik
icon Zahlung
icon Html
icon Internet
icon Hardware
icon Cpu
icon Firewall
icon Speicher
icon Mail
icon Banking
icon Video
icon Hacker
icon Design
icon Sprache
icon Dvd
icon Drucker
icon Elektronisches
icon Geschichte
icon Fehler
icon Website
icon Linux
icon Computer
A-Z informatik artikel:
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z #

Copyright © 2008 - : ARTIKEL32 | Alle rechte vorbehalten.
Vervielfältigung im Ganzen oder teilweise das Material auf dieser Website gegen das Urheberrecht und wird bestraft, nach dem Gesetz.
dsolution