WinBoard Interface Implementation

The following description is meant for computer programmers, who are interested in how and what of the WinBoard protocol is implemented in RDChess.

If you want to know how to install RDChess into Winboard please go to the User Manual Part 3 Installation

The WinBoard Communication protocol is the most common link for playing chess games between chess engines. Recently even the commercial chess programs support this interface. The best known program is WinBoard by Tim Mann.
A newer interface is the UCI (Universal Chess Interface) protocol, which has more functions than WinBoard. UCI is supported e.g. by Arena.

An older interface is the "Auto232" interface over the Serial Input/Output OS routines, which is becoming obsolete as far as I can say it. RDChess supports this interface, but the implemtation is proprietary, allowing only to connect 2 RDChess processes running on the same or different computers connected with a serial (or parallel) interface cable. A test connection with Fritz 6 went unsynchronly after a certain number of protocol command exchanges.

Implementation of the WinBoard interface in RDChess:

RDChess is a Delphi program written in Object Pascal. The main program is a single process (thread) and uses heavily the Borland Visual Component Library (VCL).
Winboard.exe (or an equivilant program) starts RDChess and creates 2 pipes for standard input and standard output. My interface code is based on an example by Tony Werten

RDChess writes to the output pipe with an output handle (created by gHandleout:=getstdhandle(std_output_handle) ) by calling _lwrite(gHandleout,PCHAR (string),length).
RDChess reads from the standard input in an own thread WBReadThread, derived from the VCL TThread class.
In the thread function ( procedure TWBReadThread.Execute ) the commands received from WinBoard are read and analysed. It is critical and Borland does not recommend to use VCL functions in this extra thread, because many are not thread safe. So I use at some points the Delphi supplied method Synchronize. Larger work is postponed to the main thread by posting messages to the RDChess main thread with PostMessage(MainForm.Handle, ...) .
A few calls to VCL functions and global variables are still used directly in the thread execute method, but I also use frequent calls to Application.ProcessMessage, which should decrease the risk of a collision.

WBReadThread is set to a lower priority than the main thread in order that the main thread ends his work on a received command faster before it takes actions for a newer command. (e.g. all the work at receiving a "result" winboard command (for instance saving the chess game) must be done before a received "new" winboard command sets all data to a new game). I had problems with synchronizing the both tasks at the beginning of using the thread (and even program crashes!) until RDChess V3.07, but in V3.08 it seems there are no problems.

RDChess "uses" currently (version V3.12) the following Winboard commands

Receiving (WinBoard-> RDChess):

xboard, new, random, protversion 2
hard, easy, post, nopost, computer, name, ics hostname
rating (in ICS mode)
level, st (all 3 styles conventional, ICS-style, nr of seconds per move)
sd (set maximum search depth)
time, otim (used optionally for synchronizing of RDChess internal timining routines with WinBoard timing)
force, go, white, black
hint, "?" (move now)
moves in standard notation (not SAN format !)
remove
setboard FEN (for setup of positions and at loading games)

analyze, undo , "." , bk (bk only partially implemented)
result
draw
quit

Sending (RDChess -> WinBoard):

answers to protversion 2:
name=1      // request the name from the opponent!!!
time=1       // send time and otim cmds
  setboard=1 // FEN-cmd instead of edit-cmd
ics=1        // inform about ICS data
  analyze=1    // implemented
move xxxx (computermove calculated by RDChess)
0-1 (or 1-0, 1/2-1/2) {xxxxxx} xxxxxx = result/ resigns

"offer draw" (when RDChess is behind 12 pawn units and at certain types of endgames (RK-RK; QK-QK) and the opponent is not in time troubles)

Error (xxxxxxxxxxx) : yyyyy // error messages from RDChess to the opponent

Thinking output ( ply score time nodes pv) (when state is "post command received")

Status update (stat01: time nodes ply mvleft mvtot mvname) in response to a received "." cmd. mvleft and mvtot are not supported and set to a default value 1.

RDChess understands only the newer (protversion 2) position setup command "setboard" and not the older "edit" commands for seting up positions. This means that currently chess games may be loaded from .pgn files with the program Winboard.exe only and not with the program Arena.exe.

2002-12-06 Rudolf Posch