Since the development of WinBoard by the "official" GNU-Savannah project team came to a halt with WinBoard 4.2.7b, WinBoard has seen an enormous "unofficial" development by individuals. Unfortunately, that development was not parallelled in xboard. On the contrary, it often took place in such a way that it destroyed the compatibility of the xboard front-end code with the improved back-end, as the developers were simply not aware that the changes they were making would break xboard.
In this release, 4.3.14, we make a modest beginning with closing the gap between xboard and WinBoard: we restored the compatibility, so that at least the latest back-end can be compiled without errors with the xboard fron-end files in a Unix/Linux environment. In addition, we did a rather minimal effort to make some new features in the back-end available in xboard, by providing the necessary command-line options to turn them on. This mainly applies to the adjudication features.
Since the new back-end has a variable board format, it was also necessary to change the display routines a lot. In particular, the Crazyhouse holdings, which are now displayed next to the board, required some modification of the code for entering moves from the user interface, to prevent dragging of pieces to the holdings. Also the entering of FRC castling by dragging a King on top of the Rook to castle with required a change in the mouse event handler. A consequence of these efforts is that most variants that were added can now be played in xboard as easily as in WinBoard. Especially since the non-orthodox pieces occurring in these variants are also provided as bitmaps and pixmaps.
The latest WinBoard also has a very large number of improvements in the user interface. This includes new auxilary windows, for engine output, evaluation graph and move history. But it also includes a 'face lift' of the display, allowing arbitrarily textured squares, so that the board can made to be look like wood or marble. In addition, it is possible to render pieces using symbols from a true-type Chess font. All these additions were due to Allessandro Scotti, and became known as WinBoard_x.
Unfortunately none of that works yet in this version of xboard. But do not despair: we intend to implement most of it in the next release.
In particular, we did not make any changes and additions to the menus. Everything that is new can only be controlled through the command-line options, if at all.
As many of the command-line options of WinBoard_x pertained to these front-end impovements, we have not added them in xboard yet. There is no good documentation of xboard 4.3.14; you will have to do with this file. The documentation of WinBoard 4.3.14 is only partially useful for xboard users, due to the many things that do not work yet. But making elaborate separate documentation at this stage would mainly be wasted effort, as eventually we aim to get everything that works in WinBoard also working in xboard. In this file we give a short overview of the new things that do work.
The most obvious change in the looks of xboard are due to the variant support. Many variants are added, all selectable as new argument for the existing -variant option. The new variants include exotic pieces such as Elephants and Generals in shatranj, but also expanded (non-square) board sizes as in xiangqi (Chinese Chess) or Capablanca Chess.
There is one caveat, though: the exotic pieces work only in board sizes "bulky" and "middling". (Sometimes "petite" also works.) In most other sizes they would show up as a Lance, or even as an ordinary King. This limitation is also still present in WinBoard (although there the missing pieces show up as empty squares). It is due to the fact that there are no bitmaps available for these pieces in every size. So if you want to play variants, even if only to see how they look, do not forget to include the arguments:
./xboard -size middling -variant xiangqi ...
This also holds in variant crazyhouse in local mode, despite the fact that crazyhouse was variant already supported in xboard 4.2.7. The reason is that the current back-end represents pieces that are really pomoted Pawns (and thus revert to Pawns on capture) as slightly different from their original counterparts. And again, the required bitmaps are only available in board sizes bulky, middling and petite. This problem does not occur in ICS play, by the way. There the ICS sends the board position before each move, containing ordinary pieces even for promoted Pawns. So there you have the opposite problem, of not being able to see which Queen is really a Pawn, and which is a Queen. In crazyhouse the contents of the holdings is displayed next to the board, and drop moves can be entered by dragging the pieces there onto the board.
Options that control the board format are -boardHeight N -boardWidth N -holdingsSize N, but you would almost never have to use them, as their default setting is to take the value that is default for the selected variant. The same holds for the option "-pieceToCharTable STRING", which you can use to determine by what letters the various pieces are referred to in FEN and SAN (and which pieces are allowed to appear there).
A variant that already sort-of existed was FRC ("-variant fischerandom"). The back-end now fully supports this variant, and Shredder-FEN can be used for transmitting castling rights (i.e. HAha notation). The Human interface allows FRC castlings to be performed by dragging the King on top of a Rook. An option "-defaultFrcPosition N" can be used (in local mode) to set the starting position used in FRC to a fixed one represented by the given number N (0-959), or cause a new shuffle on every new game (the default) when N<0. This option can be used to force shuffling even in variants that are normally not shuffled.
In engine-engine mode the back-end now reliably detects mate and recognize draws (as it is fully aware of e.p. capture and castling rights, as well as of the 50-move counter and repetitions). As a consequence, it is also able to correct the score of win or draw claims falsely made by an engine. The command-line options to switch on the various adjudications are
-checkMates true -testClaims true -materialDraws true -trivialDraws true -ruleMoves 50 -repeatsToDraw 3
These options cause xboard to recognize checkmates and stalemates even before engines send the RESULT claim, test RESULT claims for validity and forfeit cheating engines, recognize games with insuffcient mating material and adjudicate as draw some end-games that are almost impossible to lose (such as KRKR). The numeric options set the number of reversible moves, and number of repeats after which xboard adjudicates a draw. (FIDE rules would allow engines to play on, but in automated testing you would not want two stubborn engines to play on forever. So there are good reasons why you would want to give the engins more or less leeway here. But whatever you specify, draw claims by an engine will always be accepted after 50 moves or 3 repeats.)
In addition there is an "-adjudicateLossThreshold N" option, where you could set a score that would be cause to adjudicate the game as a win when both engines agree it is exceeded for a number of moves in a row. To make this option work, you would have to make sure that the engines do not print their evaluation scores with the opposite sign, as some engines do when they play black. To discipline such engines, the options "-firstScoreAbs true" and "-secondScoreAbs" are provided.
The WB protocol command "offer draw" gets the extended meaning of a draw claim in situtions where FIDE rules allow a draw to be claimed before or after the claiming engine moves. (As is already the case in ICS play.) Genuine draw offers are relayed to the opponent only after the engine gives its next move, but before this move is sent to the opponent.
The WinBoard_x option "-pgnExtendedInfo true" to get the depth and score for each move into the PGN file as a comment also works in xboard. In 4.3.14 it even adds the thinking time in there as well. Other options to control the PGN are "-pgnEventHeader STRING" and "-userName STRING". The name given in the latter will also be used in the title bar. For the score to appear in the PGN, it is essential that "Show Thinking" is switched on. In Human vs. engine games it is undesirable, however, that this output appears in te display. As a solution to this problem the option "-hideThinkingFromHuman true" is provided.
The options "-firstTimeOdds N" and "-secondTimeOdds N" reduce all time qota given to the mentioned engine (as specified with the options -st -mps -tc -inc) by a factor N (default N=1, so no time odds). The option "-timeOddsMode M" determines what happens if both engines have time odds. With M=1 the slowest engine gets nominal time, and the time of the fastest engine is scaled to preserve the ratio. With M=0 both engines play at the reduced time as specified by their time-odds factors.
Node-based time controls are also provided. There are not many engines that support those, though, as they require an extension of WB protocol in the form of the 'nps N' command. (Joker is an engine that fully supports it, but only available as WinBoard execuatable.) With the options "-firstNPS N" and "-secondNPS N" the respective engines can be instructed (through sending them the 'nps' command) to convert their node counts to time as if they were seaching at N nodes per second. This is mainly provided for playing ultra-fast games, where the system clock would be to inaccurate, or for playing on machines that are heavily loaded.
The time between games in match mode can now also be controlled, through the option "-matchPause T", where T is given in msec.
The option "-engineDebugOutput M" can be used to keep de debug file WinBoard makes clean from garbage the engines might send to xboard. If M=0, any protocol-violating output of the engine is kept out of the debug file. This is useful when there are other programs using the debug, such as TLCS. When M=1, everyting appears in the debug file exactly as the engine gives it. This is the old mode, good for debugging the engines. When M=2, the protocol-violating lines are "commented out" by prefixing them with a '#' character, as the engine should really have done himself. This allows applications using the debug to avoid being confused by spurious engine output, (once they learn to use this information), while not interfering with debugging of such engines.
An option that is useful when playing on ICS tournaments like CCT, is "-autoKibitz". This option takes care of the kibitzing that is required in such tournaments, by automatically sending the last line of Thinking Output of the engine to the ICS after the engine moves.
The command-lines for engine start-up, given as arguments to the "-fcp" and "-scp" options, can now also contain xboard options amongst the engine options. Any engine option appearing after an option WBopt is withheld from the engine, and interpreted by xboard in stead. If it contains a "%s", xboard replaces this by "first" or "second" depending on the engine it was snatched from. This feature is useful for creating options that follow a specific engine, when using a tournament manager to invoke xboard. Such options overrule even what is on the xboard command line.