How to suspend a Winboard tournament?

[H.G.Muller]

When you entered that Shijia download page, at the upper right corner, did you see Shijia.rar; 545400720; 2012/06/05 16:14:43; 10.045 MB?
Then, at the down lower half there is a list of downloadable addresses, you should be able to download it from any link from the third address on (with a number attached at the address end, e.g., XXX1, XXX2, XXX3 ...).

This is what I see:


Are the green buttons with arrows the download buttons?

[Edit] OK, I got it! The texts next to the buttons are links, and the third one leads me (after two unintelligible dialogs, probably one to make me choose between a free slow and a fast payed download, and a warning that I have to OK) to a shijia.rar.

But, I wonder how dangerous a chess engine, running inside a chess board, can be.

Any executable can do damage within the full permission of the user that runs it. So if you run it as an ordinary user, it can delete or modify any file you could delete or modify by hand. If you run it as admin it can erase your hard disk. If you run it as user it could hide malicious code in a file of the user, waiting until an admin happens to run it, to be unleashed with admin powers...

Wait a minute, as the Winboard platform provider, don't you have connections with those chess engine makers? May I know your Cyclone's version? Is it a UCCI or a UCI engine?

Well, I did have an a QQ account on the Xiangqi engine-authors group. But I haven't logged in there for years. (I did not do any work on my Xiangqi engine those years; I was preoccupied by Shogi, because the ICGA Olympiad 2010 was in Japan.) Last time I used it it suddenly started downloading unlimited amounts of stuff without warning. After 40MB I shut it down, and closed my firewall to it, and I don't dare using it ever since.

But this is how I got the Cyclone: Its author (Fibbery) sent it to me through QQ, in order to test it. I think it was called Cyclone2009.

[H.G.Muller]

I don't dare to run it yet, because of the virus hazard. (I have no virus scanner at all yet, on my new computer.) I will try set up a virtual machine one of these days, and try it out there.

From lookin at the rar contents, it seems that this is a stand-alone version that comes with its own GUI. It might not be UCI at all. I met the author of Shiga ('Poor') both at the ICGA Olympiad in 2010 (Kanazawa, Japan) and 2011 (Tilburg, Netherlands), but he does not understand a word of English...

[cnchang]

Your discretion is duly noted. I am trying to contact BHWS author referring to this post. Hopefully, he will shed some light on this.
Shiga('Poor') means ?

[H.G.Muller]

