Ich denke man kann es einfach zusammenfassen:

UCI ist das Protokoll, das die GUI-Entwickler bevorzugen, da es die Kontrolle der GUI gibt. WB ist das Protokoll, das die Engine-Entwickler bevorzugen, da die Engine für das Spielen von Schachpartien programmiert ist, und nicht für das berechnen von einzelnen Stellungen.

Genausowenig wie der Engineprogrammierer vom GUI Entwickler verlangen kann, dass die GUI WB unterstützt kann der GUI Entwickler verlangen, dass eine Engine UCI unterstützt. Klar kann man fragen, aber wenn jemand sich für nur eine Variante entscheidet sollte das respektiert werden.

Die Anwender bevorzugen auch UCI, was natürlich nicht direkt am Protokoll liegt, sondern daran, wie die jeweiligen Ökosysteme sich entwickelt haben. WB-Engines haben immer irgendwelche Probleme (alleine schon, eine Analyse zu unterbrechen), und der ganze Zirkus mit den Commandline-Optionen war auch mies, zumal die für jede Engine wieder anders waren. Das UCI-Ökosystem bot Engines, die einfach funktionierten.

Zudem kann die GUI natürlich auch WB-Engines so ansprechen, wie sie das bei UCI tut: mit Übertragung einer Startposition nebst Zugliste. Dadurch liegt z.B. das Eröffnungsbuch bei der GUI, auch mit WB.

Nein. WB ist heute kaum noch von Bedeutung und eigentlich Legacy. Aus Entwicklersicht hat WB nur einen "Vorteil": man muß während der Berechnung keinerlei Eingaben verarbeiten. Gut, man kann dadurch auch keine Analyse bis Nutzerabbruch machen, wenn man das nicht einbaut.

Die Rangfolge der Engines legt nicht nahe, daß UCI-Engines da einen Nachteil hätten. Bei den Top-Engines ist keine einzige mit WB. Zudem, wie ich schon schrieb, kann man auch UCI so implementieren, daß man nicht nur einzelne Stellungen abarbeitet, sondern eine Spielfortsetzung erkennt, etwa um HV-Treffer auszuwerten.

Für den Anwender macht WInboard 2 oder UCI keinen Unterschied.

Führt aber zu noch größeren Problemen. Ich erinnere an die Zeit wo Chessbase genau das mit dem WB-Adapter gemacht hat. DIe Engines hatten Probleme durch die iniziierung der Hashtabellen nach jedem Zug, und durch nicht definierte Zeitkontrollen mit aufgezwungenem externen Buch.


Die Diskussion drehte sich ja um die alten Programme und um die Probleme beim nachträglichen implementieren von UCI. Wer eine neue UCI-Engine schreibt hat diese Probleme logischerweise nicht.

WB2 kam als Reaktion auf UCI, und viele WB-Engines haben auch heute noch irgendwelche CLI-Optionen beim Aufruf der Exe. Plus daß es für den Anwender sehr wohl einen Unterschied macht, ob z.B. Analyse geht oder nicht, abhängig davon, ob der Programmierer die Eingabe während der Suche abfragt oder nicht - ist ja optional im Protokoll. Was wieder bei jeder WB-Engine individuell ist.

Mit WB-Engines hat man praktisch immer Probleme, weil das Protokoll zu komplex ist und jeder was anderes implementiert. Das ist auch ein Grund, wieso ich WB-Engines gar nicht mehr in meinem Testparcours habe.

NG-Play, von dem ich die CT800-Engine geforkt habe, ist ja WB - und ich habe das auf UCI umgeschrieben, weil ich dann den Aufwand nur einmal hatte und nicht als Dauerbaustelle. D.h. ich habe genau sowas schon gemacht.