Linux friendly engines at all levels

[mvanthoor]

I think that if you take care not to use Windows-specific things in an engine, any engine should be able to run on Linux.

Actually, it's 'best' (IMHO) to write an engine as if on Linux, even if you're running on Windows. If you compile with GCC or Clang under MSYS2 and it works, it should compile on Linux. If you wriite your engine in Visual Studio and/or use Visual C++, you may have problems compiling the engine with GCC or Clang on Linux later.

Personally, I have never written an embedded piece of software or a command-line program using Visual C++; I've always preferred GCC under MSYS2. I don't have a lot of experience with Clang, but I assume that if a program compiles under Clang in MSYS2, it'll compile in Linux, assuming one is not deliberately doing Windows-specific stuff.

[hgm]

In my engines reading the clock is typically platform dependent. I would not know how to do it in a way that works both on Windows and Linux. Things like shared memory (between processes) also need platform-dependent system calls.

[Joost Buijs]

In my engines reading the clock is typically platform dependent. I would not know how to do it in a way that works both on Windows and Linux. Things like shared memory (between processes) also need platform-dependent system calls.

With a modern C++ compiler (C++11 and later) you can use the <chrono> header, this should be platform independent. For shared memory between processes you still need an external library like boost (or to write your own code).

Why do you want to use processes for a chess engine anyway? Nowadays C++ has a pretty platform independent thread-library, very convenient to use.

[mvanthoor]

In my engines reading the clock is typically platform dependent. I would not know how to do it in a way that works both on Windows and Linux. Things like shared memory (between processes) also need platform-dependent system calls.

Something such as GCC on MSYS2 can compile software that uses POSIX-threads to run on Windows. I assume that almost anything that uses POSIX-compatible system calls on Linux can be compiled under MSYS2 for Windows, as MSYS2 is designed for that. (MSYS2 is started as a fork of Cygwin, but in such a way that it doesn't need the external library cygwin1.dll.)

And, as Joost says, there are options in C++11, and in Boost as well; probably not in bare C. (I wouldn't know: I've cheated a lot in the past by writing "C++" programs that were basically C programs that used the C++ Stdlib and Boost...)

[IanKennedy]

I think that if you take care not to use Windows-specific things in an engine, any engine should be able to run on Linux.

Actually, it's 'best' (IMHO) to write an engine as if on Linux, even if you're running on Windows. If you compile with GCC or Clang under MSYS2 and it works, it should compile on Linux. If you wriite your engine in Visual Studio and/or use Visual C++, you may have problems compiling the engine with GCC or Clang on Linux later.

Personally, I have never written an embedded piece of software or a command-line program using Visual C++; I've always preferred GCC under MSYS2. I don't have a lot of experience with Clang, but I assume that if a program compiles under Clang in MSYS2, it'll compile in Linux, assuming one is not deliberately doing Windows-specific stuff.

I'm currently working in VIsual Studio 2019 and cross-compiling and testing in Ubuntu/gcc once a day to ensure its still 100% portable. I don't want to waste time testing something in Windows that I'm going to have to bin because it won't port.

[hgm]

With a modern C++ compiler (C++11 and later) you can use the <chrono> header, this should be platform independent. For shared memory between processes you still need an external library like boost (or to write your own code).

Why do you want to use processes for a chess engine anyway? Nowadays C++ has a pretty platform independent thread-library, very convenient to use.

My engines are not written in C++. And my C compiler (3.4.4) does not support C++11.

I only have one engine that uses SMP, and using processes was a simple way to implement it without extensive changes to the code. With threads I woud have had to split up all global variables (such as board and piece list) into arrays, so that each thread would have its own instance. That would have been a lot of work, and I only had 10 hours to do it. (The duration of a flight to Japan.) It was much simpler to just change the function that allocates the hash table to one that allocates shared memory, and fork off multiple processes all using that memory for hash table.

@mvanthoor - I am using gcc under Cygwin, and there you can use POSIX functions too. But then your program can only run on machines that have the Cygwin1.dll installed. Which is not standard, so you would have to distribute it with your engine. And it measures about 2MB. I like to distribute my engines as single (~40KB) executables, without users having to install all kind of libraries. So I just use the Windows API.

[Ras]

probably not in bare C.

C11 has threading support with the goal of being compatible with C++11 - minus templating of course.

And my C compiler (3.4.4) does not support C++11.

It's not like GCC costs money, so updating it after 15 years doesn't sound too far-fetched.

For my engine, I'm using C99 without threading support, but I encapsulate the platform specific stuff and use some ifdefs. Compared to using Posix functions via MingW (no Cygwin DLL), the Windows executable size shrinks by some 30kB, and I can look up the Win API directly to be sure what I'm doing.

[hgm]

The problem is that later Cygwin GCCs stopped supporting the -mno-cygwin option, so that they were of no use to me.

[Ras]

The problem is that later Cygwin GCCs stopped supporting the -mno-cygwin option, so that they were of no use to me.

If you use the Win API anyway, then I don't see the point in building Windows applications with Cygwin. If you don't want to set up MSYS2, you can either use a ready-made GCC-MingW, unfortunately only available up to 8.1.0, but that's already a lot more recent.

https://sourceforge.net/projects/mingw-w64/files/

Alternatively, Clang-MingW is also there:

https://github.com/mstorsjo/llvm-mingw/releases

Both can be plugged in right into a build chain without additional fuzz.

[hgm]

When I started compiling C on my PC MSYS2 did not exist yet. I liked Cygwin because it provided a Linux-like environment. (I use commands like grep a lot.) But MSYS2 does that too, doesn't it? On my laptop I now use MinGW, because the anti-virus software removed Cygwin. But then I cannot use the Makefile for building WinBoard, which sort of renders it useless. If I re-install Cygwin gcc 3.4.4 is no longer in the menu...

Otherwise I usually work according to the principle "if it ain't broken, don't try to fix it!". In my experience newer versions are usually worse. Ubuntus became inacceptable after 10.04, so I am still running that for Linux.