UCCI2WB and UCI2WB are currently included in the standard binary install for WinBoard, downloadable from WinBoard forum.
Source code of UCI2WB can be found in my on-line git repository.
UCCI2WB and QH2WB sources are included in one download package with WinBoard executables.
WinBoard of course supports its own native protocol, but the number of engines that are written for this protocol is quite limited. (HoiXiangqi, ChessV, MaxQi, TJxiangqi, HaQiKi D.) Many more engines exist that use other standard protocols, and these can be run under WinBoard with the aid of adapters. Currently adapters are available for:
There exist a reasonable number of free Xiangqi engines using the so-called UCCI protocol. Specs of this protocol are unfortunately available only in Chinese. But there existed an adapter UCCI2QH, which would allow UCCI engines to run as Qianhong plugins. This adapter was written by Huang Chen (also known as Morning Yellow, the author of the strong UCCI engine Elephant Eye), and released as open source under the GPL.
Now Qianhong protocol is very much like an extremely simplifed version of WB protocol, and is described concisely in English. So it was quite easy to convert UCCI2QH to an adapter for running under WinBoard, without knowing any of the details of UCCI. I did this, and the result is UCCI2WB.
Under Windows the engines are usually installed with their executable and all data files (opening books, settings) in the same folder, it is usually necessary to set the current directory to this folder with the WinBoard -fd or -sd options, or the engine could not find its files. To connect to the engine, UCCI2WB would have to know where to find it. WinBoard will think that UCCI2WB is the engine, and would only have to be told where to find and how to start that.
Newer versions of UCCI2WB can be used in three ways. The simplest way is to pass the engine command to it on the command line for starting it, like
UCCI2WB -noini ..\EleEye\ELEEYE.exe
Fortunately UCCI engines usually don't need arguments themselves, and have names that do not contain spaces, so there is no need to put quotes around the engine command passed to UCCI2WB. If there was, you would have to use double quotes, and because the UCCI2WB command obviously does need spaces to separate "-noini" from the others, you would have to use single quotes when telling the name to WinBoard:
winboard -fcp 'UCCI2WB -noini "..\Elephant Eye\ELEEYE.exe"'
What appears behind -fcp is always the same as what you would have to type in the combobox of the WinBoard Startup Dialog, or in the winboard.ini file (possibly through the Engine->Install menu dialog of WinBoard 4.5) to define the contents of this combobox. Note that an -fd argument is not really needed if UCCI2WB.exe is in the WinBoard folder. (Which it is, in the standard install.) The Engine folder is extracted by UCCI2WB from the engine path name, and does not have to be specified separately.
With this way of using UCCI2WB the engine name will be derived from the UCCI "id" given by the engine, and options must be set through the WinBoard "Engine #N Settings" dialog. This only works for fully compliant UCCI engines, which specify their options at startup, as the WinBoard Engine Settings dialog will only show options the engine specifies, and has no way to know about "secret" options.To work around problems of non-compliancy and "secret" options, UCCI2WB can be run with an INI file. In the latter you can specify "setoption" commands for such secret options, if you know they exist (e.g. from the engine docs). UCCI2WB will always look for an INI file if you don't have the "-noini" in its startup command. In that case an argument will be taken to specify the INI file, rather than the engine executable. The default name for the INI file will be UCCI2QH.INI in the same folder as UCCI2WB.exe. As you would need a different INI file for each UCCI engine, you cannot put them all in the WinBoard folder if you use this default name, but you could place them in the engine folder, where you would have to place a copy of UCCI2WB.exe then too. The engine can then be started with WinBoard through the command
winboard -fcp UCCI2WB -fd "..\EleEye"
The UCCI2QH.INI in the engine folder (given in the -fd or -sd WinBoard option) then contains information on how the engine is called, where the executable can be found, what commands it needs to be sent to adjust its option settings, etc. Note the QH in the default name of the INI file, I set it up such that UCCI2QH and UCCI2WB can use the same INI file, although most of the information in it is only used by UCCI2QH. The only lines from this file used by UCCI2WB are:
[UCCI2QH] Name=Engine Name File=filename.exe Option=any line to be sent to the UCCI engine at startup
The engine name can be any text string; UCCI2WB uses it in the 'myname' feature of WB protocol, to let WinBoard know which engine is running, as 'Engine Name (UCCI2WB)'. The 'File=' line should contain the name of the UCCI-engine executable file (as pathname if it is not in the current directory specified in the WinBoard -fd or -sd option). Everything after 'Option=' is handed as written to the UCCI engine at startup.There can be multiple 'Option=' lines. Typically you would use them to set UCCI options, which seems to go like 'setoption NAME VALUE', e.g. 'setoption usemillisec true'.
This latter example is actually a special case: UCCI2WB will recognize it too, and then will send the time to the UCCI engine in milliseconds, rather than the seconds it normally uses. This was needed as a work-around for some engines, which tell at startup that they use milliseconds, but in fact interpret what UCCI2WB sends them as seconds, or vice versa. Lying about their option settings, or reporting options that in fact cannot be set, is quite common amongst UCCI engines. If you want to know which options a UCCI engine supports, just start the engine executable by double-clicking it. This should pop up a console window, and when you type 'ucci' there, the engine will print a list of options that it might implement.
Newer versions of UCCI2WB allow you to specify the INI file as an argument to UCCI2WB, like "UCCI2WB ../EleEye/ElephantEye.ini". This makes it possible to use INI files with different names for different engines, and feed those to a single UCCI2WB.exe in the WinBoard folder, rather than having to place copies of UCCI2WB.exe with each UCCI2QH.INI file in the engine folder. The standard way to install WinBoard puts all such INI files in a sub-folder QH of the WinBoard folder. WinBoard should then be called as:
winboard -fcp "UCCI2WB QH\EleEye.ini"
Qianhong is a GUI that uses a very simple protocol, which translates to WB protocol almost 1-on-1. The major difference is that is has no notion of the engine playing a particular color; you have to send an explicit command to set the engine thinking for each move. In such a protocol the concept of 'force mode' is not needed. So the adapter interprets the WB 'force' and 'go' commands to decide if it should send a command to the QH plugin to produce a move, after that plugin has received one.
A more annoying difference between WB and QH protocol is that the latter has no way to set the engine to think a given (average) amount of time. Qianhong knows the concept of 'levels', but they are simple numbers, and it is not define what these numbers mean. So QH plugins use whatever amount of time they feel is appropriate for the level they run at. And this amount might vary during te game, .g. because the level corresponds to a fixed search depth.
I wrote a very simple adapter, QH2WB, to play Qianhong plugins under WinBoard. Unfortunately is uses Unix-type system calls, and can therefore only run under Cygwin, or when the cygwin1.dll is present in its folder. (It uses 'fork()' to split off a separate process for the engine, and then forks itself again into two processes, for communication from and to the engine, respectively.) So you will see two QH2WB.exe in the process list of the task manager for every QH plugin you are running through QH2WB.
The QH2WB adapter should be invoked like it is the WB engine, but its startup command should contain two extra items: the first command-line option of QH2WB should be a number that specifies the Qianhong level at which the plugin should run. (Beware: not all QH plugings start at level 1. Run the plugin under Qianhong first, to figure out which levels it knows, for QH plugins often do not complain on faulty input, but simply exit.) All following options on the QH2WB command line are used as command line to startup the plugin. This means that typically two arguments follow the level specification: the name of the plugin executable file, and '-plugin'. So on the WinBoard command line it might look like:
winboard -variant xiangqi -fcp "QH2WB.exe 7 C:\XQ\engines\QHplugins\ki11egg.exe -plugin"
UCI2WB is a dumb adapter to translate WB protocol to various UCI dialects. "Dumb" in this context means it is not aware of the game state or rules of the game, which has the advantage it can be used for many different variants. UCI2WB therefore can be used for Chess as well as Xiangqi and Shogi engines. Several commercial engnes, e.g. Cyclone and gagaChess, come as UCI engines. UCI2WB is available in source code, and can be compiled both under Windows and Linux (to work with XBoard).
UCI2WB needs to know two things: the name of the engine executable, and in which folder to find it. The latter only if it is not in the same folder as UCI2WB. Both of these are handed to UCI2WB as arguments in its startup command, which thus is "UCI2WB ENGINE.exe ENGINEFOLDER". The way to start WinBoard with a UCI engine thus is:
winboard -fcp "UCI2WB Cyclone2009.exe ..\Cyclone"
when you would have Cyclone 2009 installed in a sister folder 'Cyclone' of the WinBoard folder. Again, no -fd argument is needed in the standard install, because UCI2WB.exe is in the WinBoard folder there. When running Xiangqi games, UCI2WB will use the so-called "Cyclone dialect" of UCI.