winboard protocol

[wing]

Where can I find the official & latest winboard protocol? I guess it's version 4.5.2 now?
What does this phrase mean: "WinBoard requires Win32 engines" - does the mean it doesn't work with x64 engines?

[H.G.Muller]

No, the protocol document is very old, and obsolete in places. This phrase means it cannot handle 16-bit DOS engines. I once started to write a new one, but never found the time to finish it.

The version of the specs included with 4.5.2 should be more or less complete, though. I did not add any new commands after that in the normal version. (At least, not documented commands.) Only the Alien version (supporting Checkers and such) has a lot of new protocol, but it is of no relevance for Chess.

Note I posted a model protocol driver in the 'Programming lessons' section of this forum. To a programmer that might be more helpful for a quick understanding of the protocol than the official specs.

[wing]

OK and thanks a lot for your model protocol driver - I am using it.
BTW I added some code lines to write to a file, so I can trace the order of the commands from winboard,
this did not seem to work at first, but then I discovered that this file was placed in the winboard folder.
(looks like the engine is assimilated by winboard I'll have to check the engine installation parameters.

[H.G.Muller]

This is strange. Winoard is supposed to change to the engine folder (given in the /fd option) before creating the engine process, so that the engine process will inherit that as 'current directory'.

The notion of 'current directory' seems a bit fuzzy on Windows, though, like it is a global variable shared by all processes. We had problems with the save file when we did not extend it to a full path name first; it was then made in the folder the user last clicked, before pressing save. I can imagine that when you create the file not immediately at startup, but only later, engine-created files could suffer from the same problem.

BTW, a convenient way to have the engine report is to just let it print messages prefixed with '#' (if it has set feature debug=1), so they will appear in the winboard.debug file. That also makes it easier to see the relative timing of events, and the engine input is listed there anyway.