polyglot write problem

[Gábor Szots]

I am experimenting with Windows 8.1. First I installed WB 4.7.3 then I copied my winboard47.ini from my Vista drive to the 8.1 drive (same AppData locations), then I installed HIARCS 14 WCSC under WB. I even played a game with it. Then I changed a parameter and upon pressing "save" an error message popped up saying 'write_ini():.\_PG\HIARCS_14_WCSC.ini: Permission denied."

What is happening here and what is the solution?

[H.G.Muller]

Polyglot stores the ini files for the individual engines all in the sub-folder _PG of the WinBoard folder. It only stores settings in them that are not the engine defaults, so initially there might not be any ini file created at all. Only when you first press 'Polyglot Save' after having changed some settings an ini file would be created.

I would expect a message of the kind you get when this _PG sub-folder did not exist, or somehow has access rights that would not allow the current WinBoard user to create or write files there. An alternative explanation could be that WinBoard got confused about what the current folder is, so that it looks for _PG in an entirely wrong place. I noticed this sometimes happens, although I never figured out what exactly causes it. It might have something to do with using the file-browse dialog (even in another program!).

What was the engine line you were using for HIARCS?

[Gábor Szots]

"HIARCS 14" -fcp "Hiarcs14WCSC.exe" -fd "C:\Sakk\UCI-engines\HIARCS 14\HIARCS 14 WCSC" -fn "HIARCS 14" -fNoOwnBookUCI -fUCI

However, the same happens with all UCI engines I have tried.

[H.G.Muller]

OK, there is nothing suspicious in that engine line.

What is the folder where you installed WinBoard? C:\WinBoard-4.7.3 ? Did you check if the C:\WinBoard-4.7.3\WinBoard\_PG folder does exist?

What happens if you try to save something in that folder directly from WinBoard? (E.g. use the File->Save Game menu item)

You could try to use File->Load Game on a PGN file that you placed in the WinBoard folder, and try Load 1st Engine after that, to see if that makes a difference.

[Gábor Szots]

OK, there is nothing suspicious in that engine line.

What is the folder where you installed WinBoard? C:\WinBoard-4.7.3 ? Did you check if the C:\WinBoard-4.7.3\WinBoard\_PG folder does exist?

What happens if you try to save something in that folder directly from WinBoard? (E.g. use the File->Save Game menu item)

You could try to use File->Load Game on a PGN file that you placed in the WinBoard folder, and try Load 1st Engine after that, to see if that makes a difference.

I installed WB in the C:\Sakk folder. C:\Sakk\WinBoard\_PG did exist.

When I first installed WB, I did it by running the setup file from my other (Vista) drive. I thought that might have caused the problem, so I copied the setup file to my Sakk folder and reran it. Doing so I messed up the target folders so this second run installed WB in the C:\Sakk\WinBoard folder (thereby creating another WinBoard folder beneath the already existing WinBoard folder). When I noticed that, I reran the setup once again, this time correctly chosing the path. I think this was the time when I tried again to save some parameters but got the same error message.

Now I decided to remove WinBoard altogether, so I went to the list of installed programs (downwards arrow in the start screen of Windows 8.1). There I found a WB uninstaller and ran it. It asked me some question I did not really care (I think they were referring to the removal of some ini files), so I told him to uninstall everything. Uninstalling began and after some time I noticed to my horror that the uninstaller was removing my ChessBase folder. There were 3 push buttons in the uninstall process box but all were greyed out so I could not even cancel the process to reduce damage. In the end all of my Sakk folder (in which all of my chess related stuff was stored) was removed, all Fritzes, Shredders, everything, even all 6-man syzygy files, the download of which had taken me several weeks (I have a slow ADSL connection) and have no copy of.

I am not particularly upset but I simply cannot understand how the uninstaller could remove folders that in the hierarchy were above the WinBoard folder. I wonder if you have an idea.

Best regards,

[H.G.Muller]

This is truly disastrous. If you are not upset you must be a saint...