It seems to be the name of the author. (E.g. http://www.cc-xiexie.com/photo05.php )

[cnchang]

May I know your Cyclone's version? Is it a UCCI or a UCI engine?

But this is how I got the Cyclone: Its author (Fibbery) sent it to me through QQ, in order to test it. I think it was called Cyclone2009.

The reason I was asking about your cyclone engine is that I downloaded two cyclone engines from the web.
One is cyclone2011, and the other is cyclone6.2. They are both UCI engines.
When I unpacked cyclone2011 and ran it on Winboard, this engine was identified by Winboard as ggchess.
Not sure which one is more advanced.
I wonder what version is your cyclone so I know we are on the same page.
Here are SHA256 checksums of my two cyclone engines:
1. 3253d96dda0ee84e35ec397fe2b67b36d0a7761b39ae31fc93f1e62a529befb0 -> named cyclone.exe but identified as ggchess.
2. 9f4580f11fe010ac3383139bccb1aaba79c55546617cc1bdb7ab7d359586872b -> cyclone62.exe
My bet is that yours is cyclone v6.2.

[H.G.Muller]

WinBoard takes the name from the enfine from the 'id name' command it prints at startup. You can check this yourself by running the engine bare, by double-clicking the .exe, and typing 'uci'. It should then print 'id name xxx', 'id author xxx' and its options.

The cyclone2009 I have (23KB) says

id name cyclone 2009
id author chency

and starts by spontaneously printing "cyclone 2009 by chency". I also have a cyclone2007c, (272KB), which says "cyclone 2007c by fibbery". I am not sure why the author message changed between the two; I obtained cyclone 2009 from Fibbery himself. I also have a Cyclone626, which is way bigger (635KB), but I don't dare to run it, because the Virus scanner on my laptop thinks it is infected, and deleted it from there.

I don't know how to calculate SHA256.

[H.G.Muller]

I have uploaded a new UCI2WB.exe at http://hgm.nubati.net/WinBoard-4.7.beta.zip . It also contains a new winboard.exe, with some unrelated bugfixes. The UCI2WB indeed had a problem when pondering was off: it tried to stop an already idle engine, and was then waiting for it to acknowledge that it had stopped!

[H.G.Muller]

Well, Shiga does seem to sort-of work as a UCI engine. I ran it with UCI2WB in debug mode, where it reports everything the engine says to the GUI as comment line (starting with #), which again then writes it in its own debug file. And I see the normal UCI responses there. It showed thinking output (scores and PVs), and did make moves.

Problem is that is does not seem to allow setting of the hash-table size through the protocol interface, and that it seems hard-wired for the rather large size of 512MB. Which is the total amount of memory on my laptop, so that the use of the hash slows it down several hundredfold, as it has to use disk in stead of RAM for it...

Code: Select all

StartChildProcess (dir=".") UCI2WB debug Shiga.exe D:\Shijia
nice engine proc to 10
1342 >first : xboard
protover 2
11357 >first : new
random
11357 >first : variant xiangqi
11357 >first : level 40 5 0
11357 >first : post
11357 >first : hard
12438 <first : feature variants="normal,xiangqi" setboard=1 usermove=1 debug=1 ping=1 reuse=0 exclude=1 done=0
12438 >first : accepted variants
12438 >first : accepted setboard
12438 >first : accepted usermove
12438 >first : accepted debug
12438 >first : accepted ping
12438 >first : accepted reuse
12438 >first : accepted exclude
12438 >first : accepted done
12438 <first : feature option="UCI2WB debug output -check 1"
12438 >first : accepted option
12438 <first : # engine said: max threads set to 2
12759 <first : # engine said: XQMS 3.26_10_19. By  ½¯Ö¾Ãô¡¢ÕÅÃö.
13189 <first : # engine said: id name XQMS 3.26_10_19
13189 <first : feature myname="XQMS 3.26_10_19 (UCI2WB)"
13189 >first : accepted myname
13199 <first : # engine said: id author ½¯Ö¾Ãô¡¢ÕÅÃö.
13199 <first : # engine said:
13309 <first : # engine said: uciok
13309 <first : feature smp=1 memory=0 done=1
13309 >first : accepted smp
13309 >first : accepted memory
13309 >first : accepted done
13309 <first : # engine said:
13309 <first : feature smp=1 memory=0 done=1
13309 >first : accepted smp
13309 >first : accepted memory
13309 >first : accepted done
13309 <first : # engine said: XQMS Use uci[ucci] protocol
13380 <first : # engine said: readyok
nps: w=-1, b=-1
nps: w=-1, b=-1
28151 >first : time 30000
28151 >first : otim 30000
book hit = (NULL)
28151 >first : usermove 28151 >first : e3e4
28291 <first : # start search
28291 <first : # fen rnbakabnr/9/1c5c1/p1p1p1p1p/9/9/P1P1P1P1P/1C5C1/9/RNBAKABNR r moves e3e4
28291 <first : # go btime 300000 wtime 300000 movestogo 40
58895 <first : # engine said: bestmove b7e7 ponder b2e2
58895 <first : # ponder on b2e2
58895 <first : # fen rnbakabnr/9/1c5c1/p1p1p1p1p/9/9/P1P1P1P1P/1C5C1/9/RNBAKABNR r moves e3e4 b7e7 b2e2
58895 <first : # go btime 268783 wtime 300000 movestogo 39 ponder
58895 <first : move b7e7
silence
59386 <first :
72755 <first : # engine said: info depth 7
72785 <first : # engine said: info currmove e7e4 currmovenumber 1
83080 <first : # engine said: info depth 7 score 143 time 20199 nodes  29838 nps 1477 pv e7e4 d0e1 h7e7 e0d0 h9g7 a0a2 i9h9
83080 <first :   7     143   2019      29838 e7e4 d0e1 h7e7 e0d0 h9g7 a0a2 i9h9
83220 <first : # engine said: info currmove h7h0 currmovenumber 2
83250 <first : # engine said: info depth 8
83250 <first : # engine said: info currmove e7e4 currmovenumber 1
87676 <first : # engine said: info depth 8 score 111 time 24785 nodes  40810 nps 1646 pv e7e4 d0e1 h7e7 h0g2 a9a7 b0c2 h9g7 c2e3
87676 <first :   8     111   2478      40810 e7e4 d0e1 h7e7 h0g2 a9a7 b0c2 h9g7 c2e3
87686 <first : # engine said: info currmove h7h0 currmovenumber 2
87977 <first : # engine said: info currmove i9i7 currmovenumber 4
88177 <first : # engine said: info currmove b9c7 currmovenumber 6
88508 <first : # engine said: info currmove a9a8 currmovenumber 7
88728 <first : # engine said: info currmove h7i7 currmovenumber 10
88798 <first : # engine said: info currmove e7e4 currmovenumber 1
Interrupting first
90360 >first : time 26915
90360 >first : otim 26863
book hit = (NULL)
90360 >first : usermove 90360 >first : h0g2
90821 <first : # stop
90821 <first : # start search
90821 <first : # fen rnbakabnr/9/1c5c1/p1p1p1p1p/9/9/P1P1P1P1P/1C5C1/9/RNBAKABNR r moves e3e4 b7e7 h0g2
90821 <first : # go btime 269150 wtime 268630 movestogo 39
91983 <first : # engine said: info depth 8 score 95 time 29112 nodes  50426 nps 1732 pv e7e4 d0e1 h7e7 h0g2 h9g7 b0c2 i9h9 c2e3
91983 <first :   8      95   2911      50426 e7e4 d0e1 h7e7 h0g2 h9g7 b0c2 i9h9 c2e3
92013 <first : # engine said: info currmove h7h0 currmovenumber 2
92854 <first : # engine said: info currmove a9a8 currmovenumber 5
93074 <first : # engine said: info currmove b9c7 currmovenumber 9
93535 <first : # engine said: info currmove h7i7 currmovenumber 10
93535 <first : # engine said: info depth 9
93535 <first : # engine said: info currmove e7e4 currmovenumber 1
114665 <first : # engine said: info depth 9 score 108 time 51794 nodes  93254 nps 1800 pv e7e4 d0e1 h7e7 h0g2 h9g7 b0c2 g6g5 g2e3 i9h9
114665 <first :   9     108   5179      93254 e7e4 d0e1 h7e7 h0g2 h9g7 b0c2 g6g5 g2e3 i9h9
114675 <first : # engine said: info currmove h7h0 currmovenumber 2
114865 <first : # engine said: info currmove h9g7 currmovenumber 3
115526 <first : # engine said: info currmove b9c7 currmovenumber 4
119252 <first : # engine said: info currmove a9a7 currmovenumber 5
119712 <first : # engine said: info currmove i9i7 currmovenumber 7
119933 <first : # engine said: info currmove e7d7 currmovenumber 11
120273 <first : # engine said: info currmove h7h6 currmovenumber 15
120584 <first : # engine said: info currmove h7g7 currmovenumber 16
120784 <first : # engine said: info currmove h7h4 currmovenumber 22
121034 <first : # engine said: info currmove c6c5 currmovenumber 29
121154 <first : # engine said: info depth 10
121154 <first : # engine said: info currmove e7e4 currmovenumber 1
125050 <first : # engine said: info depth 10 score 108 time 62139 nodes 108957 nps 1753 pv e7e4 d0e1 h7e7 h0g2 h9g7 b0c2 g6g5 g2e3 i9h9 e2e4
125050 <first :  10     108   6213     108957 e7e4 d0e1 h7e7 h0g2 h9g7 b0c2 g6g5 g2e3 i9h9 e2e4
125260 <first : # engine said: info currmove h7h0 currmovenumber 2
125641 <first : # engine said: info currmove b9c7 currmovenumber 3
126272 <first : # engine said: info currmove h9g7 currmovenumber 4
128205 <first : # engine said: info currmove i9i7 currmovenumber 6
129296 <first : # engine said: info currmove h7h5 currmovenumber 8
129607 <first : # engine said: info currmove b9a7 currmovenumber 12
129797 <first : # engine said: info currmove e7e8 currmovenumber 14
130077 <first : # engine said: info currmove c9a7 currmovenumber 15
130298 <first : # engine said: info currmove a9a7 currmovenumber 16
130538 <first : # engine said: info currmove f9e8 currmovenumber 22
131209 <first : # engine said: info currmove g9i7 currmovenumber 26
131409 <first : # engine said: info currmove e9e8 currmovenumber 27
131720 <first : # engine said: info currmove a6a5 currmovenumber 31
131880 <first : # engine said: info depth 11
131880 <first : # engine said: info currmove e7e4 currmovenumber 1
159670 <first : # engine said: bestmove e7e4 ponder d0e1


[cnchang]

Downloaded and tested new beta. Pause/RESUME function works well with UCI&UCCI engines now, so as with MaxQi and HaqiKid.
Some engines indeed failed to coordinate with the board for their hash size and CPU threads settings.
Shiga uses 512MB in BHGUI games as well when set to 128MB. It definitely is an engine specific problem.
CPU threading (core numbers) is another concern. ggchess and cyclone6.2 use all CPU cores when set to 1 core only.
Is it possible for me to extract a debug output/dump from Winboard like that in your post so that I can see if the problem is coming from the engine side?

[H.G.Muller]

To make a debug log you have to run WinBoard with the 'Additional option' -debug . It will then create a file winboard.debug, which, amongst other stuff, lists all communication between GUI and engine (or adapter). But in this case you are more interested in what goes on between adapter and engine. UCI2WB has a debug mode that reports all engine->adapter traffic to the GUI, so it can appear in the winboard.debug file as well. It can be switched on through an option in the Engine Settings dialog, but if you want it to work from the very start, you can switch it on through an argument in the UCI2WB startup command. UCCI2WB reports all communication with the engine to the GUI by default. (It has a debug mode that creates an own log file, which can be switched on by a command-line argument on the UCCI2WB startup command, but I never use that.)

So in any case you have to set WinBoard to create the winboard.debug file, through the option -debug. (You can also switch it on or off during the session, with Ctrl-D, but then you would miss the part where it loaded the engine, which is usually of interest.) For UCI engines you can make an 'engine line' either by typing directly in the comboboxes of the startup dialog, or by using the Engine->Edit Engine List menu item to make it automatically recallable in the combobox, like

'UCI2WB debug ENGINE.exe ENGINEFOLDER' -debug

(The -debug at the end causes WB to report on the winboard.debug file.) If the engine name or folder contain spaces, you can put double quotes around those, this is why I used single quotes around the UCI2WB startup command. (WB understands both kind of quotes.) You cannot use the /fUCI option here, because WB is not configured to include the 'debug' argument when it invokes UCI2WB this way.

For UCCI engines you only have to include a -debug for WB, as UCCI2WB reports engine traffic by default.

As to the cores: neither UCI nor UCCI defines a standard option for controlling the number of cores, so it is just impossible for the adapters to enforce what the GUI requests on the engines. If the engine has a non-standard option for this, it should appear in the Engine Settings dialog, together with the other options. In some engines you can control the number of cores through ini files in the engine folder. There is such an ini file in the Shiga download, but I tried to change hash setting there from 512 to 64, and it had no effect. Perhaps these are files read by the Shiga GUI, which then uses some non-UCI-compliant way to affect the hash size in the Shiga engine.

We could of course try to reverse-engineer this: a very usefull tool is the InBetween adapter, which you can put between a GUI and an engine, and which reports (in a window) all communication in either direction. It can also be used to cure some non-compliancy, because you can configure it to substitute commands that go in a certain direction by arbitrary other commands. So we could rename the Shiga engine to xxx.exe, and rename InBetween.exe to Shijia.exe, so that the Shiga GUI would think it is the engine, and configure InBetween to start up xxx.exe as its back-end. Then we could spy on how the Shiga GUI uses the Shiga engine.

[cnchang]

Created a UCCI debug file, and I will look into that. Thanks.
Regarding that in-between spoofing to figure out how to properly configure those non-compliance ones, it sounds cool. But, is it really that easy?

I don't know how to calculate SHA256.

There is a handy tool made for doing something more than that.
SlavaSoft's HashCalc

You can also switch it on or off during the session, with Ctrl-D, but then you would miss the part where it loaded the engine, which is usually of interest.

Isn't that hot-key Ctrl-Alt-F12?

[H.G.Muller]

On Linux and Win 7 Ctrl+Alt+F12 causes terrible things to happen, because it apparently means something to the OS, and is not even relayed to WinBoard. So I programmed Ctrl-D as a safe alternative. (The old one still works, if WB gets it.)

I made my own 'Shiga simulator', which prints the command-line with which it is invoked, and everything it receives on its std input on a file log.txt. I renamed it to Shiga.exe (after moving the real Shiga.exe out of the way), and started the Shiga GUI. I then play a move, and click on what looks like the pictogram of a computer with the left half of the screen red. This produces the following log.txt:

Code: Select all

0. D:\Shijia\Shiga.exe
out: max threads set to 2
out: XQMS 3.26_10_19. By  ¢»Í¥+¶íói++÷.
in:  uci
out: id name XQMS 3.26_10_19
out: id author ¢»Í¥+¶íói++÷.

out: uciok

out: XQMS Use uci[ucci] protocol
in:  setoption name Ponder value true
in:  isready
out: readyok
in:  position fen rnbakabnr/9/1c5c1/p1p1p1p1p/9/9/P1P1P1P1P/1C5C1/9/RNBAKABNR w - - 0 1 moves h2h3 e6e5
in:  go movetime 10000000


After the 'go movetime' the fun of course stops, as spy.exe has no idea how to play xiangqi, and cannot reply with a move. But I think we already captured the essential part of the communication.

Non-compliancy is that the Shiga GUI apparently sends a setoption for 'Ponder' without announcing it has such an option (by "option name Ponder type check default true" in response to 'uci', as the protocol prescribes). I suppose there are alsu such 'hidden' options to set cores and hash size. But as the Shiga GUI is totally unintellegible to me (all menu texts show up as question marks), I have no idea what to operate in order to trick it into attempting to change the engine's hash size or cores limit.

Perhaps you can have a try at this? I uploaded the spy.exe program to http://hgm.nubati.net/spy.exe .

[cnchang]

Let me get better understanding on this "Shiga simulator" first. Is this simulator a receiver/recorder, or a spoofer?
1. A receiver will receive all commands from Shiga GUI actions and record it to a log file, and no more.
2. A spoofer will receive and forward any received command from GUI and forward it to the true target executive file(e.g., Shiga.exe), and then take response from that exe and relay it to back to the GUI.
If spy.exe is a spoofer, then is the target exe hardwired to "xxx.exe" where xxx.exe is the real Shiga.exe? Or, it can be any exe that we what to spoof to gather non-compliance setup info in the future.
My email is in the PM I just sent you, just another channel.

[H.G.Muller]

It is not a spoofer; it does not contact the real engine. It is a bit more than a receiver, though, as it not only listens, but makes someof the replies that I know Shiga would make. Namely everything you see when you start the engine from the command prompt, type 'uci' and then 'isready'.

I don't know if you are a C programmer, but this is the source code:

Code: Select all

#include <stdio.h>

void
out(FILE *f, char *s)
{
  printf(s); // to GUI
  fprintf(f, "out: %s", s); // on log file
  fflush(f);
}

int
main(int argc, char **argv)
{
  FILE *f = fopen("log.txt", "w");
  int j;

  for(j=0; j<argc; j++) fprintf(f, "%d. %s\n", j, argv[j]), fflush(f); // command line to log file

  out(f, "max threads set to 2\n");
  out(f, "XQMS 3.26_10_19. By  ¢»Í¥├¶íóı┼├÷.\n");

  while(1) {
   int i=0, x;
   char line[1000], command[100];

   fflush(stdout);
   while((line[i] = x = getchar()) != EOF && line[i] != '\n') i++;
   line[++i] = 0;
   fprintf(f, "in:  %s", line); fflush(f);
   sscanf(line, "%s", command);
   if(!strcmp(command, "quit")) return 1;
   else if(!strcmp(command, "uci")) {
      out(f, "id name XQMS 3.26_10_19\n");
      out(f, "id author ¢»Í¥├¶íóı┼├÷.\n\n");
      out(f, "uciok\n\n");
      out(f, "XQMS Use uci[ucci] protocol\n");
   }
   else if(!strcmp(command, "isready")) out(f, "readyok\n");
  }
}


So basically it spies on GUIs. If we want to spy on an UCCI GUI, however, it would have to be changed to behave like an UCCI engine. (I.e. not listen for 'uci' and reply 'uciok' but for 'ucci' and reply 'ucciok'.)

[cnchang]

I'm not a C programmer. But, I can try to get some books if needed.

else if(!strcmp(command, "uci")) {
out(f, "id name XQMS 3.26_10_19\n");
out(f, "id author ¢»Í¥├¶íóı┼├÷.\n\n");
out(f, "uciok\n\n");
out(f, "XQMS Use uci[ucci] protocol\n");
}
else if(!strcmp(command, "isready")) out(f, "readyok\n");

Please allow some code learning first.
Does "!" in C mean NOT?
If so, when the input command is "uci", then !strcmp(command, "uci") = !1 = 0, wouldn't the spy engine be sitting there and not responding with "id name XQMS 3.26_10_19 ..."?
Same goes with isready and readyok.

May I try picturing your spy scheme here?
Once your code finishes the basic UCI and engine handshaking sequence, then you go set up engine's property(hash, core#, time rule, ...) via its proprietary GUI to see/record what non-compliant configuration messages are exchanged.
Then, you make some kind of configuration translator for each of those engines so that Winboard GUI can set up those engines via the translators.

[H.G.Muller]

Indeed, ! is the unary NOT operator. strcmp uses the convention that it returns 1 = true if the strings are different. So !strcmp tests for equality.

But it is the GUI that sets up the hash etc. in the engine, not the other way around. So spy.exe is just sittingthere, recording what the GUI sends it. It just has to prompt the GUI to continue, by the standard UCI commands "uciok" and "isready".

The adapters I have (UCI2WB and UCCI2WB) are not based on any spying, but on the official protocol desciptions. That is, UCI2WB is an implementation of the UCI protocol as can be found on the web. Theonly existing UCCI specs seem to be in Chinese, but UCCI2WB is basically written by Morning Yellow, who designed UCCI, so I assume he knows what he was doing. But he actually wrote an UCCI2QH adapter. So what I did is take his adapter, and replace the QH (= Qianhong) protocol commands by equivalent WB commands. (QH protocol is described in English.)

But what we are trying to do now is for engines that apparently violate the protocol (because they fail to run on the adapters using the official protocol) figure out in what way the are non-compliant. It seems that for Shiga the problem is that it does not announce its options in response to the 'uci' command.

[cnchang]

strcmp uses the convention that it returns 1 = true if the strings are different.

OK, it seems like I took it the other way around. I thought it is like:

if (command == "uci")

In that case, it returns 1 when the input command equals to "uci". Then, it turns out strcmp returns 0 when the two compared strings are equal.

But what we are trying to do now is for engines that apparently violate the protocol (because they fail to run on the adapters using the official protocol) figure out in what way the are non-compliant. It seems that for Shiga the problem is that it does not announce its options in response to the 'uci' command.

When I tried to pull the initial handshake from Shiga, this is what I got:

Code: Select all

uci
id name Cheng, Ming-Cheng
id copyright 2000-2012 Global Financial interflow Platform Corp. All rights reserved.
uciok
isready
readyok


I would rather expect to see something like this:
id name Shiga
id author Cheng, Ming-Cheng

Anyway, I see only some engines announce their options, e.g., 3D, anita, bhws072, blcx, bugcchess, cyclone0.56, eleeye, sixteeners, swallow, tlxj, ufx, and xqspirit. Others don't. For those engines that don't announce their options, why not just look into their own ini for the options?
This is Shiga.ini.

Code: Select all

UseConfigFile = true
Threads = 4
Hash = 512
Clear Hash = false
Ponder = false
Draw = false
Random = false
OwnBook = false
OwnBook When Analyse = false
MultiPV = 1


I am able to change the hash or threads settings to command Shiga engine to use the new settings. It will take effect immediately. Now, Shiga doesn't need to take up 512MB hash anymore. Is it possible for your uci2wb or ucci2wb to check whether there is an ini to configure as an alternative if there is no options announced during the handshake?
If your interest does not end on what the engine options are, but more about what exactly the exchanged data looks like when Shiga GUI sets up Shiga engine. Does your spy.exe work as some IPC mechanisms?
Please take a look at this to see if it will achieve your goal.
http://msdn.microsoft.com/en-us/library/windows/desktop/aa365789(v=vs.85).aspx

BTW, I tested your spy.exe on Shiga GUI. I can't seem to find a place to set hash or threads, I only found pondering ON/OFF switch.

Code: Select all

0. D:\cchess\Shijia_o\Shiga.exe
out: max threads set to 2
out: XQMS 3.26_10_19. By  Ⅲ穸+塘鏙++?
in:  uci
out: id name XQMS 3.26_10_19
out: id author Ⅲ穸+塘鏙++?

out: uciok

out: XQMS Use uci[ucci] protocol
in:  setoption name Ponder value true
in:  isready
out: readyok
in:  ucinewgame
in:  isready
out: readyok
in:  ucinewgame
in:  isready
out: readyok
in:  setoption name Ponder value false
in:  isready
out: readyok
in:  ucinewgame
in:  isready
out: readyok
in:  setoption name Ponder value true
in:  isready
out: readyok

[H.G.Muller]

There is no guarantee the engines have an INI file, or how the info in the INI file should be used if they come with one. For instance, I tried to change the parameters in the Shiga.ini that you posted above (set Hash = 64), and it still continues to use 512MB in its own GUI.

According to UCI protocol, option settings are changed by the GUI sending (say foo = xxx)

setoption name foo value xxx

but they can only do this if they know the option exists, and whether xxx has to be a number, a text or true/false (as option names are not standardized). To inform the GUI, at startup (i.e. in response to the 'uci' command which starts the handshake) engines send a description of all options that can be set, like

option name foo type string default blahblah

(UCCI seems to be similar, but the commands are simplified by omitting the 'name', 'type', 'value' and 'default' keywords, and what is what is determined from the position in the command.)

If there is an ini file, containing lines like "foo = blahblah", there is no guarantee that the engine will be sensitive for a "setoption" command for "foo". In fact it is quite unlikely that it is, as it is much more wotk for the engine programmer to simply print "option name foo ..." as it is to open an INI file and parse the contents, and the usual motivation for using an INI file is that the programmer was too lazy to implement parsing the "setoption" commands, which could be even more work.

Shiga seems to be an exception. Or at least, the Shiga GUI seems to think so, because it sends a 'setoption' command for 'Ponder'. We don't actually know whether the Shiga engine actually does anything in response to this command; it could very well ignore it, and the Shiga GUI could send this command to any engine, for the benefit of those to which it means something.

This is why I would like to see the Shiga GUI send something that alters the behavior of Shiga in a way that we can verify (in the task manager), like number of cores or hash size. I don't know, however, how the Shiga GUI can be made to do that: I cannot operate it, because it is in Chinese. Onde assumes it has a menu control to specify hash size, and would then communicate it to the engine. E.g. does it send "setoption name threads value 1" or "setoption name max threads value 1" or "setuption name cores value 1", etc. The possibilities are infinite, so guessing is a poor strategy...

[cnchang]

As brought up before, things are fluid on that site. You might have downloaded a different version Shiga, for which it doesn't work well with Shiga.ini. I have mailed you Shiga.exe that I previously downloaded from the web in case you want to give it a try.

I agree that it would be tedious to guess all possible options and their syntaxes, especially when I can't find a menu option to set hash or threads in Shiga GUI. Even if you find a way to tap into their communications, it may still not that easy to create all kinds of adaptors. But, if there is an ini file, at least users can do some tweaks themselves to make things their way as a workaround. According to UCI protocolhttp://wbec-ridderkerk.nl/html/UCIProtocol.html, GUI should simply do the following to set up hash table size:
setoption name Hash value xxx

According to UCI protocol, option settings are changed by the GUI sending (say foo = xxx)
setoption name foo value xxx
but they can only do this if they know the option exists, and whether xxx has to be a number, a text or true/false (as option names are not standardized). To inform the GUI, at startup (i.e. in response to the 'uci' command which starts the handshake) engines send a description of all options that can be set, like
option name foo type string default blahblah

My question is that if Winboard does not receive announced options in the course of handshaking from the engine, will GUI ever try to set the hash or threads at all? I mean at worst non-compliant engine should just ignore the received setoption commands, isn't it? Per UCI Protocol,

if the engine or the GUI receives an unknown command or token it should just ignore it and try to parse the rest of the string.

[H.G.Muller]

I have mailed you Shiga.exe that I previously downloaded from the web in case you want to give it a try.

OK, I will check if they are any different.

I agree that it would be tedious to guess all possible options and their syntaxes, especially when I can't find a menu option to set hash or threads in Shiga GUI. Even if you find a way to tap into their communications, it may still not that easy to create all kinds of adaptors. But, if there is an ini file, at least users can do some tweaks themselves to make things their way as a workaround. According to UCI protocolhttp://wbec-ridderkerk.nl/html/UCIProtocol.html, GUI should simply do the following to set up hash table size:
setoption name Hash value xxx

Sure, once you start guessing that would be the first guess to make. Many UCCI engines do not understand Hash, though, but use hashsize in stead. Once an engine is non-compliant, there is no way of knowing how far the non-compliancy will go.

My question is that if Winboard does not receive announced options in the course of handshaking from the engine, will GUI ever try to set the hash or threads at all?

If the engine does not announce it supports Hash or threads, WB will indeed not attempt to set them.

I mean at worst non-compliant engine should just ignore the received setoption commands, isn't it? Per UCI Protocol,

if the engine or the GUI receives an unknown command or token it should just ignore it and try to parse the rest of the string.

Indeed. But compliancy with that in non-compliant engines is also expecting a bit much. There are engines that crash (or exit) when they receive something they don't expect. There are even engines that crash on receiving perfectly legal UCI/USI when the arguments of the option are not in the order they expect it. (Like "go wtime X btime Y" works, "go btime Y wtime X" -> crash.)

I think the best solution would be to have UCI2WB check for a file "EngineNoncompliancy.ini" in the engine folder, which users could use to iron out non-compliancies. The file could be read just before the reception of "uciok" from the engine, as if the engine would have sent whatever is in the file. That way the user could put lines like

option name Hash default 512
option name max threads default 2

in the file if he has somehow figured out that the engine responds to setting the options 'Hash' and 'max threads'. UCI2WB would then behave exactly as if the engine would have sent those commands. Which means it would reply with "setoption name Hash value 64" if the WB hash size was set to 64MB.