WinBoard Protocol extensions

[H.G.Muller]

I prepared an adapted version of the WinBoard protocol definition.

This version of the document contains some clarification on points where the original protocol definition was vague or absent, describing the exact meaning that the implementation in WinBoard 4.3.xx has implemented.

The new paragraphs are highlighted in green. Many are just trivial extensions of the old protocol, like defining the names of some new variants. The only essentially new additions to the protocol are the engine debug output, and the node-count based time control.

I also already put in some advance information that might be important for implementing multi-session time controls in the future.

Please let me know what you think about this.

[mathmoi]

Hi,

does theses changed have been implemented in xboard as well?

MP

[H.G.Muller]

They will be soon.

[Vegan]

One extension that seems long overdue to me is to be able to specify the EGTB path relieving the engine from using an INI file or a command line option. Also to specify the tbcache size to be allocated.

Adding tbhits to the output would be able to validate the tablebases.

Another extension, to specify the number of search threads, allow one for the UI (not to be considered when a dual core uses 2 search threads, or 3 with a UI loop) the search threads can be separated easily enough.

Then an engine can be run without any arguments or support files, use the common book etc and use tablebases/cores. Simple is best, and makes it simpler for engine developers to focus on the engine.

[H.G.Muller]

I am not sure if that is useful. Different engines might use different tablebase formats, and so each need their own tablebase directory. The same holds for books. From the viewpoint of standardization, it does not matter much if you standardize it as a command in WB protocol, or if you simply standardize the pathname of the default tablebase and book directory itself (e.g. /nalimov and /book). Having a common book for all engines might seem convenient, but actually it is very inflexible. Even if you coud change the standard book from the user interface, it would change for all engines at the same time. So you coud never play engines with different books against each other through this mechanism. I think there is a lot to be said for specifying the book in an engine specific way, such as the command line with which you install the engine in the tournament manager, or in a private .ini file. In fct, the former possibility seems the most convenient, as you could even run two instances of the same engine against each other, without having to duplicate all the engine files.

The EGTB size is no business of the user, it is upto the engine programmer to decide which fraction of the evailable memory he thinks is best used as EGTB in his engine. It might be useful to define a command to limit the total memory usage, though, e.g.

mem 128

that will instruct an engine to clear all its tables, and re-size them such that its memory footprint will not exceed 128MB.

Engines have already the possibility to print tablebase hits in their thinking output, in the PV field. This field is free format, WinBoard does not have to interpret this info, and the engine can put anythin it likes in it. Some engines even print score-dependent smilies there...

To specify the number of cores the engine can use is an interesting idea. This is similar in nature to switching pondering on and off. so we could add a command

cores N

to limit the number of cores the engine uses to N.

A more fundamental desgn choice we will have to decide on which 'communication channel' between WinBoard and engine we want to use for what purpose. The standard I/O pipe, through which the WB protocol commands are sent, is only one of the means the GUI can control the engine. The other opportunity is the command-line options it passes to the engine diring the start-up of the latter. This could also be standardized and automated.

WB protocol seems suitable for things that are highly dynamic, and that you want to change during the same run of the engine without re-starting it.

[Roger Brown]

I am nothing more than an enthusiastic Winboard user but it seems that in spirit I agree with H.G.

I think that the author should be free to implement whichever protocol he/she wants to.

UCI already handles everything else for the engine including egtb usage as in the CB interface so why mimic it in Winboard?

Surely there are some authors who want to have their engines handle matters of hash size, egtb use vs direct endgame knowledge, pawn table size, resigning etc. independently of the gui.

Seems to me that the design universe is large enough for all types here.

My one cent....

Later.

[Vegan]

The reason I suggest using as much as possible in the protocol, lets look at how many versions of that engine there are. How about a tournament running them against each other?

Nalimov tablebases are the most widely used, so that's why I focus on them. If an engine does not like Nalimov, use something else, or ignore it.

As for memory usage, cores, once again, these are dynamic and can be done through the stdio channel.

The punch line, less command line the better, less .init file, the better. Ideally the engine could be naked, joeblochess.exe and no other file. The protocol can take care of the opening book, the tablebases if supported, cores if supported, and so on.....

By enhancing the winboard protocol this way, once an open source engine using the protocol would be a good template for a clone or 20.

[H.G.Muller]

The protocol extension that I consider most urgent, is that of implementng secondary time controls. I have already upgraded WinBoard to understand time controls of the form

