Win64 build of 0.19.0-Beta3

For building 0.19.0-Beta3 with VS2017 for the x64 platform I had to define WIN32 in order to prevent the inclusion of sys/time.h.
Is this save or should I expect side effects?

Forums: 

LibRaw's Makefile.mscv also

LibRaw's Makefile.mscv also defines WIN32:
COPT=/EHsc /MP /MD /I. /DWIN32 /O2....
(while Makefile.mingw is not)

This is the way we distinguish native win32/VisualStudio build environment from emulated linux-like one (with time.h and other posix calls)

-- Alex Tutubalin @LibRaw LLC

Does this mean that

Does this mean that applications should also #define WIN32 before including libraw.h? At least for x64 builds this might not be the case by default.

Erwin

Yes, you need it in app too.

Yes, you need it in app too.
WIN32 does not means 'not 64 bit'.

Please note, that WIN32 and _WIN32 are not the same. _WIN32 is defined in both MS and MinGW/Cygwin compilers. BTW (old versions of) MinGW does not support unicode filenames. So, to use open_wfile() call (needed if you wish to support non-native-locale filenames) you need to define WIN32 macro.

-- Alex Tutubalin @LibRaw LLC

Thank you for the explanation

Thank you for the explanation. I'm aware of the difference between WIN32 and _WIN32, but this use seems a bit irritating. Why not using _MSC_VER or some _MINGW macro to identify the compiler?

Windows compilers are not

Windows compilers are not limited to MSVC/MinGW (Intel, clang /very different flavours on Windows/, PGI, Wacom....).
Although most compilers *should* mimics to some of mainstream ones, I'm not sure they really does it (right way and in all versions)

So, WIN32 is defined manually while building LibRaw to indicate that Win32-like environment is present.

We're open to patches: if someone wants to accurately replace #ifdef WIN32 to something better (to work automatically with most common compilers), we'll happily use this patch (too late for 0.19, but in future version)

-- Alex Tutubalin @LibRaw LLC