I started this a few days ago,I have a bunch of patches ready for compiling on windows. Couple of things to note though:

• This won't build on msvc 2013, there's some C++(11?) use that's just not supported on msvc 2013 (it really disliked the copy constructor on types in a union) , we really can't upgrade this far without first moving to a newer msvc verison as 'standard compiler' and officially dropping 2013.

• I got release/x64/msvc2015 to link, but any osl render crashed instantly

• debug/x64/msvc2015 i got really weird linker errors relating to some missing utf8to16 conversion functions for opencollada (!?) once resolved the final binary wouldn't run at all due to missing imports in the C runtime dll's

This upgrade might not be as easy as it seems on face value.

Given the C++11 requirement, this seems destined for the 2.8 branch (i can't see a way to support it in master where C++11 is still not allowed) so we have some time...

From OSL 1.9.1:

C++11 required: OSL 1.9 requires a minimum standard of C++11. It should also build against C++14 and C++17.

• I got release/x64/msvc2015 to link, but any osl render crashed instantly

Being solved here, assuming it's the issue you found: https://github.com/imageworks/OpenShadingLanguage/pull/810

• debug/x64/msvc2015 i got really weird linker errors relating to some missing utf8to16 conversion functions for opencollada (!?) once resolved the final binary wouldn't run at all due to missing imports in the C runtime dll's

LLVM and OpenCollada contain the same UTF code. In newer LLVM that code has been namespaced, so we should remove the workarounds:
https://developer.blender.org/diffusion/B/browse/master/build_files/cmake/platform/platform_apple.cmake;f4026382116b2fbd93c5f539addd5c03db01892a$219
https://developer.blender.org/diffusion/B/browse/master/build_files/cmake/platform/platform_win32.cmake;f4026382116b2fbd93c5f539addd5c03db01892a$240

Yeah 2013 is officially a nogo, but with the osl 1.9rc1 adding back in support for oiio 1.7, i guess we could do oiio 1.7.17, until we drop 2013 support?

llvm5 is also a no-go for 2013.

Why are we still supporting VS 2013?

2013 worked for us,
2015 had occasional weird codegen issue in cycles, i just don't trust it, so we stuck with 2013.
2017 seems allright, but cuda support kept holding us back, I made D2913 to sidestep that issue and clear the way for an official compiler bump. There's some other minor issues like our boost version is too old to officially support 2017, but it seems happy (even though it's outputting a ton of warnings about this)

I don't see why we couldn't move to 2017 for 2.8

Ok, seems this patch will happen along with an upgrade to VS 2017 then. I'm all for only supporting a single VS version at a time to keep thing simple

Feel free to commit D2913 by the way.

Pushing my luck here, last time i asked @Ton Roosendaal (ton) , the x86 users were around 15% , too early to drop x86 support as well?

As much as I'd like to simplify things, it seems too early with that percentage.

Practically every other 3D app has been 64 bit only for a while now, but for whatever reason the percentage of Windows 32 bit downloads is still high. Maybe only a small subset of those will support the Blender2.8 OpenGL minimum requirements, but that's difficult to estimate.
https://www.blender.org/media-exposure/over-half-a-million-downloads-per-month/

In D2915#69102, @Brecht Van Lommel (brecht) wrote:

Feel free to commit D2913 by the way.

Funny enough, i have some outstanding x86 issues on it, haven't gotten around to resolve those. will take a stab at that tomorrow.

Couldn't get the build fixes in without having so sign legal papers, we'll keep the diff on our side for now.

Why are the include statements in Cycles are changed? Those are supposed to be alphabetically sorted.

oiio now drags in windows.h and glog loses its shit if someone else #defines ERROR first

Poke.

Holding this one off till we drop msvc2013, it's just not worth the hassle.