This is very nice! A while back, I attempted to interact with Bluetooth/BLE on Windows 10 with Node.js, which didn't go particularly well... I switched to ChakraCore (pretty rough at the time but required for node-uwp support) which was supposed to give me access to the Windows APIs but nothing was working out as expected, so I ended up dropping my project. Thanks to this, I might be able to give this another shot! I see there's an open issue for Electron, I'll try and give it a shot over the weekend too.

It would be very nice if the WinMD thing could be system-agnostic (within reason of course), so that the generated modules aren't specific to a particular version of Windows. I admittedly know very little about this, so I'm guessing it's a lot more complex than I realize.

@grownseed - Sorry about the confusion, NodeRT was actually tested with Electron. We also added a "Building for Electron" section in the doc. The issue was updated to refer to a tool that wraps Electron apps for the Windows Store.

Yes I'm wondering about this too. Say I want to build a windows application with electron, and I want to use geolocation or bluetooth, does the app need a module for each version of windows if I want to support multiple versions of windows? Or would it perhaps even be possible to generate the modules for the appropriate windows version on the fly from the app itself?

The Windows runtime is backwards compatible, so there are no breaking changes in WinMD files. You should be able to just generate a module for the latest available version of Windows.WinMD.

Attempting to call functions which don't exist on the OS you are using should just result in E_NOINTERFACE being surfaced by this projection.

Actually what I like more is the generator.

It looks quite nice idea to fork and re-purpose it to generate projections for other languages besides JavaScript.

Specially because the documentation how to create language projections is quite sparse and requires COM knowledge.

So the generator accessing the .NET metadata from a .NET language is more appealing than the existing COM API to work with WinRT types.

In any case, nice work.

There's also a work-in-progress (but working - it processes all WinMDs) generator for Rust, being developed by Patrick Reisert: https://www.github.com/contextfree/winrt-rust

(I started this GitHub repository but this has been developed 100% by Patrick so far, since everything I was working on was done much better by him. His fork is at https://github.com/Boddlnagg/winrt-rust )

Quite nice. Thanks for the heads up.

The generator is cool, but I'd focus more on the output; that is what people will care about. It's output is also fairly static, so focussing on the generator doesn't make sense (although it's very awesome!).

So, in short: cool project!

As one of the PMs at MSFT that built WinRT, this makes me smile :)

I really hope the WinRT type system/metadata (and Windows APIs) continues to be updated to follow advances and trends in the languages that bind to it. e.g., non-nullability annotations in metadata, to project to non-nullable references in languages (currently in newer languages like Rust, Swift, F#, Typescript, but potentially making their way into future versions of C#)

I guess you can't make win32 calls like with pinvoke?