Actually, I think there still have to be two distinct layers - a HAL layer that is hardware-specific and built within some framework that probably looks a bit like the existing NETMF underpinnings, and then your deployable apps which would transition from being compiled to IL to being AOT compiled.
That’s all supposition on my part, but it is based on the sound presumption that you have to have a HAL layer with a well-defined and cross-platform-consistent ABI, and then you can build portable apps on top of that. The main thing I think that this changes is how those apps get built (and the wondrous speeds at which they will run).
(Glider trainer once told me that our training glider wasn’t slow - it just moved ‘majestically’)
If UWP apps run on these thingies, what would be NETMF be good for anymore?
I expect that for quite a while, NETMF will remain the larger, older and in terms of features more powerful brother of Llilum.
Not to spoil the party - this is wonderful news. But a bit of expectation management may still be healthy. This is very early code, still at least three months away from even a minimal complete rudimentary system. Probably several years away from the feature set of today’s NETMF, let alone of anything larger. There’s still an enormous amount of work needed until it matures from a research prototype to a production system, even if only the bare minimum of drivers is supported in the beginning.
The best we can do for this new platform is, IMHO, to give it time and not pressure Microsoft to provide everything but the kitchen sink. We are talking about microcontrollers, after all. Maybe we should think of it as a .NET nano framework, that is allowed to be smaller (also in terms of API surface) than NETMF. At least for the next couple of years.
However, if we don’t ask for too much, or the Llilum team does the Steve Jobs stunt (saying NO to new features always all the time even under duress from the community), then Llilum could become a fantastic tool.