Winboard Forum

This is an extremely useful posting, but it raises some questions:

For one, it could be improved in some places. E.g. it remarks that WinBoard_x comes without a help file, and then recommends to download an obsolete help file from version 4.2.7, which will not contain anything about WinBoard_x. While WinBoard 4.3.14 comes with a complete help file that describes every feature of WinBoard_x, and even highlights the WinBoard_x features in red so they are easily recognizable.

If we intend this to become a reference document for advising people how to do this, I think we should give them the best possible advice in it. So I forward a motion to edit this post to improve it (with permission of the original author, of course, which I hereby sollicit).

I agree that making it sticky in this forum section is not the best idea, but I think it deserves better than to be slowly shifted towards oblivion. In the 'WinBoard development and bugs report' section of this forum there already is a (locked) sticky thread with the WinBoard 4.3 download. I think this would be an excellent place for it. So I propose to move or copy this post as a second post in that sticky trheread, directly after the post with the download links for WB 4.3 and Polyglot 1.4.

Another concern is that this post makes it obvious that we are making a strategic mistake in packaging the WinBoard dowloads. The whole process described requires one to download all kinds of software from many different places. I was already made aware of this when I was advertizing WinBoard on the Rybka forum: this evoked the criticism "WinBoard is very user-unfriendly software, because you have to download things from a zillion different places before it works, and people just don't know how to do that". Of course it is unfair to blame that on the software, it is merely a deficiency in bundling strategy. A deficiency that we could easily address and remedy!

So I indeed intend to remedy it in the next WinBoard release. In any case I want to bundle the most-advanced Polyglot version with WinBoard, in the executable download package. I understood that both WinBoard and Polyglot are covered by the GPL, so there is no legal problem in distributing them together.

It would be very nice if we could distribute the Polyglot_GUI in the same package, but I don't know if its licencing policy permits this. Ideally we should eliminate all download steps from the prescription above, so that once people click the "download WinBoard executable for Windows", and unpack it, they will have the whole toolkit ready and installed. This might include a tournament manager as well (PSWBTM?). It would be very important to mae sure the suppleid components would also work under Linux.

H.G.Muller wrote:This is an extremely useful posting, but it raises some questions:

It is useful. I almost feel like imposing on its author again....I hope he will give the slight editing and moving of the post his blessing.

For one, it could be improved in some places. E.g. it remarks that WinBoard_x comes without a help file, and then recommends to download an obsolete help file from version 4.2.7, which will not contain anything about WinBoard_x. While WinBoard 4.3.14 comes with a complete help file that describes every feature of WinBoard_x, and even highlights the WinBoard_x features in red so they are easily recognizable.

I agree here. That helpfile has been updated but the unfortunate truth is, more needs to be done to aggressively push the knowledge of these improvements. This forum has a smaller membership (although much nicer huzzah!) than other places.

If we intend this to become a reference document for advising people how to do this, I think we should give them the best possible advice in it. So I forward a motion to edit this post to improve it (with permission of the original author, of course, which I hereby sollicit).

I second the motion right now.

I agree that making it sticky in this forum section is not the best idea, but I think it deserves better than to be slowly shifted towards oblivion. In the 'WinBoard development and bugs report' section of this forum there already is a (locked) sticky thread with the WinBoard 4.3 download. I think this would be an excellent place for it. So I propose to move or copy this post as a second post in that sticky trheread, directly after the post with the download links for WB 4.3 and Polyglot 1.4.

I agree here as well. Despite the modesty of the author this creation deserves more than a gradual slide off the radar. Your suggestion makes eminent sense and should make both parties happy. The author will not have the concern of seeing his post on the front page and all the visitors will be rapidly able to find the information which is quite useful.

H.G., this is really disturbing, I am actually agreeing with you all the way!

Another concern is that this post makes it obvious that we are making a strategic mistake in packaging the WinBoard dowloads. The whole process described requires one to download all kinds of software from many different places. I was already made aware of this when I was advertizing WinBoard on the Rybka forum: this evoked the criticism "WinBoard is very user-unfriendly software, because you have to download things from a zillion different places before it works, and people just don't know how to do that". Of course it is unfair to blame that on the software, it is merely a deficiency in bundling strategy. A deficiency that we could easily address and remedy!

