About Midori
Midori was a research/incubation project to explore ways of innovating throughout Microsoft’s software stack. This spanned all aspects, including the programming language, compilers, OS, its services, applications, and the overall programming models.
A Tale of Three Safeties
Midori was built on a foundation of three kinds of safety: type, memory, and concurrency-safety
So, anyway, how do you build an operating system, whose central purpose is to control hardware resources, buffers, services and applications running in parallel, and so on, all of which are pretty damn unsafe things, using a safe programming environment? Great question. The answer is surprisingly simple: layers.
A nice consequence of our approach was that the system was built upon itself.
Note that I didn’t say we banned concurrency altogether, just that we banned unsafe concurrency.
They key insight driving the formalism here was that no two “threads” sharing an address space were permitted to see the same object as mutable at the same time. Many could read from the same memory at once, and one could write, but multiple could not write at once.
The combination of memory, type, and concurrency safety gave us a powerful foundation to stand on. Most of all, it delivered a heightened level of developer productivity and let us move fast. The extremely costly buffer overflows, data races, deadlocks, and so on, simply did not happen. Someday all operating systems will be written this way.
Objects as Secure Capabilities
Insecure operations rejected at compile-time, how cool is that!
Midori was by no means the first to build an operating systems with object capabilities at its core.
Since objects represent capabilities, they can be as fine or coarse as you wish. You can make new ones through composition, or modify existing ones through subclassing. Dependencies are managed just like any dependencies in an object-oriented system: by encapsulating, sharing, and requesting references to objects. You can leverage all sorts of classic design patterns suddenly in the domain of security. I do have to admit the simplicity of this idea was jarring to some.
we banned mutable statics, by-construction at compile-time, in our programming language. That’s right, not only could a static field only be written to once, but the entire object graph it referred to was frozen after construction.
Asynchronous Everything
First, remember, Midori was an entire OS written to use garbage collected memory. We learned some key lessons that were necessary for this to perform adequately.
The first key optimization, therefore, is that an async method that doesn’t await shouldn’t allocate anything.
The second key optimization was to ensure that async methods that awaited allocated as little as possible.
What we ended up with was a model that only allocated when the await happened, and that allocated only once for an entire such chain of calls. We called this chain an “activity.” The top-most demarcated the boundary of an activity. As a result, could cost something, but was free.asyncasyncawait.
It was pretty common to be running the Midori system at 100% CPU utilization, because it was doing useful stuff, which is pretty rare on PCs and traditional apps.
and ?