TweakUI im Eigenbau

Inhaltsverzeichnis

Erst die Vorlagendateien machen aus Poledit das, was es ist: ein Werkzeug zur einfachen, schnellen und sicheren Umsetzung von Windows-Tipps. Man muss einfach nur den richtigen Schalter drücken und hat die kompliziertesten Registry-Einträge schlicht per Mausklick erstellt oder geändert. Auch das Selberbauen solcher Schalter ist nicht schwer, Anwendern mit Programmierkenntnissen dürfte das sehr leicht von der Hand gehen. Mit einfachen Anweisungen, die nur aus wenigen Schlüsselwörtern bestehen, ergänzt man bestehende Vorlagen oder erstellt neue. Hierzu reicht ein simpler Text-Editor wie das Windows-eigene Notepad aus. Die fertigen Vorlagen speichert man als Datei mit beliebigen Namen und der Endung ADM.

Ein Tipp für Poledit besteht aus einzelnen in sich geschlossenen Eingriffen in die Registry, die einen Konfigurations-Kniff ergeben, genannt Richtlinie oder Policy. Eine Richtlinie kann einen oder mehrere Registry-Einträge in unterschiedlichen Schlüsseln den eigenen Wünschen entsprechend anpassen. Sie liefert hierfür Anweisungen an Poledit, welche Registry-Schlüssel, Einträge und Werte (siehe Bild) in welcher Weise zu bearbeiten sind. Die Anweisungen liegen in folgendem Format vor, das nur auf den ersten Blick kompliziert erscheint:

CLASS USER 
CATEGORY "Desktop" 
  CATEGORY "Startmenü" 
    POLICY "DOKUMENTE aus dem Startmenü entfernen" 
      KEYNAME "Software\Microsoft\Windows\CurrentVersion\Policies\Explorer" 
      VALUENAME "NoRecentDocsMenu" 
      VALUEON "1" 
      VALUEOFF Delete 
    END POLICY 
  END CATEGORY 
END CATEGORY

Diese Beispiel-Richtlinie veranlasst Windows, den Menüpunkt ‘Dokumente’ aus dem Startmenü auszublenden. Im Folgenden erläutern wir ihre Struktur und die einzelnen Anweisungen. Der Übersichtlichkeit halber empfiehlt es sich, sämtliche Schlüsselwörter in ADM-Dateien stets in Großbuchstaben zu schreiben. Aus dem gleichen Grund rückt man die einzelnen Richtlinien mit Tabstopps ein.

Zum Festlegen der Ebene (Kategorie) in der Baumansicht, in der die Richtlinie später in Poledit auftauchen soll, dient CATEGORY, welches mit einem END CATEGORY wieder abzuschließen ist. Mit den gleichen Befehlen kann man innerhalb einer Kategorie beliebig viele Unterkategorien verschachteln. Hinter jedem einleitenden CATEGORY muss eine Bezeichnung folgen, die später im Poledit erscheint und in kurzen Worten beschreibt, was in dieser Kategorie für Richtlinien enthalten sind . Die Bezeichnung darf zwar bis zu 256 Zeichen lang sein, jedoch stellt Poledit immer nur rund 65 Zeichen dar, sodass man sich kurz fassen sollte. Sie muss in Anführungszeichen stehen, falls Leerzeichen oder ein Semikolon enthalten sind. Die Einschränkungen gelten übrigens auch für alle anderen Parameter, sodass man grundsätzlich Anführungszeichen verwenden sollte. Sie schaden nichts, vermeiden jedoch viele Fehler.

Als Nächstes folgen die eigentlichen Richtlinien, von denen in jeder Kategorie beliebig viele enthalten sein können. Das Kommando POLICY leitet jede Richtlinie ein, END POLICY schließt sie ab. Für die mögliche Anzahl der Zeichen des Parameters hinter dem einleitenden POLICY gilt dasselbe wie für CATEGORY.

