Managed operating system are you talking about? Give me a couple ...

Typical developer error

Perhaps every programmer at least once attended the idea at night that it would be nice to write your own Operating System.
In any case, I made a mistake by allowing this thought to absorb my own interests.

On the development of operating systems: modern realities.

Roughly speaking, there are monolithic cores and micronuclei. First, all I / O, process control and many of the main drivers are inside one big process. The second ones carry out the solution of these tasks in separate small modules.

While the latter provide at least one obvious advantage, which is better stability (the dead module can be replaced), in practice Linux and Windows use monolithic kernels. Why? They are easier to implement.
')

Actually, I know only 3 microkernels: Mach kernel MacOS X, kernel L4 and kernel Minix OS, written by the well-known Andrew Tanenbaum.

Although the most common operating system, Windows, still has a monolith inside, the guys from Microsoft have been developing a completely new kernel for a long time.

Singularity

Back in the early 20th year, when C # and .NET were just gaining momentum, I got the idea of ​​trying to write an operating system on managed code. However, at that time this thought remained a thought. What was my surprise when a year later I saw on Microsoft Research a page dedicated to the development of a new OS. They decided to apply the benefits of managed code to the development of the operating system. This is how the Singularity project came about.

Managed code

With the transition to managed code, we get one huge advantage: we can control the program before it starts to run. What can be learned from this?

The property of the entire managed code: the programmer can not make a mistake in working with memory. And this means that as long as we are confident in the compiler of our intermediate code, we can also be sure that our programs do not contain buffer overflow vulnerabilities (the most common critical vulnerability), do not write to other people's memory by mistake and do not read data by hanging signs. The garbage collector takes on the heavy burden of managing the program's memory (for now, though with some loss of performance).

We can rely on the static analysis of the program, thus eliminating the need for hardware memory protection. For the simplest processors, this means that at last you can safely run a multi-tasking OS and not be afraid that the programs will kill each other. For modern processors of the x86 line, this makes it possible to run all programs in kernel mode, which removes the overhead of switching from one mode to another on every system call.

We can add other rules of almost arbitrary complexity and check whether the program satisfies them before launching it, rather than with each access to the resource, as is done in many cases in existing OSs.

Singularity combines all of these benefits. For obvious reasons, Microsoft used its own Common Language Infrastructure implementation as a virtual machine. OS processes can all work in kernel mode, while remaining protected from each other. Drivers get API and advanced features based on contracts. A programmer can write his programs in any .NET compatible language.

Open projects

Microsoft is one part of the world. An ordinary programmer is different. Yes, Singularity RDK is laid out, but the company is unlikely to provide an opportunity to participate directly in the development of the OS.

The idea has spread. In the open source community, there are some developments. Cosmos and SharpOS . For the first one, I even wrote more than a dozen lines (basically translating MSIL into assembly code).

Both of these developments have been around for quite a while. However, some things forced me to abandon assiduous participation in these projects.

First, none of them has yet implemented the most important thing: the garbage collector. Therefore, the code of Cosmos and SharpOS is in fact not manageable.

Secondly, none of the projects follow the path that seems more correct to me - development from the lowest level to the highest, from the kernel and compiler to drivers and user programs. In Cosmos, there is already code for working with Ethernet, but there is no JIT compiler and such important OS concepts as process and stream.

Virtual machine with your own hands?

Learn and practice. As a student of the system programming department, it is very interesting for me to practice writing a compiler and / or OS. But at the same time to understand something new.

F # is selected as the language, the target architecture is AMD64 (it is somewhat easier to write for it than for the usual x86). This afternoon (after a couple of months of irregular programming in my spare time), I still managed to compile the simplest function (the nth member of the Fibonacci sequence) with my MSIL -> AMD64 binary translator. The generated code is still wrong (:)), because some things have not yet been completed, but already close enough to what is needed.

Conclusion

I really hope that SharpOS and / or Cosmos will eventually become full-fledged operating systems (not from outsiders) and that my own workings will take part in the race of managed technologies.

PS Join OS community!