Die Hälfte eines Windows-Programms, die kein Code ist

Ein Dialog ist ein Rechteck mit einer Überschrift, ein paar Zeilen festem Text, drei Eingabefeldern und zwei Schaltflächen. Fast nichts daran wird zur Laufzeit berechnet. Wo jedes Steuerelement sitzt, was auf jeder Schaltfläche steht, welche Schrift verwendet wird, in welcher Reihenfolge die Tabulatortaste durch die Felder läuft, welches Element zuerst den Fokus bekommt — all das steht vorher fest und liegt in der ausführbaren Datei in einem eigenen Bereich, direkt neben den Maschinenbefehlen und doch niemals ausgeführt. Dasselbe gilt für das Symbol in der Titelleiste, die Bitmap auf einem Startbild, das Menü am oberen Rand des Fensters, die Tabelle, die eine Tastenkombination einem Befehl zuordnet, und die Stringtabelle, aus der beim Laden jede Beschriftung der Oberfläche gelesen wird.

Diese Aufteilung ist der Grund, warum ein Programm in eine andere Sprache übertragen werden kann, ohne neu übersetzt zu werden, und warum jemand sein Aussehen verändern kann, der noch nie eine Zeile seines Quelltextes gesehen hat. Resource Hacker ist ein Betrachter und Editor genau für diesen Bereich. Richtet man ihn auf eine ausführbare Datei, läuft er durch das Ressourcenverzeichnis und zeigt den Inhalt als Baum: Symbole, Bitmaps, Zeiger, Dialoge, Menüs, Stringtabellen, Versionsinformationen, Anwendungsmanifeste und die binären Klumpen, für die es keine freundlichere Form gibt. Nichts davon ist geraten und nichts neu erzeugt — man sieht, was der Linker dort abgelegt hat.

Vier Verben, und das vierte wird unterschätzt

Das erste Verb heißt lesen. Vor jeder Änderung lohnt es sich, einfach nur hinzusehen, denn der Baum beantwortet Fragen, die sonst umständlich sind: wie viele Dialoge hat dieses Programm tatsächlich, liegt da noch eine Stringtabelle für eine Sprache, die niemand mehr benutzt, wurde diese Symbolgruppe aus mehreren Größen zusammengesetzt oder existiert nur eine einzige Größe, die das System gerade schlecht hochskaliert.

Das zweite Verb heißt bearbeiten. Text, Symbole, Bitmaps und ganze Dialoglayouts lassen sich an Ort und Stelle ändern — die sichtbare Oberfläche eines Programms, verändert ohne einen Compiler. Dialoge bekommen einen visuellen Editor, in dem Steuerelemente gezogen und in der Größe verändert werden; Menüs, Stringtabellen und Versionsblöcke bekommen ein Formular. Binäre Ressourcen lassen sich Byte für Byte flicken, was selten die richtige Antwort ist und gelegentlich die einzige.

Das dritte Verb heißt herausziehen. Jedes Symbol, jede Bitmap und jeder Zeiger lässt sich in eine Datei schreiben, und allein das rechtfertigt das Werkzeug für viele Anwender: die Symbole in einem seit Jahren aufgegebenen Programm sind oft die einzigen Exemplare, die überhaupt noch existieren. Das Herausziehen ist zugleich der Weg, eine Ressource auseinanderzunehmen, ihre Struktur zu verstehen und eine geänderte Fassung zurückzulegen.

Das vierte Verb macht aus dem Werkzeug erst etwas, das man wöchentlich benutzt: stapelweise arbeiten. Eine Ressource hinzufügen, eine löschen und eine ersetzen sind drei getrennte Vorgänge, und sie über eine Gruppe verwandter Programme hinweg auszuführen ist kaum schwieriger als ein einziges Mal. Für alle, die mehrere Builds desselben Programms pflegen, ist das der Unterschied zwischen einem Nachmittag und einer Kaffeepause.

Was das Bearbeiten eines Dialogs wirklich bedeutet

Der visuelle Editor ist bequem, und er verdeckt eine echte Einschränkung: ein Dialog wird in Einheiten ausgelegt, die keine Pixel sind. Ein Feld, dessen Breite für die Beschriftung einer Sprache berechnet wurde, schneidet die längere Beschriftung einer anderen ab, und ein Steuerelement, das man verschiebt, um Platz zu schaffen, überlappt manchmal einen Nachbarn, der vorher schon knapp saß. Wer Oberflächentexte ändert, sollte damit rechnen, hinterher nachzuziehen, und das Ergebnis bei mehr als einem Anzeigemaßstab prüfen, weil sich Dialogeinheiten nicht wie absolute Koordinaten verhalten.