40/60+20/15+5+1

meaning 40 moves in the first hour, then in the second session 20 moves in 15 min, then 5 min + 1 sec/move for the rest of the game. I.e. there can be an arbitrary number of sessions, each consisting of moves/time, until there is one consisting of a time only (or 0/time), indicating the rest of the game. That will then of course always be the last session, and it can only be followed by an increment (seconds/move). If the time-control specification does not end with an incremental or sudden-death session, the last session is repeated as often as needed. I.e.

40/60+20/15

means the same as

40/60+20/15+20/15+20/15+20/15+20/15+...

All this already works in WinBoard, as far as updating the clock is concerned. But the question is now, "how could we send it to the engine?".

The WB protocol as we know it only defines a

level MPS TC INC

command, that can be used to communicate TCs of the form 40/5 or 5+1. To stand maximum chance that what we implement will work with existing engines, I am considering to simply send a level command on each session. The WB protocol as we know it doesn't realy say that you cannot do that (send level commands during the game). It is just that WinBoard was not in the habit of doing it. Until now, that is.

So suppose the meaning of a level command is defined as "at this very moment, you have TC minutes left on your clock, and if you do not do MPS moves before that time is up, you forfeit". This is of course exactly what it means at the beginning of the game. Except that then it also suggests that, once you hve done the specified numbe of moves, you will get an equal amount of tme added to your clock for the next MPS moves.

This latter meaning should be dropped, at least for level commands received during the game. If engines somehow want to predict how much time will be added to their clock after the MPS moves have been done, they can only do it if the sesson they are currently in is a repetitive one (i.e. not a multiple-session control, or the last session of a multiple TC, which happens to be non-incremental). And to do it, they should realize that the TC specified by the level command they got at the beginning of that session was the time added for the new session, plus the time left on the clock from the previous session.

To make it easier for the engine to make this calculation, WinbBoard could send an extra 'time' command just before any later level command, to specify how much time was left just before the new time for the next session is added. So receiving

time 6000
level 40 6 0
time 36000
otim ...

would tell the engine that it completed the previous TC session with 1 min left on the clock, and that it now has 6 min for the next 40 moves. So the engine can draw the conclusion that it just received 5 min for 40 moves, and that it might get another 5 min for the next 40 moves after that.

Now the question is if this is all worth it, as, in a multi-session TC, the engine might just as well get a different amount of time for another number of moves in the next session, or might even have to play incremental or sudden-death. What really would help the engine is if it would be told what to expect in all future time controls.

Now all this is pretty immaterial if we do not expose the engine to maliciously designed time controls, like first 40 moves per hour, and then 30 sec for the rest of the game. Then the engine will be taken completely by surprise, and the game will likely be decided by who accidentally has more time left on his clock after the first session. Engines that could see the disaster coming, would of course ignore the 40/60, and divide their time as if this had been a 60:30+0 sudden-death control, and thus leave about 20 min on their clock after 40 moves. But if we keep things within reason, like 40/60+15, there would hardly be any reason for the engine to divide his time differently in the first session than with a cassical 40/60 TC.

Nevertheless, I would want to include a possibility for the engines to request the full multi-session TC specification in advance, so they can protect themselves from malicious time controls. The easiest way would simply send them the full string. "40/60+20/15+5+1" or "40/60+0:30". To be compatible with the old 'level' format, the number of moves in the leading session would be sent as the MPS parameter, a possible increment at the end of the string as INC. The rest of the string could go in the TC parameter, which is already defined as a string (to handle the seconds).

An engine requesting this advance information would thus recieve

level 40 60+20/15+5 1
or
level 40 60+0:30 0

at the begnning of the game, for the two examples. And after the first 40 moves were done, they would receive just before they have to start thinking on their 41th move (or before it is force-fed to them):

level 20 19+5 1
or
level 0 4:30 0

assuming they had 4 min left on their clock from the first session. The second example would then have to finish the game in the second session, and would hus not receive any more level commands. The first example, just before move 61, would then receive

level 0 8 1

assuming 3 minutes were left on the clock from the first two sessions.

Engines that would not have requested advance TC info (say through feature sessions=1), would under the same conditions receive

level 40 60 0
level 20 19 0
level 0 8 1
(example 1)

or
level 40 60 0
level 0 4:30 0
(example 2)

i.e. only a description of the situation upto the end of the upcomming session.

How does that sound? Would it ork with your engine?

[Dann Corbit]

