Zudem ist Xboard ziemlich tot, und das aus gutem Grund. Glaub mir, ich hab beides in der Engine implementiert, und Xboard fraß dermaßen Aufwand weg, daß der einfachste Bugfix war, es nicht mehr zu unterstützen.

Du hast zig verschiedene Wege, dasselbe zu erreichen. Das läßt das Testing explodieren. Troubleshooting wird viel aufwendiger, weil man nicht weiß, welcher Codepfad genommen wurde, und reale Nutzer schicken keine Logfiles. Ich bin ja dankbar, daß ich überhaupt weitere Nutzer als Tester habe.

Dann muß man noch grübeln, welche der diversen Möglichkeiten die GUI genommen haben könnte, und ob das Problem dann bei der GUI oder der Engine liegt. Das ganze auch noch mit zustandsbehaftetem Verhalten, und fertig ist der Wartungs-Alptraum. Deswegen ist UCI heute der Standard.

Die propagierten Vorteile von Xboard, auf die besonders Bob Hyatt pocht, sind in der Realität so minimal, daß Crafty sich nur mit aller Mühe unter den Top 30 hält, gegen die ganzen UCI-Engines. Selbst die Erkennung, ob ein neues go-Kommando eine bestehende Partie fortsetzt oder etwas komplett anderes ist, ist auf Engine-Seite mit UCI kein nennenswertes Problem. Nützlich für die Hashtabellen und Treffer in der Hauptvariante.

Für Hobby-Engines aus dem unteren Bereich gibt es zwei Gründe, wieso Winboard noch verbreitet ist:

- man muß das "?"-Kommando in der Suche nicht erkennen, so daß man eine Engine ohne jedes Threading machen kann. Die Top-Engines haben aber alle Multithreading, so daß noch ein Thread für die Eingabe auch schon egal ist.

- die einzelnen Kommandos z.B. für die Zeiten kommen separat, so daß man die Werte trivial mit sscanf auswerten kann. Mit UCI braucht man einen Tokeniser, den zu schreiben und zu testen aber auch nur zwei Tage dauert.

Auf GUI-Seite ist es nicht aufwendiger, weil die GUI die komplette Historie des Spiels sowieso verwalten muß, also Züge und auch Zeiten, weil sonst die Undo-Funktion nicht geht. Die Zugliste dann bei jedem Zug mit auszugeben, ist trivial. Ebenso die Remis-Erkennung.