1) I've installed Winboard v.4.9.1 on Win 10 x64 v. 10.0.16299.334.Winboard v.4.9.1 (from this forum) seems to be the last available version, but indicates 2015 (3 years before), although XBoard is moving on and on.Does Winboard's development has been stopped?I'm facing some problems and I think that's not strange, considering the colossal changes in Windows world.

2) Winboard comes with Fruit, but I wanted to use StockFish. (Stronger and up to date).Apparently Winboard doesn't any more seems to be happy with it.Does someone else succeded using StockFish? (at Win 10 Fall Update).

3) Trying to setting up a position, was a nightmare here!Any success with it?

Almost all changes in WinBoard 4.9 (compared to 4.8.0) only affected XBoard, so I never bothered to release it as a WinBoard version. Which was just as well, as v4.9.0 turned out to have introduced a bug w.r.t. e.p. capture. The latest development version of WinBoard is available as a beta release ( http://hgm.nubati.net/WinBoard-AA.zip ).

The purpose of the WinBoard binary install is not to distribute engines; Fruit was only included as an example of a working UCI engine. Unlike Fruit, Stockfish is still under development, so including it would only lead to complaints that it was not the latest version that was included. Unless I would update the WinBoard package every week, which I have no intention of doing. Plus that most Stockfish compiles would not run on most computers. The WinBoard-AA package does include a (by now quite old) version of Stockfish as a 32-bit compile, which takes a big hit in strength in comparison with any state-of-the-art 64-bit compile, but has the advantage of running on all hardware.

A GUI would be of little use to people that do not know how to install new engines in it. Any included engine would sooner or later become obsolete, and would have to be upgraded to a newer version. Just download the engine you want to use, and install it somewhere on your disk (usually by unzipping some archive). Then use the WinBoard 'Load Engine' dialog to navigate to the .exe file you want to use, indicate whether it is UCI or not, and you should be done.

What I consider by far the most convenient way to set up a position is to summpne the 'piece-palette' position (which contains one copy of every piece type), by clicking the 'active' (black background) clock twice. And then dragging the pieces to their desired position, throwing away types that you don't need by dragging them off board (or dragging an empty square, or just another piece, on top of them). If multiple pieces of the same type are needed you copy instead of move, by keeping Ctrl pressed while you drag (or 'grab' the piece with a double-click rather than a simgle press).

Only for very sparsely populated boards it would be easier to start from a completely empty board (which you get after clicking the clock once). You can drop pieces on it by right-clicking the square you want to drop on. A static click drops a Pawn there (a black one if you keep Shift pressed during the click). Other pieces can be obtained by moving the mouse between the button press and release; just release when you see the piece you want. You can also 'upgrade' a dropped Pawn to another piece type by repeatedly right-clicking it. (This could be easier with touch-pad devices, where making a non-stationary right-click sometimes is awkward.) When each side has 3 or fewer pieces, this can be faster.

If you don't like this 'sweep selection' of the dropped piece, you can reconfigure WinBoard to pop up a menu from which you can select a piece type, after right-clicking a square. Just run WinBoard once with 'Additional option' -pieceMenu true .

1) I didn't know that recent XBoard development was Linux specific.I'm still at Debian Jessie (oldstable), and due to a known bug, Xboard can't be neither installed from repositories nor compiled from source (so wasn't informed for latest development).Arena is an alternative solution, but personally I prefer to reboot at Windows and running Winboard.Of course there's no reason for updates, if there's no Windows specific improvements.

2) a) For the 32-bit binary, I agree that compiling Winboard as a x64 binary won't get big performance improvements. More important is the backend chess machines (eg. StockFish) to be x64, so you'll gain the most out of your machine strength.

b) In a more theoritical approach, x32 applications can't natively run at x64 Windows, so SysWow64 comes to play.SysWow64 being a compatibillity layer, I think it adds more complexity and performance loss.Being invaluable for running older apps (mainly games), I think it may be avoided for running serious programs.And as it's predecesor NTVDM, can be retired from MS at any time, as NTVDM retired without further explanations.My personal thought is, that at future we'll need an x64 binary.

3) For the editing position problem:a) Trying the right-click sugested methods, is what I already tried and only drived Winboard to crash here. Maybe a bug?

b) Adding at shortcut the "-pieceMenu true" argument, did the trick!!!

Please let me test it for a while and I'll be back.THANKS AGAIN!!!

EDIT:

4) I tested Stockfish v.9 x64 POPCNT and seems to work perfectly.

5) The only thing that didn't work for me so far, is sounds.

The Options -> Mute all Sounds option is deselected, but the Options -> Sounds... is greyed out.