I prepared an adapted version of the WinBoard protocol definition.

This version of the document contains some clarification on points where the original protocol definition was vague or absent, describing the exact meaning that the implementation in WinBoard 4.3.xx has implemented.

The new paragraphs are highlighted in green. Many are just trivial extensions of the old protocol, like defining the names of some new variants. The only essentially new additions to the protocol are the engine debug output, and the node-count based time control.

I also already put in some advance information that might be important for implementing multi-session time controls in the future.

Please let me know what you think about this.

I have a suggestion:
Create WBUCI protocol. It encompasses all of Winboard/Xboard and all of UCI. The engine simply understands any combination of Winboard or UCI control flow without having to differentiate.

It combines the ease of setup with UCI engines with the ease of play of Winboard engines.

Best of both worlds, as I see it.

[H.G.Muller]

I am not sure how exactly you imagine such a protocol would look. Perhaps because I do not know UCI protocol at all. What I understand from discussions about it that now and then surface, is that the strong point of UCI is that it defines a standard for the parameters that an engine needs at startup, like hash-table size, book and EGTB paths, EGTB cache, Pawn Hash, Eval Cache.

But is seems to me the problem with WB engines is not so much that such parameters cannot be set through the same stdio channel as that handles the moves during playing. Such parameters can just as easy be generated by the GUI for passing as command-line arguments to the engine it starts. If only there was a standard for this.

One line of reasoning might be that WB protocol is a tightly controlled standard, so that adding the setup commands to that protocol would be accepted as standard much more rapidly than designing a standard for command-line arguments. A second point might be that using the same channel for all communication would be easier on the engine programmer, which than only has to learn about stdio, and can ignore command-line arguments.

But I think the existing WinBoard protocol already offers an excellent device for setting up engines, namely the 'features' command. It would be a comparatively small protocol extension to make it possible for the engine to make known to WinBoard what setup parameters it needs/can handle through the stdio channel. How about having a feature similar in syntax to the 'variants' feature, where the engine can tell to WinBoard all the setup options it will understand? like

feature options="hash,EGTBcache,nalimovpath,bookpath"

This would enable WinBoard to send commands

hashsize 128
EGTBcache 32
nalimovpath F:\chess\nalimov
bookpath F:\chess\books\goldbook.bk

Would this achieve the ease of setup that you had in mind?

[Roger Brown]

I am not sure how exactly you imagine such a protocol would look. Perhaps because I do not know UCI protocol at all.

I am in the same boat. In addition, I am not as bright as the other contributors in this thread but I am fascinated by your work on Winboard, Xboard and the protocol.

What I understand from discussions about it that now and then surface, is that the strong point of UCI is that it defines a standard for the parameters that an engine needs at startup, like hash-table size, book and EGTB paths, EGTB cache, Pawn Hash, Eval Cache.

That is my understanding as well. The full protocol can be examined at:

http://www.shredderchess.com/download.html

[SNIP]

But I think the existing WinBoard protocol already offers an excellent device for setting up engines, namely the 'features' command. It would be a comparatively small protocol extension to make it possible for the engine to make known to WinBoard what setup parameters it needs/can handle through the stdio channel. How about having a feature similar in syntax to the 'variants' feature, where the engine can tell to WinBoard all the setup options it will understand? like

feature options="hash,EGTBcache,nalimovpath,bookpath"

This would enable WinBoard to send commands

hashsize 128
EGTBcache 32
nalimovpath F:\chess\nalimov
bookpath F:\chess\books\goldbook.bk

Would this achieve the ease of setup that you had in mind?

I do not and cannot speak for Dann Corbit but my issues with this approach are:

(a) There are engnies that get cranky when they do not find their own book in the same folder as the executable

(b) Wouldn't the several different book formats present a real problem here?

(c) What about engines with no opening book or an internal opening book?

(d) What about engines that have not implemented egtb's?

(e) What about engines that have not implemented settable hash size? Or that depend on a command argument to set hash? Or that set hash in discrete steps not compatible with 128 Mb? Would that engine simply have to find the next best hash size?

Is it contemplated that the engine be sent these commands at startup (in preference to any arguments in its settings file) and then where there is a problem, resolving it by then reading its configuration file at the end?

So the sequence is:

(a) These are some commands. Do you understand them? Good.

(b) Where (a) is no (not understanding the command or the command is ambigious), then I (the gui) turn you over to the configuration file for further clarity.

