The compiler which came with Visual Studio 2015 Community Edition didn't work well for chess engines which set the buffer size to zero. For Maverick it meant it couldn't receive any commands via the command line or StdIn. Can anyone confirm this is still the case?
- Steve
I think this was fixed in update 1, not sure...
This problem is not fixed yet.
About half a year ago I reported this problem at Microsoft Connect.
In December I got an email stated that they fixed it and will be released in an upcoming update to the UCRT library.
Recently I acquired about the status of this update and I got this:
Hello,
An updated SDK and Universal CRT redistributable containing this fix should be available later this year. Unfortunately, I don't have a better estimate to share at this time.
Sincerely,
James McNellis
Visual C++ Libraries
Since a day or two there is a new beta release of the UCRT, unfortunately it doesn't install properly and I don't have time to look at it.
jdart wrote:I used to be a Windows-centric developer but now the Windows version of Arasan is a port from the Linux version.
I only use VC++ for debugging, on those rare occasions I need/want a GUI debugging session.
Linux is a much more productive environment if you are a old-style command line user like me.
I do use the command-line MSVC compiler on Windows (the professional version). But I cannot believe just how crippled and horrible NMAKE is, after all these decades. I have been meaning to look into CMAKE, which might make it tolerable.
--Jon
There are several IDE's for linux if you want to have an integrated environment to work in, i.e. a source window, a debugger window, a program input/output window, etc...
The compiler which came with Visual Studio 2015 Community Edition didn't work well for chess engines which set the buffer size to zero. For Maverick it meant it couldn't receive any commands via the command line or StdIn. Can anyone confirm this is still the case?
- Steve
I think this was fixed in update 1, not sure...
Yesterday I installed Windows 10 beta SDK 10.0.14332.0 and voila! the problem is fixed.
Not that it matters much because Visual Studio 2015 works with the v12.0 platform toolset as well.
The only difference is that the v14.0 compiler has better C++11/C++14 compatibility.
That is very strange because Microsoft acknowledged the bug exists.
It has something to do with the number of chars sent and the buffer size.
When the number of chars sent by the other side is 1 larger than the buffer-size the read function blocks, and with buffer-size 0 the read function blocks when there is an odd number of characters sent.
It doesn't throw away characters though, the read function only blocks, this is enough to mess up the communication with the engine.
The bug was actually in the UCRT (Universal C Runtime) that now seems to be part of the Windows 10 OS, when you install VS2015 on Windows 7 or 8 it will separately install the (same?) UCRT.
Joost Buijs wrote:Yesterday I installed Windows 10 beta SDK 10.0.14332.0 and voila! the problem is fixed.
Not that it matters much because Visual Studio 2015 works with the v12.0 platform toolset as well.
The only difference is that the v14.0 compiler has better C++11/C++14 compatibility.
That's cool!
Not only has it better C++11 compatibility, but it also compiles faster and produces faster (and also a bit smaller from I've seen) code, so it's actually win-win-win-win
I looked and I don't actually use read() to get input .. I use the OS call ReadFile, which by-passes the C runtime (or ReadConsole, if the engine is not connected to a pipe). That is probably why I am not seeing this.