KEYNAME legt den genauen Unterschlüssel fest, in dem der zu manipulierende Registry-Eintrag enthalten ist. Allerdings ist der Schlüssel ohne Angabe des Hauptschlüssels zu schreiben, den ja bereits das CLASS-Kommando festgelegt hat. Der Schlüsselname darf weder einen vorangestellten noch ein beendenden Backslash enthalten. Ist in den nachfolgenden Richtlinien der gleichen Kategorie kein neuer KEYNAME benannt, gilt der bisher gültige weiter.

Den zu ändernden Wert in der Registry benennt VALUENAME, die Schlüsselwörter VALUEON und VALUEOFF schließlich legen den Wert des Eintrags beim Ein- und Ausschalten der Richtlinie in Poledit fest.

Beim Setzen des Häkchens vor dem Registry-Tipp trägt Poledit nun den mit VALUENAME benannten Eintrag in den mit CLASS und KEYNAME festgelegten Schlüssel ein und weist ihm dem mit VALUEON festgelegten Wert zu. In diesem Fall also legt Poledit beim Setzen des Häkchens einen Eintrag namens ‘NoRecentDocsMenu’ im Schlüssel HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer an und weist ihm den Wert ‘1’ zu. Das veranlasst Windows, den Menüpunkt ‘Dokumente’ aus dem Startmenü auszublenden. Beim Entfernen des Häkchens löscht Poledit den Eintrag wieder, da für VALUEOFF hier statt eines ebenso möglichen Wertes das Schlüsselwort ‘Delete’ festgelegt ist - daraufhin erscheint der Menüpunkt im Startmenü wieder [1].

Mit der im Beispiel genannten Anweisung lassen sich nur einfache Registry-Manipulationen durchführen. Die Poledit-Vorlagen sind dank weiterer Schlüsselwörter jedoch weitaus leistungsfähiger. Am einfachsten lassen sich die weiteren Möglichkeiten am konkreten Beispiel erläutern. Wir haben hierzu eine eigene Vorlage mit Beispiel-Richtlinien erstellt, die unter dem Namen ct-vorlage.adm auf unserer Homepage zum Download bereit steht, zu finden über den Soft-Link am Ende des Artikels.

Zeichenkette