I hope I have not now exposed my idiocy for the world to see.



Later.

[Harald Lüßen]

I am not sure how exactly you imagine such a protocol would look. Perhaps because I do not know UCI protocol at all. What I understand from discussions about it that now and then surface, is that the strong point of UCI is that it defines a standard for the parameters that an engine needs at startup, like hash-table size, book and EGTB paths, EGTB cache, Pawn Hash, Eval Cache.

But is seems to me the problem with WB engines is not so much that such parameters cannot be set through the same stdio channel as that handles the moves during playing. Such parameters can just as easy be generated by the GUI for passing as command-line arguments to the engine it starts. If only there was a standard for this.

One line of reasoning might be that WB protocol is a tightly controlled standard, so that adding the setup commands to that protocol would be accepted as standard much more rapidly than designing a standard for command-line arguments. A second point might be that using the same channel for all communication would be easier on the engine programmer, which than only has to learn about stdio, and can ignore command-line arguments.

But I think the existing WinBoard protocol already offers an excellent device for setting up engines, namely the 'features' command. It would be a comparatively small protocol extension to make it possible for the engine to make known to WinBoard what setup parameters it needs/can handle through the stdio channel. How about having a feature similar in syntax to the 'variants' feature, where the engine can tell to WinBoard all the setup options it will understand? like

feature options="hash,EGTBcache,nalimovpath,bookpath"

This would enable WinBoard to send commands

hashsize 128
EGTBcache 32
nalimovpath F:\chess\nalimov
bookpath F:\chess\books\goldbook.bk

Would this achieve the ease of setup that you had in mind?

You could do more. I think you are now in a position to improve Winboard
a lot, and with the acceptance of many programmers. For a long time
winboard was just stable but stuck. And if you change something
have a look at the UCI protocol. Perhaps there are ideas and features
that are worth to 'steal'. This would also make it easier to change
and expand the engine side of the communication.

I have not looked up whether and how UCI does this:
Make it easy for an engine to tell the GUI (and the human user) how
to change a lot of parameters with dialog boxes. The engine could send
something like this:
setting <featurename> <valuetype> [<list of values> | <min> - <max> | <free text>]
With <valuetype> := bool | list | int | string
Example:
setting "UseTrick17" bool 0
setting "Style" list "solid" "normal" "active" "agressive"
setting "KingSafetyPercent" int 0 - 100
setting "LearnFile" string ".\default_learn_file"
setting "UseSecretSettings" string "A1_B42_X23"
I mean, let the engine tell the GUI all things that it needs to know
to build a dialog box on the fly (perhaps even with some grouping
informations and radio buttons):
setting group "Title" radio
...
setting group end

And on the other hand Winboard could respond with something like this:
setting <featurename> <value>
Example:
setting "UseTrick17" 1
setting "Style" "active"
setting "KingSafetyPercent" 67
setting "LearnFile" ".\other_learn_file"
setting "UseSecretSettings" "A1_B6x9_U2"

May be that this seems to be overkill. But not every day we [ you ]
have the possibility to think ahead and do some good work for the future.

Harald

[Roger Brown]

You could do more. I think you are now in a position to improve Winboard
a lot, and with the acceptance of many programmers. For a long time
winboard was just stable but stuck. And if you change something
have a look at the UCI protocol. Perhaps there are ideas and features
that are worth to 'steal'. This would also make it easier to change
and expand the engine side of the communication.

[SNIP]

May be that this seems to be overkill. But not every day we [ you ]
have the possibility to think ahead and do some good work for the future.

Whatever I have said in private, let me say in public. Persons such as Tim Mann, Alessandro Scotti and now H.G.Muller (forgive me for any names omitted, no disrespect intended) are to be commended and H.G. in particular is doing some really wild and good stuff with Winboard - both the gui and the protocol.

The more the better.

Thanks all.

Ps I am of course endorsing everything Harald Lüßen said.

[H.G.Muller]

Make it easy for an engine to tell the GUI (and the human user) how
to change a lot of parameters with dialog boxes. The engine could send
something like this:
setting <featurename> <valuetype> [<list of values> | <min> - <max> | <free text>]
With <valuetype> := bool | list | int | string
...

It seems that wat you want is to let the engine decide how dialog boxes poppe up by the GUI look. But WB protocol already has a very similar feature:

askuser REPTAG MESSAGE

If an engine sends this, WinBoard pops up a dialog box containing MESSAGE, (e.g. describing the possible answers), and the user can then type in a text string as an answer. This answer will than be sent to the engine as a command

