Nicht schon wieder: Runtime Error 200

Mit dieser Meldung verweigern DOS-Programme auf schnelleren PC-Systemen ihren Dienst, wenn sie mit Borland-Pascal kompiliert worden sind. Schuld ist eine schlampige Programmierung der Initialisierung für die Delay-Routine in der Unit CRT, die bei schnellen Prozessoren überläuft und den Runtime-Fehler provoziert.

In Pocket speichern vorlesen Druckansicht
Lesezeit: 3 Min.
Von
  • Andreas Stiller

Mit dieser Meldung verweigern DOS-Programme auf schnelleren PC-Systemen ihren Dienst, wenn sie mit Borland-Pascal kompiliert worden sind. Schuld ist eine schlampige Programmierung der Initialisierung für die Delay-Routine in der Unit CRT, die bei schnellen Prozessoren überläuft und den Runtime-Fehler provoziert. Der Effekt ist nicht neu, er trat schon bei Pentium-II-Systemen ab etwa 266 MHz auf. c't hatte schon vor drei Jahren unter ‘Borlands Zeitbombe’ (c't 7/97, Seite 232) auf diesen Fehler bei der Division hingewiesen und für Programmierer eine verbesserte CRT-Routine vorgestellt, die 32-bittig dividiert und die erst bei Pentium-II-Systemen ab etwa 256 GHz überläuft. Um sie nutzen zu können, braucht man aber den Sourcecode der betreffenden Programme und den Borland-Pascal-Compiler.

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)