GiorgosK wrote:I'm still at Debian Jessie (oldstable), and due to a known bug, Xboard can't be neither installed from repositories nor compiled from source (so wasn't informed for latest development).

That is strange; I develop on a very old Ubuntu (10.04), which also is a Debian system, and I have no problems to build from source there (obviously). Have you tried to build a version directly taken from git? (From the repository ar GNU Savannah or http://hgm.nubati.net/cgi-bin/gitweb.cgi ?) You would have to start with the command "./autogen.sh" for those, before the usual "./configue; make; sudo make install".

2) a) For the 32-bit binary, I agree that compiling Winboard as a x64 binary won't get big performance improvements. More important is the backend chess machines (eg. StockFish) to be x64, so you'll gain the most out of your machine strength.

Indeed, for the engine it is important to exploit the newest architecture features, such as x64, popcnt, bmi... WinBoard itself hardly puts any load on the machine, so there is not much to gain there. In principle the WinBoard source code is 64-bit compatible. But I don't have a 64-bit compiler myself, and a 64-bit wnboard.exe would not run on olde 32-bit machines, so that I would have to host multiple binaries. It does not seem woth it.

My personal thought is, that at future we'll need an x64 binary.

Well, I am sure there are Windows users that could make such a compile. I guess I would abandon Windows altogether in that case; the latest versions of that are hard to stomach anyway. Unfortunately the same thing is true for Ubuntu. (Which why I am still using 10.04 .)

3) For the editing position problem:a) Trying the right-click sugested methods, is what I already tried and only drived Winboard to crash here. Maybe a bug?

Let me get this straight. When you select Edit Position, and then right-click a square, WinBoard always crashes? I have never seen or heard of that. For me (with the WinBoard-AA version) it just creates a white Pawn in the clicked square.

b) Adding at shortcut the "-pieceMenu true" argument, did the trick!!!

Note that this also suppresses the possiblility to 'clear the board' by clicking the clock, but that you still can summon up the piece palette by selecting 'clear board' twice from that pop-up menu.

5) The only thing that didn't work for me so far, is sounds.

The Options -> Mute all Sounds option is deselected, but the Options -> Sounds... is greyed out.

Sounds should be greyed out only if you don't use an engine or ICS mode.

H.G.Muller wrote:Have you tried to build a version directly taken from git? (From the repository ar GNU Savannah or http://hgm.nubati.net/cgi-bin/gitweb.cgi ?) You would have to start with the command "./autogen.sh" for those, before the usual "./configue; make; sudo make install".

They passed ~2y. since my last try and I'm sure (because I asked) that backporting it to Jessie, has also failed (and abandoned).Let me retry and I'll be back.

H.G.Muller wrote:I guess I would abandon Windows altogether in that case; the latest versions of that are hard to stomach anyway. Unfortunately the same thing is true for Ubuntu. (Which why I am still using 10.04 .)

For similar reasons I'm still on Debian's oldstable, while (after many years, I'm searching for an alternative distribution).Specially after SystemD adoption, we had a kind of a civil war and a vast number of developers abandoned the ship.Me myself, I'm just waiting for the dust to settle down, while looking at SystemD-free distributions or even classic Unices.In any case, after such a type of incident, I'm sure that there are darker days ahead.

H.G.Muller wrote:When you select Edit Position, and then right-click a square, WinBoard always crashes? I have never seen or heard of that. For me (with the WinBoard-AA version) it just creates a white Pawn in the clicked square.

It just didn't work for me, but I didn't try the AA version.Let me try with this version and I'll be back.

H.G.Muller wrote:Sounds should be greyed out only if you don't use an engine or ICS mode.

I can recall that (when using an engine, playing against it, or at 2-engines mode), I could enable sounds that way, so after a move a click sound could be heared,

Well, it seems that Ubuntu 10.04 ('lucid') under which I develop XBoard is based on Debian 'squeeze', which by now would be old-old-oldstable, two generations before 'jesse'. So it should not be so much an issue of 'backporting' as well as modernizing it. But as I never received any compatibility complaints from Debian for their more recent suites that feature XBoard, I don't expect any problems at all. Problems are to be expected when GTK 2.0 would be no longer supported.

The sounds are only used in ICS mode or (for the 'move' sound) with an engine. WinBoard has always greyed out functions in game viewer mode that you would not need there (e.g. Time Control). This has always seemed a bit pedantic to me, as these settings are persistent, so that it seems legitimate that you want to set them for future use, independent of what you happen to be doing at the moment. But I never took the effort to change it. It seems many people consider being patronized by their software as a hallmark of user-friendliness...

Indeed, this can be pretty convenient. I think in the latest version I even made it possible to use the move sound in analysis mode when a new PV comes in, after a certain time. It really annoyed me when I was analyzing 4 positions simultaneously, that I had to constantly call them to the foreground to see if they had already reached the desired depth.