@mburumaxwell: It's definitely possible to run IoT Core on a custom board that has a supported SoC on board (e.g., Intel BayTrail-I, Qualcomm 8016, Broadcom 2836, ...), but porting Windows to a new SoC is a different question. It's not practical today for someone other than Microsoft to bring up Windows on a new SoC.
Steve Teixeira (Microsoft)
In terms of support for additional dev boards, we'll be sharing more about Qualcomm DragonBoard 410c support soon. Just to provide a little bit of "Behind the Music" perspective, the key piece of engineering work for us to enable new boards is the core Windows port to the SoC that is used by the board. This can range from reasonably straightforward, as is the case with DragonBoard since it uses a SoC family already supported by Windows Phone, or many people-years of effort for a new SoC, such as was the case with Raspberry Pi 2. Udoo uses the Freescale i.MX 6 and BeagleBone uses the TI Sitara -- neither of these SoCs are supported by Windows today, so either would be a pretty heavy lift.
Valentin: We will make a limited number of these Galileo boards running Windows available later in the spring (see www.windowsondevices.com for more info).
Jack: This particular demo uses the Windows 8.1 core, although with a few small changes to accommodate the Quark chip (e.g., no SSE).
C9::GoingNative Live: Kate Gregory and Steve Teixeira - Modern C++, AMP, Casablanca, C++ RenaissanceJul 12, 2012 at 9:23AM
On your first question, WinRT will be at least part of the answer for you. You will increasingly see component and library vendors (including us) publish their goods at WinRT components (or, at least, with WinRT wrappers). WinRT is good for these component/library scenarios because it is:
- High-performance because it's native (it's basically modern COM).
- The ABI is rich enough to represent a modern, well-factored, composable library in all of the above languages (classes, interfaces, generics, exception model, etc.)
This will result in more components/libraries available in all languages, including C++, because vendors can spend more time writing the code that matters and less time trying to target or tune to a particular programming language audience.
I said "at least part of the answer" earlier because WinRT handles the case of running on Windows 8 really well, but it doesn't solve the problem more generally down-level or cross-platform for C++. For this, there are some efforts just getting underway to improve the collection of standard (both de jure and de facto) C++ libraries, which Herb originally motivated in his talk at the GoingNative conference and has been leading since then.
As to your second question, you should check out Casablanca at http://msdn.microsoft.com/en-us/devlabs/casablanca.aspx. I think you'll find it includes much of what you're looking for, and we're taking on this work in a way that we expect to be palatable to both cross-platform implementations as well as eventual standardization of all or parts.
I hope that helps.