WinBoard 4.7.0 released (with CCT support!)

[hgm]

Well, you could also change it in the installer when you want them in the same folder, right? The installer proposes a name, and you can change it to anything you like. The package was designed to be installed in the folder where you keep all your Chess engines (where Fruit, Fairy-Max etc. would then also end up in).

Perhaps I should change the proposed name to 'C:\ChessEngines'.

There did not go a lot of deliberation into what name to propose, as it was selectable during install. The C:\Program Files\WinBoard which we had first was a very bad place, however, as the install depends on making some files in the WinBoard folder, and since Vista this would not be allowed in the Program Files sub-tree.

Note that when you install a new version in the same folder as the old, it would be better to un-install the old version first. Otherwise you will never get rid of files that are no longer in use. The 4.7.0 install, for instance, does not create any shortcuts anymore in the WinBoard folder, as the new association with XOP files allows files with settings to serve as shortcuts themselves: you just double-click them, and it should start WinBoard with the settings they contain. You could also drag them on top of WinBoard if you don't want to make the file association (e.g. in a portable install). Because of this change a lot of files previously having INI extension have XOP extension in the new version, and you should get rid of those INI files too.

[hgm]

Yes, I know I can change the name of the installation folder to WinBoard, but that still creates another folder named WinBoard which seems a bit strange as the winboard.exe file will be under ...\WinBoard\WinBoard.

Yes, that is a bit strange. But you could also name it Chess, and then winboard.exe would be in C:\Chess\WinBoard, which would actually be more logical, as Fairy-Max, Pulsar and Fruit (and Shokidoki, HaQiKi D, Elephant Eye) would all be in there as well, and are not per se associated with WinBoard.

BTW, am I right to assume that I cannot have 4.6.2 and 4.7.0 on my disk drive at the same time because they will overwrite each other's setting.ini?

Indeed, they share the same ini file. Which was done to not make you lose any settings when upgrading. (Especially the installed engines.) So if you want them to co-exist, there would be a problem for new options: 4.7.0 would save them, but 4.6.2 would then encounter unknown options. I tried to make WinBoard resistant to that (it used to be a fatal error), by simply ignoring lines that start with an unknown option in ini files. But it still means you would lose their settings after using the old version.

What is worse is that it does not work well enough: 4.7.0 defines a new multi-line option -themeNames (similar to -firstChessProgramNames), so ignoring the rest of the line is not good enough, and the earlier version that does not know it should really have skipped everything to the next }. Because 4.6.2 would not do this, it would read the entire contents of the -themeNames as if they were options, and would most likely choke on that. (And in the best case destroy your entire themes database.) Of course this can be fixed (and should be fixed), but not in 4.6.2, which is by definition what it is.

The alternative would be to give each WinBoard version a separate ini file (e.g. winboard46.ini, winboard47.ini...) and then automatically import the old one before reading the new one. This could be achieved by configuring, by writing at the end of the master ini file something like

/settingsFile= %APPDATA%\oldwinboard.ini
/settingsFile= %APPDATA%\newwinboard.ini
/saveSettingsFile= %APPDATA%\newwinboard.ini

This would cause (every time you start the new WinBoard, as each new install has its own master ini file) the winboard.ini file of the previous version to be read first (if it exist), and then the one for the new version, which would typically completely eclipse it (once it exist, so not the first time you run it). The /saveSettingsFile option would force saving to the new ini file even when it did not exist, thus creating it on the first time use. So the new version would never save something on the old settings file.

This actually seems a good way to handle it. The downside is that it would always try to read the old file first, even when this has become completely pointless because it will be totally overruled by the new one read after it. For efficiency's sake, I guess it would be better to have an option "/backupSettingsFile", which would be ignored if the current save-settings-file name would already be different from the compiled-n default (which is the winboard.ini in the WinBoard folder). In the master file you could then put

/settingsFile %APPDATA%/winboard47.ini
/backupSettingsFile %APPDATA%/winboard46.ini
/backupSettingsFile %APPDATA%/winboard45.ini
/saveSettingsFile %APPDATA%/winboard47.ini

This would first try to read the new settings file, and redirect the saving to it when it existed. Which then would cause the two following options to become no-ops. But if it did not yet exist, it would try to read the file from the previous version, and only if that did not succeed from the version before that, etc. Eventually it would redirect the saving to the new file anyway, protecting the master file and all old files that it might have found and read.

This seems to have no downside at all; it would not even waste time to check if there is an old file if it had already found the new ini file. So I guess we should adapt this system in the future. And to prepare for it I will immediately change the configuration in the current installer to use the slightly-less efficient method, reading both winboard.ini and winboard47.ini.

[Kyodai]

Now we are moving into complicated areas (at least for me)

What is the recommended step if you have WB 4.6.2 and want to install 4.7.0 and keep your installed engines (both Engines folder and the settings
in wb.ini which took quite some work to get right)

