I/O issues in mingw due to _MSC_VER misuse

[letmaik]

The following conditionals are essential on Windows, however since _MSC_VER is used instead of _WIN32 this will break on gcc within mingw64. It would be good if these could be fixed. By the way, I saw you use Appveyor but don't run any tests, just compile it. And you already make use of MSYS's cmake within Appveyor. Why not extend it for building under mingw and running tests there?

netcdf-c/libdispatch/ddispatch.c

Lines 80 to 84 in c844e5b

	#ifdef _MSC_VER
	tempdir = getenv("TEMP");
	#else
	tempdir = "/tmp";
	#endif

netcdf-c/libdispatch/dfile.c

Lines 2522 to 2526 in c844e5b

	#ifdef _MSC_VER
	file->fp = fopen(file->path, "rb");
	#else
	file->fp = fopen(file->path, "r");
	#endif

netcdf-c/libdispatch/dutil.c

Lines 171 to 175 in c844e5b

	#ifdef _MSC_VER
	stream = NCfopen(filename,"rb");
	#else
	stream = NCfopen(filename,"r");
	#endif

netcdf-c/libdispatch/dutil.c

Lines 240 to 244 in c844e5b

	#ifdef _MSC_VER
	fd=NCopen3(tmp,O_RDWR|O_BINARY|O_CREAT, _S_IREAD|_S_IWRITE);
	#else
	fd=NCopen3(tmp,O_RDWR|O_CREAT|O_EXCL, S_IRWXU);
	#endif

[DennisHeimbigner]

The case you need to consider is Cygwin. It defines _WIN32, but unlike mingw,
is linux based. This means that the various windows specific features are not available.
This is why we use _MSC_VER. You are saying that mingw uses e.g. windows.h
as does visual studio, but not cygwin. If correct, then the proper solution is to
use something like this
#if define _MSC_VER || defined _MINGW
(or whatever is the mingw system flag).

[DennisHeimbigner]

Now, I am not sure what is up.
I just did a test to see if gcc under cygwin defined _WIN32|_WIN64
and the answer is that it does not. This seems to conflict with my previous
experience. So maybe we can use _WIN32 instead of _MSC_VER.

[DennisHeimbigner]

Superceded by #1108

[WardF]

@letmaik

By the way, I saw you use Appveyor but don't run any tests, just compile it.

For some reason, attempting to invoke the tests either in whole (via ctest, or cmake --build . --target RUN_TESTS, and with various options) or one at a time simply results in a hang that eventually times out. It would be great to run the tests and I will take another look at this. At the time, I spent a couple days messing with it in my spare time before concluding that maybe it was a system problem and I would come back to it later. I'll take a look and see what happens if we re-enable the tests on Appveyor and if they now work as expected.