Windows

[rvagg]

I'm making an issue here mainly to collect names of people who can legitimately help with making Windows a first-class citizen. It's such a different beast that it really requires people who spend their time in it and understand the ecosystem rather than drop-ins (like me) who make do with their historic knowledge and occasional googling.

Examples of things that we need people for:

1. We're heading in to a place where we can only build with C++11 capable compilers, which is only MSVC 2013 on the official end (and 2015 when it's properly released). What are the implications of this for Windows build platform support (currently I only have Windows 2012 in the node-forward build cluster) and what are the implications for our ability to produce binaries that support older versions of Windows?
2. There has been some discussion of moving to clang at some point but apparently it's not quite "ready", is anybody following this? Do we have any clue about our ability to even start testing with it?
3. Fixing minor bugs in core and keeping the test suite solid and relevant for Windows. Consider the test-cluster-eaccess.js example--originally implemented for non-Windows only but was then expanded to work on Windows but tested something completely different on Windows because of the nature of named pipes. It has since been changed in io.js but only because it was noticed while tracking down unrelated problems.

[seishun]

I'm not an expert, but I do use Windows and care about its support. So you can count me in as someone who would be interested in diving deep to figure out a Windows-specific issue.

[bnoordhuis]

There has been some discussion of moving to clang at some point but apparently it's not quite "ready", is anybody following this? Do we have any clue about our ability to even start testing with it?

I follow clang development quite closely but I haven't actually tried to build node with it yet. I speculate that clang HEAD is compatible enough with MSVC now that a build would need only minor tweaks. The biggest barrier is having to build clang from source.

@seishun If you're up for adventure, you could give that a try.

[seishun]

@bnoordhuis LLVM already provides a binary for Windows, so no need to build it from source. Building node on Windows using clang would certainly be a challenge, but what's the purpose? Surely you're not meaning to drop Visual Studio build support?

[Qard]

The challenge is that, with C++11 features in V8, the support versions of Visual Studio is limited. Many developers still use older versions of Visual Studio and don't want to upgrade. More still don't even have it installed, and getting it set up properly is pretty awkward for someone not familiar with it. (Needs extra stuff for x64, etc)

By building with clang, we don't have to care what version is installed, or that they even have Visual Studio. I believe the need to build from source is just to catch the latest Windows support features. Support for Windows is pretty new--I'm not familiar enough with it to know if current releases lag behind some important features, but it seems like that could be the case.

[seishun]

Many developers still use older versions of Visual Studio and don't want to upgrade.

Why should we cater to such developers? It's not like they can't use node without building it from source.

[Qard]

It's native modules where clang is really needed. Some total newbie to node probably isn't going to be building node from source, but there's a good possibility of them trying to install something with npm that has native code in it and it blowing up at them for not having the right Visual Studio with everything in the right place.

Presently, native modules are built on the user end, which means a compiler must be available. There has been discussion about npm building and delivering built binaries in the future, but that'd take very significant effort.

[bnoordhuis]

Building node on Windows using clang would certainly be a challenge, but what's the purpose?

Several reasons:

1. We wouldn't have to work around VS bugs anymore. Of the three major compilers we support, VS is the buggiest one by a wide margin; it's certainly the least compliant when it comes to C++11.
2. Like @Qard said, it would help immensely with native add-ons. In order to build add-ons with clang, node needs to build with clang (or at least, its public headers should.)
3. Longer term, I expect Chromium (and therefore V8) to switch over to clang. I'm not sure if they would drop VS support completely (maybe not for development) but it probably won't have tier 1 support either.

Apart from IDE support, and assuming good enough ABI compatibility, are there any downsides to moving to clang?

[seishun]

We wouldn't have to work around VS bugs anymore. Of the three major compilers we support, VS is the buggiest one by a wide margin; it's certainly the least compliant when it comes to C++11.