Das Werkzeug legt außerdem das Ressourcenskript hinter dem Formular offen. Das zählt, sobald dieselbe Änderung in vielen Dialogen wiederholt werden muss: Text zu ändern ist schneller als Steuerelemente zu ziehen, und das Skript macht den Aufbau eines Layouts sichtbar, was die Zeichenfläche nicht leistet. Es ist zugleich die ehrliche Sicht darauf, was der Editor erzeugt — das Formular ist eine Schicht über der Ressourcendefinition und kein Ersatz für sie.

Wo das Werkzeug seinen Platz verdient

Lokalisierung ist der naheliegende Fall. Ein Programm zu übertragen, das nie für die Übersetzung gedacht war, heißt meistens, Stringtabellen und Dialoglayouts direkt zu bearbeiten, und genau dafür ist dieses Werkzeug gebaut. Oberflächenarbeit ist der zweite Fall: den Wortlaut einer Meldung ändern, ein veraltetes Symbol durch ein aktuelles ersetzen, ein Layout auflockern, das der ursprüngliche Autor zu eng hinterlassen hat. Spielmodifikation ist der dritte und der am schwersten vorhersagbare — in Spiele-Programmen stecken besonders viele Ressourcen, und ein großer Teil der kleinen Änderungen an Menüs, Startbildern und Oberflächengrafik ist nichts anderes als ein Ressourcentausch.

Die im Original genannten Gruppen — Entwickler, Oberflächengestalter, technisch sichere Anwender — sind die richtige Zielgruppe, und ihr gemeinsamer Nenner ist nicht Können, sondern Absicht. Das hier ist ein Werkzeug für Menschen, die etwas Bestimmtes ändern müssen und schon wissen, was dort stehen soll. Zum Erkunden taugt es schlecht, denn der Ressourcenbaum verrät kein Wort darüber, wozu ein Dialog dient.

Die Disziplin, die das Werkzeug nicht erzwingen kann

Alles hier schreibt unmittelbar in eine Datei, auf die andere Programme angewiesen sind, und die Art des Scheiterns ist kein Warndialog. Es ist ein Programm, das nicht mehr startet. Also gilt als erste Regel etwas Langweiliges ohne Verhandlungsspielraum: vor der ersten Änderung eine unberührte Kopie des Originals behalten, jedes Mal, auch bei dem Versuch, von dem man sicher ist, dass er klappt. Auf einer Kopie zu arbeiten und das Original wegzulegen kostet nichts und entfernt das schlimmste Ergebnis vollständig.

Die zweite Regel lautet, die Ressource zu verstehen, bevor man sie verändert. Ein Dialog ist eine Struktur und kein Bild; eine Stringtabelle ist indiziert, und ihre Indizes werden aus dem Code heraus angesprochen, sodass eine eingefügte Zeichenkette in der Mitte jede folgende Beschriftung verschiebt. Die dritte Regel ist, klein anzufangen: ein Symbol tauschen, prüfen, ob das Programm noch läuft, und erst dann den Dialog anfassen, auf den es ankommt. Diese Gewohnheiten sind unspektakulär, und sie sind der ganze Unterschied zwischen einem geänderten und einem kaputten Programm.

Was es nicht ist

Es ist keine Entwicklungsumgebung und es hilft nicht, Logik zu verstehen. Ressourcen beschreiben, wie ein Programm aussieht und wie seine Bestandteile heißen; das Verhalten wohnt im Code, den dieses Werkzeug bewusst nicht anfasst. Es ist auch kein Dekompiler, und beides zu verwechseln ist das häufigste Missverständnis: einen Dialog aus einer ausführbaren Datei zu ziehen und einen anderen zurückzulegen ist ein gewöhnlicher Vorgang, während aus Maschinencode wieder Quelltext zu gewinnen eine andere Tätigkeit mit anderem rechtlichem Gewicht ist. Das Werkzeug erledigt das erste und hält sich vom zweiten fern.

Genau genommen ist es ein sauber zugeschnittenes Hilfsmittel, das eine Aufgabe mit einer klaren Grenze erledigt. Es liest ein dokumentiertes Dateiformat, zeigt den Inhalt ehrlich, lässt ihn ändern und tritt dann zur Seite. Das ist ein bescheidener Anspruch, und deshalb ist das Programm so lange brauchbar geblieben.

Das Urteil

Wer je ein Wort in der Oberfläche eines Programms ändern, ein Symbol ersetzen oder sehen wollte, was eine ausführbare Datei mit sich herumträgt, findet hier den kürzesten Weg zwischen Frage und Antwort. Die Oberfläche ist schlicht, die Hilfe vollständig, und die Gemeinschaft darum beantwortet seit Jahren dieselben praktischen Fragen. Der Eintritt kostet eine einzige Gewohnheit: die Datei vorher kopieren. Alles andere an diesem Werkzeug ist nachsichtig.