1. 19
  1.  

  2. 8

    See also Midori (where async/await was invented): http://joeduffyblog.com/2015/11/03/blogging-about-midori/

    1. 3

      This blog series is great — I’ve just finished the first one and bookmarked the rest.

      Interesting that Microsoft would have two projects this similar at almost the same time. But I guess huge companies can afford that. (My experience at Apple in the 90s and 00s was that building even one new OS causes talent-drain “brownouts” in the existing OS, but Apple was a lot smaller then.)

      Also interesting that there’s no mention of Rust in the Midori blog posts I’ve read. Rust was less visible in 2015, but I would have expected someone in that field to have known about it.

      1. 7

        Interesting that Microsoft would have two projects this similar at almost the same time

        As I understand it (and this was some years before I joined the company: everything that follows is hearsay and may be my mangling incorrect reminiscences of folks who were there), they weren’t exactly at the same time. Singularity was a research project, Midori was the attempt to turn it into a shipping product. There was some fantastic stuff in Midori, but it was killed by a couple of big things:

        • The global GC provided a global synchronisation point. A lot of Midori worked incredibly hard to avoid allocation and that somewhat defeated the programmer-effort benefits that you should be getting from working in a garbage-collected language.
        • Most of the performance benefits were only there for pure .NET code. Anything that required access to Win32 needed to fall back to MMU-based protection and was a lot slower.

        If the industry had more aggressively embraced .NET then this may have been different. Running pure .NET apps on Modori was faster and used less RAM than Windows. Running Win32 apps was slower and used more RAM. In a market where Win32 apps were the only main reason that people bought an OS from Microsoft, Midori didn’t make commercial sense.

        I believe the same overall project was the origin of Drawbridge, a Windows-based library OS that allowed Midori / Singularity to run a Win32 environment in an isolated component. This still survives and has now been ported to Linux: it’s the thing that allows SQL Server to run on Linux. It’s a bit ironic that Drawbridge failed because needing around 30 MiB of RAM per app for the isolated Windows environment was considered too much, now that we have Electron apps consuming 300MiB to do nothing.

    2. 2

      I found that idea really cool when ms first described it. There were two projects which tried to implement a similar system before MS opensourced theirs. One I got involved in was SharpOS (https://github.com/sharpos/SharpOS) with a full AOT compiler for MSIL. It booted to a simple commandline and used single, flat memory mapping (IIRC). A lot of fun to play with. I remember the devs as super welcoming too.

      1. 1

        Reminds me of the SPIN operating system, which used Modula-3 to enforce isolation at the programming language level but had all of the kernels subsystems running together in the same address space. It’s described in this paper and I wrote a summary of the paper as part of a course I was taking.