World Championship Winning Computer Chess Software Program & Downloads for Chess Databases, Analysis and Play on PC, Mac, iPad and iPhone — Visit: Hiarcs.com
This is not yet another question about whether or not I can use these engines only to be told no. I already know the answer and, as I hinted at in a previous thread, the answer is yes.
There are certain limitations, a number of system requirements and absolutely no guarantees or, of course, support. That said, this is how it is done.
Step 1: Install Wine or CrossOver for OS X. The two most common methods of installing Wine are using Homebrew (which I don't use because it conflicts with other development platforms I use) and Mac Ports (which I do use because it confines itself to /opt/local and doesn't interfere with anything else). You will also need the XCode development platform with the command line tools and the GNU libraries (gcc, g++, etc.).
Step 2: Use Wine to install Arena. There are two reasons for this: First, to test that the Windows engines behave themselves when they are accessed by a Windows interface, even if that interface is being run through Wine. The second is that Arena still has a few features which Chess Explorer does not have (yet).
Step 3 (optional, but advisable): Test the Windows engine in a Terminal using wine and/or "wineconsole --backend=curses" to be sure that it is not adding anything weird to the input or output on the command line. A passing familiarity with the UCI protocol is advisable here.
Step 4: Create a mach-o executable wrapper for Wine and the chosen engine. This can be done in C, C++ or Objective C (Cocoa). My successful test, which I'm using as the example here, utilised C++ and Dragon 4.6.
#include <stdio>
#include <stdlib>
int main()
{
system("/opt/local/bin/wine /Applications/Games/Chess/UCIengines/Dragon/Dragon_46.exe");
}
If you installed Wine using homebrew or installed it somewhere else then you will need to update the path for your installation of Wine. If you're keeping your chess engines somewhere else (e.g. in your Documents folder) then you will need to update that path too. I recommend using full paths rather than relative ones so that you can place the compiled binary wherever you want.
The compiled file can then be added to Mac Chess Explorer in the same manner as any native UCI engine for OS X.
Following my successful test with Dragon, I set it against Stockfish 5 (single core, precompiled binary) and then against HIARCS 14 WCSC (the single core version), it lost every match, but it was definitely playing.
This process should work for any UCI engine which consists of a single folder with a single .exe file (the engine) plus various support files (e.g. an opening book, other tables, configuration files, etc.). It should be perfectly fine with the engines provided with Arena. I'll update this topic with confirmation of successes or failure with those engines when I test them. I'll also post some engine matches with the ones that work.
Unfortunately my attempts to use the same method with ProDeo 1.88 have failed so far, the reasons for which require further investigation and will need to wait on other projects (it could be the additional .exe files, the multiple subdirectories, the response codes I noted in the wineconsole tests or something else entirely). Chances are a solution for ProDeo will require considerably more code to create the mach-o wrapper and may or may not be a rather complex task. A pity since I pursued this in order to specifically get ProDeo working with Mac Chess Explorer ... oh well, ces't la vie.
It should go without saying, but I know better than to leave this last bit unsaid: this method of using Windows UCI engines with Mac Chess Explorer comes with no warranty, no support and no guarantees. Don't expect the HIARCS team to support it or the developers of the Windows engines to do so either. As for me, I'm posting this for informational purposes only; if it works for you, that's great, but if it doesn't, well, you've lost nothing really.
If it does work for you, though, I would be interested in hearing of it.
Rybka failed slightly spectacularly. The 64-bit version was not recognised as a UCI engine at all. The 32-bit version was recognised, but upon trying to launch an engine match it generated a rather nasty page fault in kernel32.dll. This means that if it had been a real Windows system there would have been a BSOD and a reboot.
The failure of the 64-bit rybka engine is an expected result since Wine simulates a 32-bit Windows environment and thus cannot use any of the 64-bit Windows engines.
The 32-bit version of Hermann 2.8 works. I'll post the match against HIARCS later, it's still in progress and Hermann is giving a very good account for itself.
Ruffian appeared to work at first, but after eleven moves it unexpectedly quit following some kind of significant error. It did not, however, crash as happened with Rybka.
Like Hermann and Dragon, Nejmet works, but it still had serious trouble in the games against HIARCS 14. Still, a success here is completing the engine matches, which Nejmet did.
In spite of the name indicating it is solely for Arena, SOS 5 works fine with HCE and a C++ wrapper. Like the others it had trouble with the matches against HIARCS, but that was more to do with the games than the software.
Then I made a little error and instead of running the next two matches for Spike 1.4, I ran two more for SOS 5 again. I may as well include them, especially since the second of that pair was a draw between SOS 5 and HIARCS 14.
This was a shame given the previous clashes between Spike and HIARCS. This crash was more like that of Ruffian than that of Rybka, but it was still serious enough to prevent anything continuing.
Houdini 3a Pro well and truly works. I have four instances of it loaded; one with the default configuration (which uses 8 threads even in the 32-bit version), one wth the tactical mode enabled, one with learning mode enabled and the last with both tactical and learning modes enabled. I am still in the process of determining precisely where it sits in regards to strength and in comparison to the other engines, but wherever it is, it is certainly well situated.
HIARCS 14 did not fare well this time around, but there are still tests of Deep HIARCS and Stockfish to go. This is the results of HIARCS 14 vs. Houdini 3a Pro w32, I may post the results of some of the other games later, though probably not all of them.
I've had the opportunity to test the 32-bit version of Houdini 4 Pro in addition to Houdini 3a Pro. As far as my little trick to bring it to heel on OS X is concerned, it is just as responsive as its predecessor and like 3a I have default, learning, tactical and combined tactical and learning instances active.
I also have another four of those instances that are configured to use the syzygy endgame tablebases, though I have yet to test them at all. Configuration for the syzygy tablebases is in the engine congiguration parameters rather than a setting in Chess Explorer, as with the Nalimov tables. Hopefully Mark will include support for syzygy tables natively in HCE at some point in the future since they do save a lot of space to provide that function. Especially for those people who want to run 6-man tables on site, though personally I think 5-man at home and 6-man or even 7-man online is good enough for me.
Anyway, on with the results of HIARCS 14 WCSC vs. Houdini 4 Pro w32 and some somewhat surprising results:
And there's a draw, compared to the previous total losses. In addition to all this, there have been some other indications during other testing that Houdini 3a really is stronger than Houdini 4. A little weird, but there you go. I will, of course, be testing this further and seeing how Houdini in its various forms handles Stockfish.
If you would let your wrapper read the string it feeds to system() from a file with a fixed name (say wrapper.ini) in the current directory, people could use it without comiling anything. They would only have to prepare an ini file with the wine command in it. Of course you could have the wrapper also supply the path to wine by itself and just read the path to the engine from the file. Or, to accomodate even more lazy users, let it construct the engine path from the current directory and the .exe name read from the wrapper.ini file.
h.g.muller wrote:If you would let your wrapper read the string it feeds to system() from a file with a fixed name (say wrapper.ini) in the current directory, people could use it without comiling anything. They would only have to prepare an ini file with the wine command in it. Of course you could have the wrapper also supply the path to wine by itself and just read the path to the engine from the file. Or, to accomodate even more lazy users, let it construct the engine path from the current directory and the .exe name read from the wrapper.ini file.
You would only have to distribute the (OS X) binary for this.
I guess we should include such a generic wrapper for Windows engines in the XBoard Mac App too.
This is a brilliant idea. Unfortunately that sample code there didn't compile for me, but I may be able to cheat my way around such problems with the aide of Python and Cython (i.e. write it in the language I know best and convert that to C to make the binary).