Computer Chess Club Archives




Subject: UCI versus Winboard

Author: Bas Hamstra

Date: 02:03:29 08/21/02

I forgot I posted a message some time ago about this topic. Here is a late

>>UCI is superior IMO (Not surprising, since they were able to learn from

>I completely disagree.  Just because they "looked at winboard" doesn't mean
>they "learned from winboard".

>>- It's very straightforward and only processes commands in force mode
>>- Easier to implement
>>- It publishes it's own options which are then supported by the gui, this is
>>very very nice
>>- Much easier to install new engines, no dozens of ini files necessary
>>- You can change engine settings while the engine is loaded
>>- The situation with pondering in Winboard is asking for trouble. While
>>pondering (=busy searching) the engine must be able to process commands which
>> is messy. Each engine comes up with it's own messy solution for this.

>And you think the UCI version is _better_???  The GUI tells the engine what
>it can do, and when it can do it?  The engine can't decide how / when to
>ponder? What to ponder?  If it should ponder at all? The GUI is _supposed_ to
>be the interface between the human and the chess engine.  It is not supposed
>to get in the way of either.  UCI does get in the way, and it requires a
>re-design of how the basic engine operates. Why would I want to do that when
>the shredder GUI is _not_ free?  When the Shredder GUI does _not_ support
>unix?  When winboard does everything that UCI does (and then some in protocol
>version 2 and more in version 3 when it is finalized). We don't need _another_
>protocol.  Particularly one developed by a commercial entity.  We _already_
>had the chessbase protocol.  We need _fewer_ not _more_ to make it easier to
>standardize everyone and eventually hold tournaments where humans are not
>allowed to intervene whatsoever.  This is coming at ICCA events before long.

Ok, some comments:

- First of all UCI is not the same as "Shredder gui" but merely a protocol
- There actually IS a free UCI gui, called Arena
- From a software design point of view I don't understand your suspicion to the
"gui taking control". I say handle some basic stuff right once, so 50 engines
don't have to invent the wheel. It leads to more stability IMO. Actually the
"control" is no big deal at all. If the engine has provided a pondermove, the
gui WILL instruct it to ponder that move. _Always_. What's the problem with
- You say that Crafty would need a re-design for UCI, actually it's no big deal
at all, I bet you can write your UCI stuff a lot faster than you did Winboard
and no re-design of the engine itsself is necessary. My UCI code is less than
half of Winboard's, yet a lot cleaner
- Nobody even had THOUGHT about Winboard version 2/3. Until UCI entered the
scene... Suddenly Winboard needed new versions...
- Tim Mann is not interested in supporting WB anymore, he says. Who is going to
do/coordinate WB 2/3?

Tim Mann could be freed of his heavy burden, by implementing UCI in Winboard and
calling it Winboard 4. Everybody happy, you have your free Unix code, the users
have ease of use and stability, the engine programmers get great gui's with a
lot of extra options, the gui builders finally have a robust protocol.

>- UCI offers more information about the search

> How?  The engine can tell the operator _anything_ it wants.  You can't provide
> more information than that.

Yes, but I want it "live" on-screen in a windows environment, not in a

>>I would not be surprised if > 95% of the programmers who actually implemented
>>both WB and UCI, preferred the UCI protocol.

>I would...

You say so now. But my UCI code is 400 lines, clean, and rock-solid. That is
simply impossible with Winboard. That says something about the protocols.

>>Maybe Winboard can support UCI as well? This would give the WB protocol the
>>chance to die slowly (but peaceful) because eventually everyone will chose for

>Don't hold your breath.  The "concepts" used in winboard have been around
>for 30 years.  They _work_.  Giving the GUI total control over the engine is
>_not_ the way I want to see my engine work.  I don't want another person's GUI
>to have control over _my_ engine.  For obvious reasons.  We've already seen
>this once with the broken winboard adapter Chessbase first released...

You make this sound so dramatic "gui takes total control". It just takes a tiny
bit more control than Winboard. It just tells the engine when to ponder. In
practice there is no difference. The _engine_ provides the pondermove, the gui
_will_ tell it to ponder ASAP, and the _engine_ decides how long it will think.

Best regards,

This page took 0.1 seconds to execute

Last modified: Thu, 15 Apr 21 08:11:13 -0700

Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.