It's going to improve. VS2015 isn't far away and it's going to get significantly closer to C++11 compliance. Also, which VS bugs and missing C++11 features are you concerned about, besides constexpr and extended sizeof?

Like @Qard said, it would help immensely with native add-ons. In order to build add-ons with clang, node needs to build with clang (or at least, its public headers should.)

Now that's a valid issue. But what prevents addons built with clang from working with node built with VS?

Longer term, I expect Chromium (and therefore V8) to switch over to clang. I'm not sure if they would drop VS support completely (maybe not for development) but it probably won't have tier 1 support either.

If that does happen then I'll agree with you. But I don't see any reason to drop VS support before V8 does.

Apart from IDE support, and assuming good enough ABI compatibility, are there any downsides to moving to clang?

I imagine most Windows developers are likely to have VS installed, not so with clang and whatever build system that would be used. Also, the convenience of IDE should not be taken lightly. Personally, I would be quite disappointed if I could no longer use Visual Studio to work with node's code.

[Qard]

Devs that write native code would probably have VS installed. But there's a huge number of frontend devs, using node for tooling, that don't write native code and thus probably don't have VS installed.

There are core devs hacking on node from Windows, so I doubt VS support would ever be removed, it'd just not be the default.

Also, I think the intent might be to ship clang, pre-built, alongside node in some installer. So you'd just run the installer and not have to concern yourself with installing a particular version of compiler to get native modules to work.

[seishun]

Devs that write native code would probably have VS installed. But there's a huge number of frontend devs, using node for tooling, that don't write native code and thus probably don't have VS installed.

Sure, but we're talking about building node itself. Front-end devs are unlikely to want to do that.

There are core devs hacking on node from Windows, so I doubt VS support would ever be removed, it'd just not be the default.

Supporting two build systems on Windows sounds like a huge pain.

Also, I think the intent might be to ship clang, pre-built, alongside node in some installer. So you'd just run the installer and not have to concern yourself with installing a particular version of compiler to get native modules to work.

That would be great. So it boils down to whether we can get clang-built addons to work with VS-built node.

[smikes]

names of people who can legitimately help with making Windows a first-class citizen

I've done devel work on windows and would like to help.

That would be great. So it boils down to whether we can get clang-built addons to work with VS-built node.

I can look into this. Offhand I would guess that insofar as C++11 requires new name mangling, they will be hard to reconcile unless there is explicit collaboration between the compiler author groups.

[springmeyer]

@rvagg please count me in for helping / happy to get mentioned anytime I might be of use (My email is dane@mapbox.com too). Other thoughts:

• Stoked to see C++11 discussion here: it is critical for me because nearly all c++ addons I maintain need C++11.
• I would recommend aiming to use Visual Studio 2015. I've encountered no bugs in Visual Studio 2014 CTP 4 (basically the same as the 2015 preview as far as C++11). It has worked great. I found 2013 to be too buggy to be usable in terms of C++11.
• I've successfully been building Node v0.10.33 against Visual Studio 2014 CTP 4 with minor patches and plan to soon provide these upstream to joyent/node and iojs/node: Visual Studio 2014 support for node v0.10.x series mapbox/node#1
• At Mapbox we maintain a CI setup that uses travis + aws to automate building C++11 node binaries on ubuntu precise, osx, and windows that might be of interest in this effort: https://github.com/mapbox/node-cpp11. I would love to retire this eventually if node/iojs could provide Visual Studio 2015 binaries.

[rvagg]

We'll certainly rope you in for help @springmeyer since you've had so much experience with this, we'd also like to get you involved in #12 when we start thinking about that (perhaps not for a while yet!).

VS2015 was next on my list for Windows in the test cluster but I wasn't in a hurry because it's not properly released yet. We're only doing VS2013 at the moment.

[bnoordhuis]

I'm going to tentatively close this now that we have @iojs/platform-windows and are getting close to zero test failures on Windows.

@springmeyer Let me know if you're still interested in helping out and I'll add you to the Windows team.