REPTAG ANSWER

So the engine can in fact define any command outside WB protocol that it would like to receive. It could for example send

askuser hashsize Please enter hash size in MB

and when the user would type 256, the engine would receive:

hashsize 256

Is this what you had in mind? Perhaps it is a problem that we want the user to initiate the engine prompting for its settings. So we could add a command 'configure' to WB protocol. If WB sends this to the engine, the latter should start asking the user for the settings it needs. Clicking some menu item would trigger the sending of 'configure' to the engine, the engine would use 'askuser' to present a menu of parameters that could be set. The user would respond by typing the number of the parameter he wants to change. The engine gets send something like

parameter 4

and uses askuser again for a new dialog specified for this parameter

[Zach Wegner]

IMO that's a pretty clumsy way of handling it. This is one area where I think the UCI protocol works pretty well. They have a standard way of representing parameters, along with a set of standard parameters such as hashsize that can be set universally. Making the engine create dialog boxes is a bit cumbersome, to say the least.

I think the optimal solution would have the GUI create the configuration window, where it can put all parameters in one place and use things like drop down menus. There can also be "system-wide" configurations, such as setting the hashsize for all engines that support such a command. This is of course only applicable (for now) for GUIs like Arena, that handle large amounts of engines simultaneously.

[H.G.Muller]

This is of course only applicable (for now) for GUIs like Arena, that handle large amounts of engines simultaneously.

Not necessarily. For the WinBoard philosophy, which uses the GUI only for the duration of one match between to opponents (usually even only a single game), the equivalent of a global setting is simply what you include in the winboard.ini file. The option stored in there for the hash size will be valid each time you restart WinBoard, i.e. for all engines. Engines could be started in such a way (instructed by the options passed to them in the /fcp, /scp argument) to ignore the option and determine their own hash size.

I also think there is no advantage in having engines define what commands they need to adjust something as universally present in engines as hash size. I just wanted to point out that the mechanism to o it is already there, even in protocol 1. And for very special features, not included in the standard, allowing the engines to communicate with the user can be a very useful feature. The best idea to me still seems to be to add commands like

memory N
cores N
EGTBpath DIRECTORY
bookpath FILENAME

and let the engine request sending of the settings that apply to the current game (because the user set them through the WinBoard menus, or because they were specified in the command-line or winboard.ini) through a a 'feature options={...}'.

Options like playing style might be more triky, because they cannot be easily standardized. Each engine might have his own list of styles (or a single, unnamed one). So a command

style STRING

would be difficult for WinBoard to handle universally. But if it does not know what arguments are allowed, it could simply send 'style' to the engine without an argument. The engine could than respond by popping up a dialog box, listing the styles it supports, (using the 'askuser' command) and wait for the user to select one of them.

[Harald Lüßen]

This is of course only applicable (for now) for GUIs like Arena, that handle large amounts of engines simultaneously.

Not necessarily. For the WinBoard philosophy, which uses the GUI only for the duration of one match between to opponents (usually even only a single game), the equivalent of a global setting is simply what you include in the winboard.ini file. The option stored in there for the hash size will be valid each time you restart WinBoard, i.e. for all engines. Engines could be started in such a way (instructed by the options passed to them in the /fcp, /scp argument) to ignore the option and determine their own hash size.

I also think there is no advantage in having engines define what commands they need to adjust something as universally present in engines as hash size. I just wanted to point out that the mechanism to o it is already there, even in protocol 1. And for very special features, not included in the standard, allowing the engines to communicate with the user can be a very useful feature. The best idea to me still seems to be to add commands like

memory N
cores N
EGTBpath DIRECTORY
bookpath FILENAME

and let the engine request sending of the settings that apply to the current game (because the user set them through the WinBoard menus, or because they were specified in the command-line or winboard.ini) through a a 'feature options={...}'.

Options like playing style might be more triky, because they cannot be easily standardized. Each engine might have his own list of styles (or a single, unnamed one). So a command

style STRING

would be difficult for WinBoard to handle universally. But if it does not know what arguments are allowed, it could simply send 'style' to the engine without an argument. The engine could than respond by popping up a dialog box, listing the styles it supports, (using the 'askuser' command) and wait for the user to select one of them.

I did not know that Winboard already has a command for exchanging
some parameters. I also do not know how inboard is organized and works
internally. There is just this idea in my head.