The un-installer is the one that is generated by the installer software we use to package WinBoard. The structure of the tree of the WInBoard installation is such that when you specify to install in XXX, (default is XXX = C:\WinBoard-4.7.3), winboard.exe goes in XXX\WinBoard, but accompanying engines go in XXX\Fruit, XXX\Fairy-Max etc. So by default XXX is a folder created in the install, and the un-installer also tries to remove it, after removing XXX\WinBoard, XXX\Fruit etc. But if there is anything else in XXX, like in your C:\Skakk folder, Windows would not allow you to remove it.

But the installer then throws up this popup, to ask if you want to forcefully remove it.

This is obviously (in hindsight) far too dangerous. I just tried it myself on a test install, and what it removes does not even go to the trash bin. So if you inadvertantly answer 'yes' when it asks if it should delete C:\Skakk, it does massive and irrepairable damage to anything contained in C:\Skakk that was not part of the WinBoard install.

I am really very sorry that this happened. I feel partly responsible, because the text in the warning message must have been part of the installer-generation script (since it mentions winboard.ini), and it is much too low-profile a warning for the possible destruction you could be at the point of initiating. That an un-installer removes an occasional file that might have been created in the installed tree after a warning is one thing (although preferably it should warn for every file deleted that way separately), but I think it should never delete entire folders that it did not create during install. This un-installer is just far too primitive.

[Gábor Szots]

OK, thanks for the explanation. And I am not upset because I have my setup files on the Vista drive or on DVD's and installing the programs again won't take more than a couple of hours. The true loss is syzygy but I have started to download them again and I am already at about 4%.

As a suggestion, maybe everything should be installed under XXX\WinBoard so that no folders like XXX\Fairy-max would be created. Besides, apologies, I do not use Fairy-max, so it would be of help to me if I could untick its box at install time, then no folder outside XXX\WinBoard would be created.
Or maybe a more sophisticated installer could be used but that probably has something against it.

As a side note, I've had no crashes with WB 4.7.3 under Win8.1, which confirms that the crash problem (written up somewhere else in this subforum) was specifically Vista related.

[Waldemar]

"""PolyGlot is a "UCI adapter". It connects a UCI chess engine to an xboard interface such as WinBoard."""

"""Polyglot: A utility created by Fabien Letouzey which is used to run UCI engines under Winboard (for older versions of Winboard; the latest version of Winboard has a UCI2WB adapter built in)."""

Based on that, Is there any version of polyglot that works/runs in any/different GUI than Xboard/Winboard?

[H.G.Muller]

I would not base anything on one-liner descriptions of complex software.

Polyglot translates CECP ('WB protocol') on the GUI side to UCI on the engine side (and vice versa). That means any version of it would work with any GUI that supports CECP. There are many GUIs beside XBoard/WinBoard that support CECP.

If the GUI also supprts UCI directly, you might not need Polyglot to run a UCI engine in that GUI. But that is a different issue alltogether. With Arena, for example, you will need Polyglot to run UCI engines for Chess960, as the Arena UCI implementation for Chess960 is not compliant, and most engines do not work with it. (They would hang after the first castling.)

Another reason why people use Polyglot to run UCI engines on a GUI that would also support UCI directly is to use it as book adapter, to allow the engine to use a Polyglot (.bin) book (which the GUI might not support). For this reason Polyglot even supports a UCI-to-UCI mode, so it can be used with GUIs and engines that both only support UCI (but not Polyglot books).

[Waldemar]

Thx a lot mr. Muller! Very clarifying. Could you tell me a little about UCI to UCI mode? And how activate it?

Muchas gracias!

[H.G.Muller]

I think it activates itself. Polyglot can see whether the GUI tries to communicate with it in UCI or CECP: the first word it will receive from the GUI will be either 'uci' or 'xboard'. So it would just be a matter of installing Polyglot as UCI engine in the GUI.

It could be there also is a command-line option that could force Polyglot into UCI mode. This would be useful when dealing with GUIs that detect the engine type themselves, to make sure you use it in the mode you want. I don't know the option by heart, though, as I never use Polyglot in UCI mode. Michel van den Bergh implemented this mode.

[Waldemar]

Thx for your reply!