The collective WinDev has always had a reputation of trying to shoot down anything not C++. Singularity and Midori included.
Let's not forget the time they tried to make the shell of Vista use .NET and WPF, but only got less experienced developers to do that while getting the more experienced developers to work on everything else, almost guaranteeing it's failure in order to say "see, told you so".
I was shocked when it was revealed the new Windows store and maybe even the default Mail app are now fully C#/.NET on UWP. That would have been impossible in previous Microsoft eras.
Midori as described is interesting but in a very academic-fashionable way. There weren't many ideas there unique to that team and it doesn't seem to deliver clear value. If anything its model delivers negative value: Midori is largely defined by what features it did not allow in the name of safety or efficiency. This specific blog post mentions the fact that there was no dynamic linking. Every app is statically linked. By implication there are no true in-process plugins: it's 1970s UNIX again where if you want to compose software components written by separate people you get message passing, and that's it.
Still, maybe you suck it up or use RPC or whatever, but you'd like to ask a plugin a question. Or maybe you need to load a file as part of starting up. Well, you're not allowed to do that. Synchronous blocking is another feature Midori doesn't offer. You get async/await for everything with unlimited re-entrancy. Maybe you'd like to do some computations on shared data with real threads, the sort of thing modern CPUs are designed for? Too bad: there are no threads either. "Shared-memory multithreading really isn’t the future, we thought" so they just got rid of it entirely, even though for many programs it's the only tool that makes sense.
So the model was node but with a C#/C++ hybrid instead of JS, presumably to try and address critiques from the Windows guys that managed languages were too inefficient to use for OS dev. If you do expensive OS research then by the end of it you'd better have come up with some really compelling features either for end users or developers. Where were the killer features or killer apps for Midori? Node blew up and became big because it still delivered value to developers, Rust proceeded to conquer the safer-C++ space, whilst Midori went down this technological purity spiral and never got beyond a single internal production app despite years of work.
And all that's just about the dev story. Duffy spends all his time describing the language model. What was it like to administer? What was Midori's user interface like? Did it even have one? If so, why were none of the ideas in it worthy of mention?
If you look at what the java guys have been doing lately in their own Midori-esque project then it somehow seems more on-point. They recognize threads are useful and async/await just transforms threading problems into re-entrancy problems anyway, so they are upgrading threads. They recognize that JITC and reflection are expensive so they made a tool that AOT compiles everything and restricts reflection for when you need it, but in a way that's a smooth migration for the ecosystem. They found ways to apply their compiler tech to other languages that really need perf, instead of trying to compete with C++. And they ship features to the outside world regularly.
iOS, Fuchsia, Android and ChromeOS show what happens if a company actually cares to push such an OS no matter what hardcore old timers think about C and C++ alternatives.
Yes they are still kind of there, for very niche tasks, and that is about it.
Safe Systems Programming in C# and .NET
https://www.infoq.com/presentations/csharp-systems-programmi...
RustConf 2017 - Closing Keynote: Safe Systems Software and the Future of Computing
https://www.youtube.com/watch?v=CuD7SCqHB7k
The latter has some remarks on how the WinDev disregarded Midori efforts even with the system proving its value in workloads like Bing[0].
[0] - https://www.microsoft.com/en-us/research/group/operating-sys...