Das bisherige Beispiel legt einen Registry-Eintrag mit einem bestimmten Wert an, und zwar als Zeichenfolge (siehe S. 112 in c't 8/2002). In einigen Fällen muss der Eintrag jedoch als DWORD angelegt werden. Hierfür gibt es kein eigenes Kommando, stattdessen erledigen dies die Wert-Zuweisungen VALUEON und VALUEOFF: Ein NUMERIC zwischen dem Schlüsselwort und dessen Parameter veranlasst Poledit, keine Zeichenfolge, sondern einen DWORD-Eintrag in die Registry zu schreiben. Eine fertige Richtlinie sieht dann so aus:

POLICY "'Verknüpfung mit' entfernen" 
  KEYNAME "Software\Microsoft\Windows\CurrentVersion\Explorer" 
  VALUENAME "Link" 
  VALUEON Numeric 0 
  VALUEOFF DELETE 
END POLICY

Das Festlegen eines Eintrags als DWORD kann auch als Ausweg dienen, wenn eigentlich ein Binärwert in der Registry erwartet wird, der sich via Poledit nämlich nicht erzeugen lässt.

Die Kommandos VALUEON und VALUEOFF sind übrigens optional. Fehlt eines, erstellt Poledit selbsttätig eine Zeichenfolge mit dem Wert 1 (VALUEON) oder Wert 0 (VALUEOFF).

Verschönern

Die bisher genannten Beispiele haben einen Nachteil: Der Anwender erhält beim Verwenden von Poledit nur spartanische Informationen über die Auswirkungen seines Tuns. Um das zu ändern, fügt man weitere Kommandos ein:

POLICY "EINSTELLUNGEN - SYSTEMSTEUERUNG und DRUCKER entfernen" 
  KEYNAME "Software\Microsoft\Windows\CurrentVersion\Policies\Explorer" 
  VALUENAME NoSetFolders 
  PART "Entfernt im Startmenü unter EINSTELLUNGEN die Punkte"  TEXT END PART 
  PART "SYSTEMSTEURUNG und DRUCKER. Setzt aus unerfindlichen"  TEXT END PART 
  PART "Gründen auch die Tasten-Kombination <Win>+<E>  außer Kraft."  TEXT END PART 
END POLICY

Das Schlüsselwort PART, das immer mit END PART abzuschließen ist, erlaubt zusätzliche Einstellungen der Anweisung. Poledit bildet diese später in der unteren Fensterhälfte ab. In diesem Fall handelt es sich schlicht um einen zusätzlichen Hinweis-Text, der wie üblich zwischen Anführungsstrichen steht. Das zusätzliche TEXT kennzeichnet ihn als funktionslose Erklärung. Auch hier gilt wieder die Beschränkung auf rund 65 Zeichen Länge pro Zeile. Wer mehr zu sagen hat, schreibt einfach mehrere dieser Anweisungen hintereinander. Die Anzahl ist beliebig, allerdings passt nur eine begrenzte Anzahl von Zeilen in die untere Fensterhälfte von Poledit. Sind zu viele vorhanden, muss der Anwender scrollen.

Wie wäre es mit ...?

Nicht immer ist es damit getan, einen Registry-Eintrag wie einen Schalter an- und auszuknipsen. Stattdessen will der Anwender vielleicht selbst festlegen, welchen Wert er in die Registry eingetragen haben will. Auch dies geht mit PART zusammen mit einer weiteren Anweisung:

POLICY "EIGENE DATEIEN verschieben" 
  PART "Erzeugt den Ordner EIGENE DATEIEN an anderer Stelle"  TEXT END PART 
  PART "neu, verschiebt jedoch nicht dessen bisherigen Inhalt."TEXT END PART 
  PART "Neuer Pfad:"  EDITTEXT EXPANDABLETEXT 
  REQUIRED 
  VALUENAME Personal 
  END PART 
END POLICY

Das Kommando EDITTEXT veranlasst Poledit, ein Eingabefeld in der unteren Fensterhälfte zu erzeugen, das der Anwender beliebig füllen kann. Wer den Anwender dazu zwingen will, das Feld auszufüllen, verwendet zusätzlich die Anweisung REQUIRED - Poledit weigert sich in diesem Fall, die Richtlinie unausgefüllt zu aktivieren. Schließlich erlaubt das ebenfalls optionale EXPANDABLETEXT, unter NT, 2000 und XP eine weitere Art des Registry-Eintrags zu verwenden: die erweiterbare Zeichenfolge. Die kann im Unterschied zur normalen Zeichenfolge auch eine Umgebungsvariable in der Form %VARIABLE% enthalten, die Windows bei einer Abfrage des Wertes gegebenenfalls durch deren Inhalt ersetzt (siehe S. 112). Unter 9x und ME hingegen ignoriert Poledit die Anweisung schlicht und erstellt eine normale Zeichenfolge. Zusätzlich kann man EDITTEXT auf Wunsch um MAXLEN ergänzen, um die maximale Länge der einzugebenden Zeichenkette festzulegen, sowie um DEFAULT, das einen Wert für das Eingabefeld vorgibt, sofern in der gerade bearbeiteten Registry oder POL-Datei kein anders lautender Wert vorhanden ist.

Mach mal einen Vorschlag!

Um dem Anwender beim Ausfüllen eines solchen Eingabefeldes zu helfen, kann man ihm verschiedene Vorschläge machen, welche Einträge sinnvoll sind. Auch hier kommt wieder PART zum Tragen, allerdings in Kombination mit einem anderen Schlüsselwort:

POLICY "Mausrad" 
  KEYNAME "Control Panel\Desktop" 
  PART "Gibt die Anzahl der Zeilen an, die bei einer Mausrad-Bewegung"  TEXT END PART 
  PART "verschoben werden. Seitenweises Scrollen: -1, Scrollrad aus: 0"  COMBOBOX 
    VALUENAME "WheelScrollLines" 
    MAXLEN 2 
    REQUIRED 
    DEFAULT "3" 
    SUGGESTIONS "-1" "0" "1" "2" "3" "4" "5" "6" "7" "8" 
    END SUGGESTIONS 
  END PART 
END POLICY

Das Kommando COMBOBOX beschreibt ein Eingabefeld, in das der Anwender selbst etwas eintragen und zusätzlich aus einer Liste von Vorschlägen (SUGGESTIONS) auswählen kann. Die Vorschläge, bei denen es sich um beliebige Zeichenfolgen handeln kann, stehen in Anführungszeichen und sind durch ein einfaches Leerzeichen zu trennen. Zusätzliche optionale Anweisungen sind die bereits bekannten MAXLEN, welches die maximale Länge der einzugebenden Zeichenkette bestimmt, REQUIRED definiert wieder, dass ein Wert in diesem Eingabefeld stehen muss, und DEFAULT schließlich gibt wie gewohnt den Anfangswert des Eingabefeldes an.

Alle für einen

Wer mit einer Richtlinie gleich mehrere Registry-Manipulationen in einem Fenster anbieten will, nutzt CHECKBOX:

POLICY "DOKUMENTE im Startmenü"    
  KEYNAME "Software\Microsoft\Windows\CurrentVersion\Policies\Explorer" 
  PART "Entfernt den Ordner DOKUMENTE aus dem Startmenü." CHECKBOX 
  VALUENAME "NoRecentDocsMenu" 
  END PART 
  PART "Protokollierung der zuletzt geöffneten Dokumente stoppen"  CHECKBOX 
  VALUENAME "NoRecentDocsHistory" 
  END PART 
  PART "Liste der zuletzt geöffneten Dokumente löschen" CHECKBOX 
  VALUENAME ClearRecentDocsHistoryOnExit 
  END PART 
END POLICY

Der Befehl CHECKBOX veranlasst Poledit, in der unteren Fensterhälfte ein zusätzliches Feld zum Setzen oder Löschen von Häkchen anzuzeigen. Da bei diesem Beispiel die Standardwerte für VALUEON und VALUEOFF ausreichen, fehlen die Kommandos hier, bei Bedarf lassen sie sich hier aber wie üblich einsetzen.

Listen bearbeiten

In einigen Fällen liegt in der Registry ein Schlüssel, der gleich mehrere Einträge enthält, die man auch alle auf einmal bearbeiten möchte. Auch dies stellt mit Poledit kein Problem dar:

POLICY "Run" 
  KEYNAME "Software\Microsoft\Windows\CurrentVersion\Run" 
  PART "Bearbeiten der automatischen Programmstarts des angemeldeten" TEXT END PART 
  PART "Users. Mit 'Projekt' ist der Pfad des automatisch zu startenden" TEXT END PART 
  PART "Programms gemeint."  LISTBOX 
  VALUEPREFIX "Pol-Start" ADDITIVE 
  END PART 
END POLICY

Die Anweisung LISTBOX produziert einen Knopf in der unteren Fensterhälfte von Poledit, der nach einem Klick darauf ein neues Fenster öffnet. Hierin erscheint eine Liste mit allen Einträgen und Werten, die im Schlüssel enthalten sind - in diesem Fall automatisch startende Programme [2]. Hier kann man mit der Anweisung ADDITIVE Einträge hinzufügen oder auch löschen, ohne ADDITIVE ersetzen neue Einträge die bestehenden. Das ebenfalls nicht zwingend erforderliche VALUEPREFIX legt die Namen der Einträge fest: Da die hier egal sind, weil es nur auf den Wert ankommt, bekommen alle Einträge denselben Namen, den Poledit zusätzlich mit einer Zahl versieht, die es hochzählt.

Alle auf einmal

Soll der Anwender gar nicht erst zwischen den verschiedenen zu manipulierenden Registry-Einträgen auswählen können, sondern stattdessen ein Mausklick gleich eine Reihe von Einträgen in der Registry verändern, kann man dazu eine Liste erstellen: Zwischen den Kommandos ACTIONLISTON und END ACTIONLISTON steht dann alles, was Poledit beim Setzen des Häkchens vor der Richtlinie erledigen soll, zwischen ACTIONLISTOFF und END ACTIONLISTOFF alles, was beim Entfernen des Häkchens zu tun ist. Anzugeben sind jeweils wie gewohnt der KEYNAME, der VALUENAME sowie - und das ist hier neu - der VALUE, der sich in seiner Funktion aber von VALUEON oder VALUEOFF nicht unterscheidet. Kleiner Haken: Vor dem Start der ACTIONLIST ist bereits ein KEYNAME anzugeben, sonst kommt es beim Einlesen der ADM-Datei in Poledit zu einer Fehlermeldung. Eine fertige Liste könnte so aussehen:

POLICY "DOS-Box aus Explorer" 
  KEYNAME "Software\CLASSES\Directory\Shell\DOSBox\command" 
  PART "DOS-Box mit dem gerade aktuellen Verzeichnis öffnen" TEXT END PART 
  ACTIONLISTON 
  VALUENAME "" VALUE !!DOSBOXan 
  KEYNAME "Software\CLASSES\Directory\Shell\DOSBox" 
  VALUENAME "" VALUE "&DOS-Box von hier" 
  KEYNAME "Software\CLASSES\Drive\Shell\DOSBox\command" 
  VALUENAME "" VALUE !!DOSBOXan 
  KEYNAME "Software\CLASSES\Drive\Shell\DOSBox" 
  VALUENAME "" VALUE "&DOS-Box von hier" 
  END ACTIONLISTON 
  ACTIONLISTOFF 
  VALUENAME "" VALUE "" 
  KEYNAME "Software\CLASSES\Directory\Shell\DOSBox" 
  VALUENAME "" VALUE "" 
  KEYNAME "Software\CLASSES\Drive\Shell\DOSBox\command" 
  VALUENAME "" VALUE "" 
  KEYNAME "Software\CLASSES\Drive\Shell\DOSBox" 
  VALUENAME "" VALUE "" 
  END ACTIONLISTOFF 
END POLICY

[Strings] 
DOSBOXan=command.com /k cd "%1"

Diese Richtlinie legt in den Kontextmenüs der Ordner und der Laufwerke im Explorer einen neuen Eintrag namens ‘DOS-Box von hier’ an. Klickt der Anwender darauf, führt Windows den Befehl command.com /k cd "%1" aus. Daraufhin öffnet sich eine DOS-Box, bei der man sich im gerade aktuellen Ordner oder Laufwerk befindet.

Zwei Besonderheiten zeichnen diese Richtlinie aus. Erstens stehen hinter dem VALUENAME zwei Anführungsstriche direkt hintereinander. Hier wurde nicht etwa vergessen, den Wert einzutragen, stattdessen stehen sie für den Eintrag ‘(Standard)’, den jeder Registry-Schlüssel als obersten Eintrag enthält.

Zweitens steht der Befehl, der diesem ‘(Standard)’-Eintrag zugeordnet werden soll, nicht als Klartext dahinter, sondern als Variable, die ein am Ende der ADM-Datei stehender Abschnitt namens [Strings] auflöst. Grund dafür sind die im Befehl enthaltenen Anführungsstriche. Ohne sie wäre der Befehl unvollständig, doch Poledit interpretiert sie oberhalb von [Strings] als Ende eines Parameters anstatt als Bestandteil. Das Dilemma umgehen die Variablen, deren Namen aus einer Zeichenfolge ohne Leer- oder Satzzeichen bestehen müssen und immer mit zwei Ausrufungszeichen beginnen. Der eigentliche Text, der später in Poledit an Stelle der Variablennamen zu lesen ist, steht dann ohne zusätzliche Anführungsstriche im besagten Abschnitt, und zwar hinter dem Variablennamen - diesmal ohne Ausrufungszeichen - sowie einem Gleichheitszeichen. Alles Weitere in der Zeile gilt dann unabhängig von den verwendeten Zeichen als Text.

Es gibt noch einen weiteren Grund, die Variablen zu verwenden: Man muss Text, der mehrfach auftauchen soll, nur einmal schreiben. Microsoft verweist zudem darauf, dass sie die Übersetzung in andere Sprachen erleichtern, was man für den Hausgebrauch aber wohl nur selten benötigt. Das zusätzlich nötige Hin- und Herscrollen zwischen den Anweisungen und den Variablen spricht schließlich eher gegen deren Verwendung, solange sie nicht zwingend erforderlich ist: Die Übersichtlichkeit leidet sonst.

Selbst ist der Mann

Mit den bislang beschriebenen Beispielen sollte jeder ausreichend Hilfestellung haben, um selbst mal eben auf die Schnelle eine Vorlage für Poledit zu erstellen oder zu erweitern. Es reicht einfach aus, aus der von c't zur Verfügung gestellten ct-vorlage.adm eine Richtlinie in die gewünschte ADM-Datei rüberzukopieren und die Kommandos den eigenen Bedürfnissen entsprechend anzupassen. Einige kurze Kommentare in der Vorlage - die grundsätzlich hinter einem Semikolon stehen - helfen bei der Auswahl der passenden Richtlinie.

Allerdings handelt es sich hier eben nur um Beispiele, die zwar als Basis zum Selberbasteln eigener Richtlinien für die meisten Anwendungsfälle ausreichend sein dürften, die Leistungsfähigkeit der Vorlagen aber noch nicht vollständig zeigen können. Wissbegierige finden jedoch reichlich Literatur im Internet, wo etwa der Buchverlag O’Reilly freundlicherweise ein wichtiges Kapitel eines Buches [3] online gestellt hat, oder auch in Microsofts Knowledge Base im Artikel Q161334 (die deutsche Übersetzung hat die Artikelnummer D42304).

Poledit leidet jedoch auch unter einigen Einschränkungen: So gibt es deutlich mehr Eintrags-Typen in der Registry, als Poledit bearbeiten kann: Das Programm kann unter 9x nur Zeichenfolgen und DWORDs, unter XP und Co zusätzlich noch erweiterte Zeichenfolgen erstellen, den Umgang etwa mit Binärwerten beherrscht sie jedoch nicht. In der Praxis dürfte dies jedoch kaum eine Rolle spielen, da sich die genannten Binärwerte üblicherweise durch DWORDs ersetzen lassen.

Ein echtes Ärgernis hingegen ist die fehlende Möglichkeit, Werte in Abhängigkeit ihres bisherigen Wertes zu bearbeiten. Stattdessen muss man bereits beim Erstellen der Vorlage genau wissen, was man als Wert eintragen möchte. So legt zum Beispiel ein einziger Eintrag durch gesetzte oder gelöschte Bits fest, welche Laufwerke der Explorer anzeigt und welche nicht. Um einen bestehenden Eintrag mit Wert 10, der die Laufwerke B (2) und D (8) bereits ausblendet, zusätzlich um Laufwerk E zu erweitern, müsste man 16 addieren, was aber mit Poledit nicht geht, weil man den bisherigen Wert zwar angezeigt bekommt, ihn aber nicht durch das Programm weiterverarbeiten lassen kann. Noch ein Manko: Poledit beherrscht auch den Umgang mit variablen Schlüsselnamen nicht, wie sie zur Kennzeichnung von Hardware-Komponenten nach Hersteller und Modell auftreten, etwa bei Netzwerkkarten.

Doch letztlich sind die Mängel nicht geeignet, die Freude an dem Werkzeug Poledit wirklich zu trüben: Die allermeisten Registry-Einträge lassen sich damit schnell, einfach und sicher umsetzen, und kein anderes uns bekanntes Werkzeug ist so flexibel erweiterbar und zudem auch im Netzwerk einsetzbar. (axv)

Literatur

[1] Axel Vahldiek, Schnellzugriff, Der Dokumentenordner im Startmenü, c't 6/02, S. 258

[2] Axel Vahldiek, Start me up, Automatischer Programmstart unter Windows 9x und ME, c't 17/01, S. 208

[3] Stacey Anderson-Redick, Windows System Policy Editor, O’Reilly, ISBN 1-56592-649-8

[4] Als Buch: Microsoft Windows XP Professional, Die Technische Referenz, ISBN: 3-86063-934-X, Online (englisch): www.microsoft.com/technet/prodtechnol/winxppro/reskit/prork_overview.asp

---

Poledit und ADM-Dateien für Windows 2000 und XP

Mit den Gruppenrichtlinien für Windows 2000 und XP (siehe Kasten in c't 8/2002 S. 106) hat Microsoft die in den Vorlagedateien benutzte ‘Sprache’ erweitert. Allerdings fallen diese Erweiterungen verhältnismäßig gering aus. Sie betreffen eher die Optik als die eigentliche Funktion. Mit geringem Aufwand ist es möglich, solche modernen Vorlagen auch mit einem älteren Poledit zu bearbeiten.

Über das Schlüsselwort EXPLAIN kann man umfangreicheren erklärenden Text zu einzelnen Richtlinien ablegen. Der Gruppenrichtlinieneditor aus Windows 2000 und XP Professional zeigt diese an. Um sie auch im Poledit angezeigt zu bekommen, ersetzt man EXPLAIN durch PART und schreibt zusätzlich TEXT END PART ans Ende der Zeile. Alternativ lässt sich die Anweisung auch einfach löschen.

Am Schlüsselwort SUPPORTED erkennt der Editor, welche Betriebssystemversion die einzelnen Richtlinien unterstützt, und weist bei der Bearbeitung entsprechend darauf hin - mit dem Erscheinen von Windows XP musste Microsoft nicht nur 2000, sondern auch XP als Client bedienen und die Richtlinien entsprechend erweitern. Streicht der Anwender dieses Schlüsselwort und seinen Parameter, verliert er zwar die Information, die Richtlinie funktioniert jedoch weiterhin - allerdings nun mit dem Risiko, unter anderen als dem unterstützten Betriebssystem unwirksam oder gar schädlich zu sein.

Darüber hinaus zeichnen sich die modernen ADM-Dateien durch Abfragen der Version des einlesenden Werkzeugs aus (‘#if’-Zeilen). Dadurch sollen ältere Fassungen unter anderem bestimmte Konstrukte innerhalb der Dateien ausblenden. Nimmt man etwa einen Poledit aus Windows 2000 her und setzt ihm die mit Windows XP Professional gelieferten Vorlagen vor, etwa die system.adm-Datei, so zeigt der Editor nur einen Hinweis an, dass er diese nicht anwenden kann. (Die zum Lieferumfang von Windows 2000 und XP Professional gehörenden ADM-Dateien hat Microsoft im inf-Verzeichnis der jeweiligen Windows-Installation untergebracht.)

Löscht man in der system.adm-Datei das erste ‘#if version <= 2’ nebst zugehörigem ‘#endif’ sowie außerdem das unmittelbar folgende ‘#if version >= 3’ mit zugehörigem ‘#endif’ (vor dem Abschnitt [strings]), so bietet der mit Windows 2000 Server gelieferte Poledit alle in der Vorlage definierten Optionen zur Bearbeitung an - ebenso wie diese im Gruppenrichtlinieneditor erscheinen. Bei anderen Vorlagedateien ist analog zu verfahren, insbesondere gilt das für Einschränkungen in der Datei, die auf Versionsnummer >= 3 vergleichen.

Eine weitere Tücke stellt das Dateiformat der Vorlagedateien selbst dar. Moderne Dateien liegen nicht in ANSI-, sondern Unicode-Kodierung vor. Sollen die überarbeiteten Vorlagen in einer älteren Poledit-Version bearbeitet werden, muss man sie zuvor in ANSI konvertieren. Das geht unter Windows XP problemlos mit dem mitgelieferten Notepad. Man öffnet die jeweilige ADM-Datei mit dem Editor und wählt dann bei ‘Speichern unter’ ANSI als Dateiformat. Die Manipulationen an ADM-Dateien, die eigentlich nicht für den klassischen Poledit gedacht sind, dokumentiert Microsoft übrigens in der technischen Referenz (Resource Kit) zu Windows XP [4] - allerdings nicht vollständig. (ps)

---

Werkzeugkasten

Zum Erstellen einer Vorlage für Poledit reicht der Windows-eigene Texteditor Notepad.exe eigentlich aus, da ADM-Dateien nichts weiter als Textdateien mit einer anderen Endung sind. Wer größere Vorlagen erstellen möchte, dürfte sich jedoch bald einen Editor wünschen, der Zeilennummern darstellen kann, da Poledit beim Einlesen der Vorlage gegebenenfalls Fehlermeldungen mit Zeilenangaben ausgibt - das beherrscht zum Beispiel die Shareware Ultraedit. Das Einlesen einer ADM-Datei in Poledit klappt nur dann, wenn die Datei formal korrekt ist, sonst beschwert sich Poledit eben mit einer Fehlermeldung, die die Zeilenzahl angibt, in der ein unerwartetes Kommando steht. Gleichzeitig macht das Programm Vorschläge, welche Anweisungen es stattdessen akzeptieren würde.

Poledit prüft allerdings nicht, ob die Registry-Schlüssel, -Namen und -Werte korrekt sind, und warnt auch nicht vor der Verwendung von Tipps, die womöglich fatale Folgen haben könnten. Hier muss der Programmierer der Vorlage selbst aufpassen, was er tut, und die Auswirkungen seiner Richtlinie dem Anwender möglichst deutlich beschreiben - es empfiehlt sich dringend, zum Ausprobieren einen speziellen Benutzer-Account einzurichten, der sich später problemlos wieder löschen lässt.

Das Bearbeiten von Vorlagen gestaltet sich übrigens bequemer, wenn man ADM-Dateien per Doppelklick mit dem gewünschten Text-Editor öffnen kann. Da die Dateien normalerweise mit keiner Anwendung verknüpft sind, erscheint nach einem Doppelklick ein Fenster, das verschiedene Programme zur Auswahl anbietet. Hier markiert man den gewünschten Text-Editor und setzt ein Häkchen vor ‘Diese Datei immer mit diesem Programm öffnen’. Zukünftig startet ein Doppelklick auf eine Vorlage immer den Editor. Sind ADM-Dateien bereits mit einer anderen Anwendung verknüpft, erscheint das benötigte Fenster nicht mehr. Dann genügt ein Klick mit der rechten Maustaste bei gleichzeitigem Gedrückthalten der Shift-Taste, um im Kontextmenü der Vorlage einen zusätzlichen Menüpunkt ‘Öffnen mit ...’ zum Vorschein zu bringen. Wählt man diesen an, erscheint das Fenster zur Auswahl des zu verknüpfenden Programms erneut. (axv)