[Allegro] srch32.exe vom 3.2.2020 verhält sich anders gegenüber der srch32.exe vom 18.11.2016

[Bernhard Eversberg]

> Gesendet: Freitag, 28. Februar 2020 um 11:29 Uhr
> Von: "Klaus Lehmann" <lehmann_klaus at t-online.de>
> 
> > Die aufgetretenen Diskrepanzen bei srch.exe wurzelten in sehr alten
> > C-Problemen mit dem Datentyp "char"
> > bzw. "unsigned char".
> 
> warum trat es jetzt gerade auf?

Eine haargenaue Aufklärung der Sache wäre unverhältnismäßig aufwendig
und darüber hinaus unnötig, weil ja nun alle "char" durch "unsigned char"
ersetzt sind und weil nie und nirgends irgendwas explizit auf "signed char"
angewiesen ist.
> [warum ich da keine testumgebung zur verfügung gestellt habe? das
> skript ist ca 1,2MB groß. es wimmelt nur so von expliciten
> suchbefehlen, die teilweise mit srch32.exe oder mit den suchskripten
> von T.B. und Th.F. durchgeführt werden...]
> 
Der srch.job von Berger wird übrigen in Kürze endgültig in die Oboleszenz
entlassen werden, denn ein neuer, universeller .job ist in Arbeit, der diese
Aufgabe ganz nebenbei mit erledigen kann und sehr erheblich schneller ist.
Sogar auf srch.exe selber könnte man dann verzichten! Das Ding ist so gut
wie fertig, es laufen nur noch Härtetests bei anspruchsvollen Anwendern.
Und die Kommentierung befindet sich noch in gründlicher Überarbeitung.
Mehr dann in der Vb.319

B.E.