I find it important that the engines should be able to aquire individual
parameters.
And it should be done in a user friendly way through the GUI. If it is
internally translated to a change in some ini file, that is ok.

There may be a wide and new range of common parameters for all
engines and Winboard may use its own dialogues to get them.

But there should be two new menu items in Winboard named
"Configure Engine 1" and "Configure Engine 2" (or use the engine names).
If an engine does not support the configuration the item could be gray.
But if an engine sends some settings requests to winboard (see my former posting)
then Winboard should start a dialog box or list box or whatever when
the menu item is clicked. I compare this with some compiler properties
settings (MS Visual Studio) or Registry entries (Windows).

The engines should be console programs and not display any graphics
and boxes. But Winbord is the GUI. It has all the window handles and
should be able to display something. This something should be free
in its content but restricted in its format (bool, int, text, lists).

The engines should send their description of this communication when
they are started and discuss their abilities with winboard.
The result of these settings should be send to the engines before a game
starts. In between is the time for the user to use the settings.

Harald

P-S.: I appreciate your good work on Winboard.

P.P.S.: I just found my very old Atari ST chess program sources.
Do you want a 300 KByte ZIP file with the (bad) program, the sources
and some piece bitmaps? Send me a mail address.

[Matthias Gemuh]

You could do more. I think you are now in a position to improve Winboard
a lot, and with the acceptance of many programmers. For a long time
winboard was just stable but stuck. And if you change something
have a look at the UCI protocol. Perhaps there are ideas and features
that are worth to 'steal'. This would also make it easier to change
and expand the engine side of the communication.

I have not looked up whether and how UCI does this:
Make it easy for an engine to tell the GUI (and the human user) how
to change a lot of parameters with dialog boxes. The engine could send
something like this:
setting <featurename> <valuetype> [<list of values> | <min> - <max> | <free text>]
With <valuetype> := bool | list | int | string
Example:
setting "UseTrick17" bool 0
setting "Style" list "solid" "normal" "active" "agressive"
setting "KingSafetyPercent" int 0 - 100
setting "LearnFile" string ".\default_learn_file"
setting "UseSecretSettings" string "A1_B42_X23"
I mean, let the engine tell the GUI all things that it needs to know
to build a dialog box on the fly (perhaps even with some grouping
informations and radio buttons):
setting group "Title" radio
...
setting group end

And on the other hand Winboard could respond with something like this:
setting <featurename> <value>
Example:
setting "UseTrick17" 1
setting "Style" "active"
setting "KingSafetyPercent" 67
setting "LearnFile" ".\other_learn_file"
setting "UseSecretSettings" "A1_B6x9_U2"

May be that this seems to be overkill. But not every day we [ you ]
have the possibility to think ahead and do some good work for the future.

Harald

Setting engine parameters through GUI should be done exactly according to UCI protocol. Any other approach is absolutely unreasonable (both to engine authors and GUI authors).

.

[Zach Wegner]

OK, let me be more clear: I like the idea of standard commands, like the ones you describe. But I think for custom parameters, like "style", there should be a UCI-like interface for setting them. I also think the "feature" command is a suitable place for them. It might look something like this:

Code: Select all

feature stdoptions="hash,EGTBcache,nalimovpath,bookpath"
feature option style list stupid patzer mediocre weak
feature option lmr_history_percent int 0 - 100

etc.

Basically a hybrid between yours and Harald's suggestions.

And about the Arena thing, I was referring to, say, setting up a multi-core tournament, or a no-egtb tournament, etc. But of course I now see that a command line switch could have the same effect. Also, keep in mind that there is no xboard.ini. Maybe it would be good to add such functionality...

[H.G.Muller]

Also, keep in mind that there is no xboard.ini. Maybe it would be good to add such functionality...

Indeed, for convenient operation of PSWBTM there must be an xboard.ini. I will see if I can still add one before we release, even if it cannot be saved yet.

Or perhaps, as a temporary kludge, I should provide an adater for invoking xoard by PSWTM, that does nothing else but reading xboard.ini, put whatever is in there as arguments before the arguments with which it was called, and then call xboard (through an exec call, no forking).

How exactly is the

feature option style list stupid patzer mediocre weak
feature option lmr_history_percent int 0 - 100

better then

askuser style Enter style: stupid patzer mediocre weak
askuser lmr_history_percent Give lmr history percentage:

?

From the viewpoint of the engine, it seems quite immaterial if you have to send one or the other.