Nicht schon wieder: Runtime Error 200

Oft liegt jedoch vom Programm nur der ausführbare Binärcode (EXE) vor. Hier half damals ein einfacher Patch weiter, der in den EXE-Dateien ein Byte änderte und so den schuldigen Teilerwert von 55 auf 110 verdoppelte, was den Überlauf erst mal verhinderte - wenn auch mit dem Nebeneffekt, dass gleichzeitig die Delay-Dauer halbiert wird. Statt 1000 ms wartete dann ein Delay (1000) nur noch 500 ms.

Doch mit Pentium II oder Athlon ab 550 MHz und schneller reicht nun der Teilerwert 110 nicht mehr aus: das Runtime-Error-Spielchen wiederholt sich aufs Neue. Man kann nun höhere Werte für den Teiler einpatchen. Mit maximal 255 reichts etwa bis zu den Gigahertz-Prozessoren. Da der Teiler 16-bittig ist, kann man schließlich auch das nächste, höherwertig Byte patchen und hat dann Reserve bis etwa 256 GHz. Dummerweise wird dadurch aber die Delay-Dauer immer kürzer und kürzer, was mitunter neue Probleme aufwirft.

c't hat daher einen anderen, etwas aufwändigeren Patch entwickelt, der die Delay-Funktion nicht beeinflusst. Er ist derzeit zwar nur bis etwa 3 GHz Pentium II/III tauglich, aber das dürfte erst mal reichen. Das Programm BPPatch2.exe (auf www.heise.de/ct/ftp/ctsi.shtml) vereinfacht auch die Bedienung. Es erkennt, ob es sich bei einem vorliegenden EXE-Programm um Borland-Pascal 7/7.01, TP 6, TP5.x oder TP4 handelt, ob es die CRT-Unit benutzt, ob diese bereits gepatcht oder mit der ‘überlaufsicheren’ c't-CRT-Unit kompiliert wurde. Im Trefferfall fragt es nach, ob es das Programm nach der neuen oder der alten Methode oder gar nicht patchen soll.

BPPatch2 unterstützt auch Wildcards (nur 8.3-Dateinamen), sodass man mit BPPatch2 *.EXE schnell ein ganzes Verzeichnis auf alte Borland-Programme überprüfen kann. Wie der DIR-Befehl kennt es Parameter wie /P (auf Taste warten) oder /D (rekursiv durch Unterverzeichnisse). (as)