So I indeed intend to remedy it in the next WinBoard release. In any case I want to bundle the most-advanced Polyglot version with WinBoard, in the executable download package. I understood that both WinBoard and Polyglot are covered by the GPL, so there is no legal problem in distributing them together.

Alright, this does it. I agree again with you! This is ironic as Fabien had jokingly remarked to me that he invented Polyglot to kill Winboard when it has made the gui even more relevant than ever.

It would be very nice if we could distribute the Polyglot-GUI in the same package, but I don't know if its licencing policy permits this. Ideally we should eliminate all download steps from the prescription above, so that once people click the "download WinBoard executable for Windows", and unpack it, they will have the whole toolkit ready and installed. This might include a tournament manager as well (PSWBTM?). It would be very important to mae sure the suppleid components would also work under Linux.

I will hope that the Polyglot gui's author is reading this. I have collaborated with him in the past. He seems a cool enough person. I really hope that he will agree to the bundling.

Most of Winboard's bad mouthing comes from persons who cannot be bothered with editing the ini files etc so perhaps if we are going to do this bundling then we should address the bundling of the following:

(a) Winboard gui
(b) Winboard ini editor
(c) Tournament manager
(d) Polyglot executable
(d) Polyglot ini editor

Perhaps the ini file could be supplied with a list of engines all adressed/located at C:\Engines which would make it easy for someone to edit it with a text editor program (notepad etc.)

H.G., thanks for your input.

Authors of the above programs please respond!

Any other suggestions?

Later.

All that is just fine for me.

Roger please proceed all needed actions when involved people give their agreement.

Besides, a full WinBoard package including all needed tools is indeed a great idea.

Olivier

Roger Brown wrote:Perhaps the ini file could be supplied with a list of engines all adressed/located at C:\Engines which would make it easy for someone to edit it with a text editor program (notepad etc.)

OK, we should be careful here. Specifying an explicit drive might be risky, as people might want to install on a different drive for capacity reasons, or keep a good separation between factory software and downloaded stuff, or simply have the C:\ drive in use for a different OS. (E.g., my Win2k system is installed on F:\)

It might be more generally useful to specify the engine location relative to the WinBoard installation folder. Assuming that the folder containing all engine folders is a sub-directory of the WinBoard folder, as is done in this manual, is in fact not a bad idea at all. For the WinBoard 4.3.14 download I have been assuming that all engine folders would be located directly in the WinBoard folder (hence I put the Fairy-Max and SMIRF folders there), which was already a step forward compared to the 4.2.7 download (which puts the engine executables themselves in the WinBoard folder), but might still not be structured enough.

So from 4.3.15 on, we can build this extra layer of file-system structure into the download, supply the "Chess Engines" folder, put the Fary-Max and SMIRF folders insde it, and change the WB defaults such that the pre-defined engines in the first .ini file it makes assume this structure. We could of course supply it with a pre-existing .ini file that defines far more engines. As all engines would be in sub-folders of the WinBoard folder, there would be no problem in specifying them, no matter on which drive people would install WinBoard, or how they would call its folder.

H.G.Muller wrote:
OK, we should be careful here. Specifying an explicit drive might be risky, as people might want to install on a different drive for capacity reasons, or keep a good separation between factory software and downloaded stuff, or simply have the C:\ drive in use for a different OS. (E.g., my Win2k system is installed on F:\)

It might be more generally useful to specify the engine location relative to the WinBoard installation folder. Assuming that the folder containing all engine folders is a sub-directory of the WinBoard folder, as is done in this manual, is in fact not a bad idea at all. For the WinBoard 4.3.14 download I have been assuming that all engine folders would be located directly in the WinBoard folder (hence I put the Fairy-Max and SMIRF folders there), which was already a step forward compared to the 4.2.7 download (which puts the engine executables themselves in the WinBoard folder), but might still not be structured enough.

So from 4.3.15 on, we can build this extra layer of file-system structure into the download, supply the "Chess Engines" folder, put the Fary-Max and SMIRF folders insde it, and change the WB defaults such that the pre-defined engines in the first .ini file it makes assume this structure. We could of course supply it with a pre-existing .ini file that defines far more engines. As all engines would be in sub-folders of the WinBoard folder, there would be no problem in specifying them, no matter on which drive people would install WinBoard, or how they would call its folder.