afraid to mess things up-regards

[hgm]

You would automatically preserve your settings, (including installed engines) no matter how (=where) you install. The problem we were discussing here is that it would not be easily possible to switch back to using 4.6.2 after you used 4.7.0.

But I uploaded a patched 4.7.0 installer half an hour ago. If you install with that one, you would have no problem to have 4.6.2 (or earlier) and 4.7.0 to co-exist. On first use 4.7.0 would still import all settings from 4.6.2. But after that, they would not see changes in each other's settings (including newly installed engines) anymore.

[hgm]

Well, I think I have to thank you. Your comments are always so wonderfully inspiring!

[JoshPettus]

I just tried compiling winboard 4.7.0 myself from source, (as I only wanted the executable) And got this

Code: Select all

Joshua Pettus@joshpettus-mbp /cygdrive/c/xboard-4.7.0/winboard
$ make -f makefile.gcc
 ../backend.c
../backend.c: In function `InitBackEnd2':
../backend.c:1347: error: `__GIT_VERSION' undeclared (first use in this function
)
../backend.c:1347: error: (Each undeclared identifier is reported only once
../backend.c:1347: error: for each function it appears in.)
../backend.c: In function `HandleMachineMove':
../backend.c:8936: warning: unsigned int format, different type arg (arg 7)
../backend.c:9078: warning: unsigned int format, different type arg (arg 4)
../backend.c:9141: warning: unsigned int format, different type arg (arg 7)
makefile.gcc:88: recipe for target `backend.o' failed
make: *** [backend.o] Error 1

I assume I'm doing something wrong? But I never had issues here before

My OS is XP 32bit if that could be part of it.

[hgm]

No, you did not do anything wrong. I had that error too, but I discovered it only after Arun had already released 4.7.0, and I was in a hurry to release before CCT, so I did not push the fix yet.

The fix is actually in the makefile. Arun added this __GITVERSION business at the last moment, and it is a macro that is supposed to be defined externally by the -D compiler flag. He patched ./configure to do that. But of course WinBoard does not use ./configure to produce the makefiles, it comes with its own makefiles.

What is needed is to add -D__GITVERSION='""' to CFLAGS, in the line

CFLAGS = $(CF) $(ARCH) $(OPTS) $(CFCYG) -D__GITVERSION='""'

of makefile.gcc. Note the nested quoting, which is needed because the shell strips off the outer quotes of anything on the compiler command line, and you want to end up with the C notation for an empty string.

Most people building WinBoard will get another error too, in building the winboard.hlp file, which then aborts the process. Because building that requires a MicroSoft utility (the 'help compiler') they have not installed. to cure that, you have to remove $(PROJ).hlp from the dependency list of $(PROJ).exe. I.e.

$(PROJ).exe: $(OBJS) $(PROJ).hlp

becomes

$(PROJ).exe: $(OBJS)

[JoshPettus]

Thanks, I knew about the help utility and have it installed. It's really old and rather hard to find though

[jshriver]

Going to grab this for my windows machines.

While I love your ICS and your WB builds, one problem I've had, trying to run Windows based engines on my 2 Windows 7 machines, is that Winboard seems to timeout, or disconnect after X.

Despite setting the idle variable very HIGH.. like 9999999 or whatever was the max for the variable.

Yet I still have that bug. Timeout issues never seem to present themselves when I run my various icsdrone engines.

----------------------------------------------------------------------------------

Rant over, I only experience this with long time controls. With lightning/blitz they are ok. So it seems it's a timing/idle/bug.

For private engines, I run a "who" every 15 minutes to get around that, a sort of "ping I'm here". But for winboard engines not sure if that is a possibility, without writing some kind of xboard or uci passthru program that reads/writes i/o while keeping timing to do a random who at x-interval.

Anyway, not sure if it's just me, but granted I tend to test 18-24.. heck now 28 engines at any given time. It is some food for thought.

Gladly willing to test or send and i/o or engine, or ics, or whatever info out there into the comp chess ether

-Josh

[hgm]

There is nothing in WinBoard or my ICS code to cause this behavior. (Apart from the regular idle time-out of the ICS, which on the Variant ICS I have set to 10 hours.) Other people have complained about it too, however. I think it is just network instability; your connection must pass through some hub that makes connections that have not been used recently 'fade away'.

WinBoard has a -keepAlive N option, which makes it send a 'date' command to the ICS every N minutes. This was mainly intended to thwart the ICS timeout (which on FICS or ICC is just 1 hour), but it might also help against the network instability. The complaint by people suffering from this was that the 'date' command was not silent, and that using it every minute would flood them with distracting ICS output. So they wanted an empty line to be sent. But the ICS code I have would not reset the time-out clock when receiving empty lines; they need a command for that. Empty lines they just ignore. (But it did seem to help them against the network instability.)