Hello H.G.,

I take your point entirely.

However, I suppose that any user savvy enough to partition their hard drive would be able to edit a text file. I suppose I am coming from the angle that users may want to use their engines with several guis - free and commercial - and so might not want to install them in any sub folder.

This largely has to do with aesthetics as C:\Engines is better than C:\Winboard\Engines assuming that the user even installs on the root.

I imagine that the users here have all their engines in a folder with that name and that it has its own sub folder structure of separate engines.

I am not really willing to argue the point however. Getting a ready for use package would make changing a text file (which I did the very first time, I think Leo or Guenther sent me a copy wayyyyyyy back then ) a minor task.

Supplying a pre-existing ini with all the known engines in the Winboard universe would be an excellent thing. The above-mentioned WB personalities - Guenther and Leo (no last names required!) would be good sources for a complete ini file example.

Guenther?

Leo?




Later.

Well, we should be careful not to fall victim to the "maximum-flexibility-minimum-usefulness principle". If you install all existing engines in the .ini file, you should realize that every time the user wants to select one, he will be presented with the entire list...

If we assume that the Engine folder is outside the WinBoard folder, we could instruct the user to install the WinBoard folder inside this folder, just like it was an engine. Then the engines could still be indicated relative to the WB folder, as ..\Fruit\Toga.exe, without having to know the drive or even the name of the engine folder. Disadvantage, however, is that we could not supply any engines with the download that automatically unpack into this engines folder. So the Fairy-Max subdirectory would remain in the WB folder. I guess this would be OK if we consider the WB folder the root of the tree for all variant engines. People will not be able to run those under most other interfaces anyway. (OK, ChessGUI can run some of the 10x8 engines.)

I have no problem with anyone taking the idea, or the actual post itself, of the first posting in this thread and conforming it to what they have in mind. It would really take a rewrite of the post but I have no problems with anyone rewriting it as their own to present things differently.

Graphics were used a lot in the first post, not from the idea of handholding, but the idea of "A picture tells a thousand words".


I am strictly an end-user. I have no computer programming or chess engine programming experience or knowledge. I can click buttons and maybe read instructions, but that is it. So what is written below is from me - an end-user - point of view.


With Winboard's modified versions - Winboard_X and Winboard_F - there exist a problem. The problem is that what might look and work o.k. on my computer, might not do the same on yours.

I have read in a few places that Winboard_X causes problems for people when chess fonts are used as pieces. I have not experienced that problem with the Winboard_X that is on my computer. Maybe if I used Winboard_X on another computer I would have that problem. Now maybe chess fonts aren't that big of a deal but really the reason I use Winboard_X (Heresy I know, but from an end-user point of view) is because I have a nice big chess board with pleasing on the eyes, colors and pieces. I also have a license to several Fritz editions and two Shredder UCI versions, but for playing games nothing, for me, beats Winboard_X visually.

With Winboard_F I can't use it. It isn't that Winboard_F has all of these chess variants and I am a standard chess player with maybe the occasional Fischer Random chess game thrown in from time to time, it is that Winboard_F looks and sets up bad on my computer (end-user), and I can't fix it. Obviously other people do not have the problem with Winboard_F that I do, maybe if I used Winboard_F on a different computer things would be different.


To me the idea of bundling is good in concept but maybe not in practice (my thoughts only). If a person were proficient in what it would take to use such a software bundle - make changes to ini files, etc. Then that same person would have the werewithal to download the software separately and piece it together on their own, or at least have the desire to learn to some degree how to do it on their own. Everyone using Winboard or Xboard on this forum at some point desired to get over the hurdle of - how to do it, however big or small that hurdle was for them.


Is there any guarantee that any Winboard modified version presented in a software bundle is going to look good (I hate to use that word) on the downloader's computer? Maybe concern for such a guarantee isn't needed, and "guarantee" is probably a poor choice of a word on my part.

[I edited out unnecessary information that was here]


Just my thoughts.

But yes, rewrite, make adjustments, changes to the first post as desired.

I just discovered another imperfection:

Using the method described in the first post would require you to keep a separate copy of the Polyglot executable for every UCI engine you install (plus a separate copy of the 1.8MB large cygwin1.dll if you use the wrong Polyglot...). The reason is that the polyglot.ini is not renamed.

The normal way to use Polyglot is to have only one copy of the Polyglot executable, and put one .ini file for each engine in the same directory, using (say) the engine names to distinguish them. So in the directory winboard_x\polyglot you would have the files:

cygwin1.dll (if needed)
polyglot.exe
rybka.ini
fruit.ini
ayito.ini
...

To tell Polyglot which .ini to use, you would start it up with the name of the .ini as argument:

/fcp="polyglot rybka.ini"

The directory given should be that of the Polyglot executable:

/fd="polyglot"

or

/fd="C:\Program Files\winboard_x\polyglot"

if you want to give a full pathname. Officially the line in the start-menu description in the winboard.ini file would have to be:

"polygot rybka.ini" /fd="polyglot"

as WinBoard prefixes this line with /fcp= before interpreting it as command-line options. I agree this does not make it very clear to the user what he is actually choosing. (Of course you could use more elaborate .ini names to improve that a little.) The method above has found an original kludge to solve that problem, by using an invalid, but descriptive name for the engine, and then repeat the /fcp option at the end of the line with the correct name. The execuable name is thus in fact specified twice, exploiting a weakness of WinBoard that it does not notice any occurrence of the same option but the last:

"Rybka 2.2.3" /fd="polyglot" /fcp="polyglot rybka.ini"

H.G.Muller wrote:I just discovered another imperfection:

Using the method described in the first post would require you to keep a separate copy of the Polyglot executable for every UCI engine you install (plus a separate copy of the 1.8MB large cygwin1.dll if you use the wrong Polyglot...). The reason is that the polyglot.ini is not renamed.

What is described as an "imperfection" is just my way of doing things. Nothing wrong with it.

H.G.Muller wrote:The normal way to use Polyglot is to have only one copy of the Polyglot executable, and put one .ini file for each engine in the same directory, using (say) the engine names to distinguish them. So in the directory winboard_x\polyglot you would have the files:

When I made the first posting I did not write it as a "must be followed" it was only intended as a pointer for someone wishing to know how to go about setting up Winboard with an UCI engine. I would expect that once the new learner gained experience that they would do things the way they want. What I have in my setup is the way that I like it - for me.


This remark that I put in the first post could just as well apply to Polyglot too.

Even though I structure it this way and it works for me, I have seen examples where other people structure some things differently than I do and I can only assume that the way they do it works for them.

Charles Browne wrote:

H.G.Muller wrote:I just discovered another imperfection:

Using the method described in the first post would require you to keep a separate copy of the Polyglot executable for every UCI engine you install (plus a separate copy of the 1.8MB large cygwin1.dll if you use the wrong Polyglot...). The reason is that the polyglot.ini is not renamed.

What is described as an "imperfection" is just my way of doing things. Nothing wrong with it.

H.G.Muller wrote:The normal way to use Polyglot is to have only one copy of the Polyglot executable, and put one .ini file for each engine in the same directory, using (say) the engine names to distinguish them. So in the directory winboard_x\polyglot you would have the files:

When I made the first posting I did not write it as a "must be followed" it was only intended as a pointer for someone wishing to know how to go about setting up Winboard with an UCI engine. I would expect that once the new learner gained experience that they would do things the way they want. What I have in my setup is the way that I like it - for me.


This remark that I put in the first post could just as well apply to Polyglot too.

Even though I structure it this way and it works for me, I have seen examples where other people structure some things differently than I do and I can only assume that the way they do it works for them.

I actually do it the same way as Charles does.

Of course keeping only one copy of polyglot.exe may be more aesthetic.

Olivier

I have given H.G.Muller permission via private message to rework the first posting in this thread if he desires. I also asked that if any of the graphics from the first posting were used that they be moved to his server, or another place, so that if photobucket disappears one day, the graphics used in his new guide would not disappear too.

OK, good thinking. I will make a list of all the links and send it to Olivier, so he can upload them to the server. Then I will replace all the links, to make them point to where hOlivier put them.