Show HN: A new hobby OS from “scratch” in C# | Hacker News Reader

Show HN: A new hobby OS from “scratch” in C#

github.com

310 pointsamaneureka63 comments

I appreciate that this is a hobby project, but comments like this one in Kernel.cs:

     while (true) //Set CPU in Infinite loop DON'T REMOVE THIS ELSE I'll KILL YOU (^ . ^)

combined with things like your "How to contribute" section requiring that anyone wanting to contribute is "dedicated", are frankly going to put anyone off wanting to get involved with this. It also doesn't reflect well on your maturity as a developer.

I'm all for humorous comments, even if they're a bit flippant, but that comment just isn't funny. Though I've met some great people with a sense of humor that makes absolute no sense to me and that's just how it came off to me versus a maturity issue (but without my experience I could easily see having an identical opinion to yours).

The dedicated part though seems a little more ridiculous to me. Most people who may contributed may not necessary be "dedicated" or even like the project but just may want to help with someone. If I saw a project was looking for dedicated contributors I'd be less likely to contribute anything as I don't want to be married to someone else's project.

The "YOU" here might refer to the compiler, not the person looking at the code.

There's also MOSA[1] and Cosmos[2]. MOSA is focusing more on the compiler/runtime, while Cosmos is doing just enough to get a working OS. Both are pure C#, it looks like Atom is too.

[1]: https://github.com/mosa/MOSA-Project [2]: https://github.com/CosmosOS/Cosmos

Yeah. And I managed to take it to the next level with dynamic executable loading and SVGA drivers.

But why not join forces with cosmos-instead of many half done OS we could have one functional? Were there any particular reasons?

For couple of years I contributed to Cosmos and fixed some bugs in MOSA. But my design idea was much different from them. So I decided to start with a new project. And seems like it worked!

Can you elaborate on differences?

Back when MOSA got created, we were aiming for a pure approach. For example, we were trying to use as few intrinsics as possible and a mostly architecture agnostic approach.

Furthermore we also focussed on Mono compatibility (that was way before CoreCLR came out).

Source: Ex co-creator of MOSA

I wonder whether now it can switch to core to native compiler (supposedly soon available)

This "why not join forces to have one good one" applies to all those "let fork it and do it better" projects....like systemd, KDE, Gnome etc (yes, they are not all forks, but you get the idea). This is one drawback of open source but also its strength....

True, but those are functional systems. While we don't have a serious C# OS.

Nice, although I'd call the AssemblyAttribute EmitAssemblyAttribute, as the Assmebly word has its special meaning in the .Net world, and can potentially confusing (not to mention the assembly scoped attributes...)

Sure, Thanks :D

[Removed to avoid distraction.]

I didn't mean that way. But I have updated the comment

Apologies if I misinterpreted.

This sounds interesting but is really lacking details. Though... now I wonder what happened to singularity / midori.

I am really sorry about lack of details on page. I am working on it and soon add more detailed documentation.

Meanwhile You can try building it and play around with source.

https://github.com/amaneureka/AtomOS/wiki/Build-Environment

according to the license headers in the source files I am not even allowed to copy the thing to my computer...

edit: ok, found the project license (bsd) but you really should update those headers...

Would be nice if there was an ISO or cloud-installable VM image available. I've distributed "live cd" VM ISO's via legal torrent sites, which is a little hassle to set up but will make it a lot easier for people to get involved.

Aren't you aware of Joe Duffy's blog?

http://joeduffyblog.com/

https://www.infoq.com/presentations/csharp-systems-programmi...

Basically both projects achieved their goals, but Midori eventually was killed by management, even though they got an usable GUI desktop running with some core applications.

Some of their decisions influeced async/await design in C#, the AOT compilers to native code in WP 8.x and WP 10, some of the new features for C# 7 and others planned for future versions.

anybody knows if the scoped modifier is going to make it from m# into c#? that would be great...

Currently they are playing with Span<> and Memory<> at CoreFX Labs, which make use of IDisposable, so they could at least partially support it at library level.

https://github.com/dotnet/corefxlab

https://github.com/dotnet/corefxlab/issues/952

As for scope M#/System C# style, I guess the door is still open for future C# versions.

I'm surprised C# is suitable for this. How does that work?

Because It is not possible to run C# executable without .NET framework. I had to work on a compiler first. Source: https://github.com/amaneureka/AtomOS/tree/master/src/Compile... Which works on the top of Microsoft's IL Builder. Then it add compiler stubs to support .NET code and convert code into native x86 assembly. The assembly file is then passed through NAsm and proper linking chain to produce final Kernel ELF binary. Build.sh produces an ISO image which can be used to boot OS in either virtual machine or on real hardware.

I explained it here: https://www.reddit.com/r/programming/comments/5xlmc6/a_new_h...

Good luck with the project, we already have too many kernels written in straight C.

Only thanks to this kind of work one can prove it is possible.

As a guy who really thinks *nix is awesome, I welcome new additions, too.

That's a lot-o-work! Pretty impressive man. I think projects like this are awesome.

How does that work? Surprisingly well :)

Many hobby kernels (as mentioned in these comments) have used C#, as well as bleeding-edge research kernels e.g. Microsoft's Singularity project: https://en.wikipedia.org/wiki/Singularity_(operating_system)

Bleeding-edge was VerveOS:

https://www.microsoft.com/en-us/research/publication/safe-to...

It's legacy will be in their IronClad Apps. Look into those if you want to see how far they've gone. Also, Microsoft Research & HLL vs Nix and C in security are a gap that's ever widening. ;)

Haven't you heard of Singularity or Midori?

http://joeduffyblog.com/

https://www.infoq.com/presentations/csharp-systems-programmi...

There are quite a few OS projects written in system programming languages with GC, all the way back to Mesa/Cedar at Xerox PARC.

If you want to have an idea, check the Project Oberon book.

http://people.inf.ethz.ch/wirth/ProjectOberon/index.html

This is the 2013 re-edition, it was originally published in 1992.

Also a library for building special purpose operating systems (unikernels) in OCaml, which is actually used: https://mirage.io/

Let's not forget other more recent stuff that still happened before AtomOS, like Redox. I seem to recall seeing a couple others recently as well, but for some reason I'm drawing a blank now. I think the big deal about this is mostly just that it's an effort outside of Microsoft to do this, and compile it to machine code rather than just use some kind of "higher order" OS that needs to run on top of something else -- and even there it's not unique, even if it looks more interesting than FlingOS (which is evidently just a new take on the "toy kernel/OS for teaching" idea).

Midori was still built on a C++ microkernel though.

Which doesn't diminishes its value.

No one would though of writing an OS in C++ in the 90's, it was too slow and everyone knew that microkernels could only be possibly written in C.

I thought of writing an operating system in C++ in the 1990s. I didn't achieve it until after the turn of the century. But I definitely thought of it.

The "everyone" who knew these things about C++ was a small set of vocal people largely from the Unix and C worlds. Other people who were at the time developing Windows NT device drivers in C++, to pick one example, knew that a lot of the received, and loudly recirculated, wisdom about systems programming and C++ was just bunkum.

Me too, I never liked C.

What I was trying to convey with that comment was that C++ was looked down for systems programming, it required Symbian, BeOS, OS X IO Kit to change that mentality.

Even Windows that you mention, which always was a more welcoming place for C++ tooling, Microsoft only started to officially support it with Visual C++ 2012 when the /kernel flag was introduced.

So even that microkernel could have been eventually written in System C#, if there was enough management support to keep developing Midori and improving the language to the point C++ wouldn't be needed.

Instead the project was canceled and since in IT, seeing is believing, there will be idea for many, that there wasn't any other way to accomplish it.

I love the way Alan Kay and others like him think, it is not what the technology give us today, but what it can give us tomorrow in a few years time.

Looks like a traditional kernel, which I think is a shame. High-level language-based operating systems have a lot more flexibility to enforce fine-grained abstractions rather than a traditional OS's coarse-grained abstractions.

For instance, memory safety is process-level in a traditional OS, but object-level in a programming language. So paging logic doesn't make as much sense here, since it would require a lot of expensive runtime support to make every object lazily loaded, not to mention the expense of the bookkeeping overhead to track which objects should be paged out.

This encourages a more event-oriented architecture where programs provide the kernel with continuation when requesting services. For instance, something like C#'s async/await operating at the kernel process level would be one possible approach.

I strongly recommend you to build the kernel once and check output assembly file. which should answer lot of your doubts like extra overhead of object loading. It's not exactly same how you are interpreting. I tried very hard in order to optimize the output code.

Are you saying this is not a traditional operating system design utilizing the MMU for memory protection? If it is, then everything I said is accurate compared to software isolation in an OS like Midori. If not, then you should really point that out because it makes your project much more interesting!

Indeed it is utilizing MMU for memory protection. But no that is not the final objective of project.

Sure, your objective is a standard operating system, and that's a neat project. I'm just saying that a high-level language operating system provides many more opportunities for different kinds of trade-offs than found in typical commodity OSs. These aren't trade-offs you can make if you're going to support legacy code or traditional OS abstractions, without jumping through a lot of unnecessary hoops.

naasking is saying you could try different protection strategies since it's an experimental, clean-slate OS. User/kernel model protection is among the weakest models that only works with separation kernels such as seL4 or Muen. Tiny, tiny kernels. Let me give you examples of alternative, OS architectures and protection models to show what naasking likely meant by doing it different:

http://www-spin.cs.washington.edu/

Note: SPIN OS was written in safe Modula-3. Interesting thing about it was leveraging the language safety & a type-safe linker to allow code to be loaded into kernel for acceleration.

http://www.symbolics-dks.com/Genera-why-1.htm

Note: LISP machines were among most powerful machines ever created for developers. The language itself had code as data philosophy to change it at will. Runtimes had REPL, incremental compilation per function, AOT compilation, and live updates of code. Do a whole OS that way you get feature 7 along with debugging or linking ones on 8-12 page that no OS has today. I mean, single coolest thing your OS could do is allow debugging or updates of it in high-level code that somehow goes through compiler and right back into memory. The same HLL that users write the applications in.

http://www4.cs.fau.de/Projects/JX/

Note: The main paper on this page will tell you what this OS is about. The architecture tries to enforce POLA at a decent granularity with building blocks that are pretty easy to understand. Almost everything is safe. One thing worth copying is using different, garbage collectors for different apps or parts of OS.

https://en.wikipedia.org/wiki/MOSIX

http://encyclopedia.thefreedictionary.com/K42

Note: MOSIX was an OS I ran into when I studied supercomputers in the late 90's. The cool thing about it was how it turned a network of computers into a cluster that it automatically distributed jobs over. Treated them like one machine in a way that typically required low-level, message passing. K42 was IBM's attempt at building blocks for something similar using microkernels and hot-swappable components.

https://www.cs.vu.nl/pub/amoeba/amoeba.html

Note: Amoeba was a distributed, operating system. Each machine ran some code. The OS and apps were spread among them.

https://www.cs.ucsb.edu/~chris/teaching/cs290/doc/eros-sosp9...

Note: EROS was a capability-secure, microkernel OS with trusted networking and GUI stacks. Abandoned when Microsoft hired Shapiro. Capability model has strong properties for enforcing POLA but one must be clever to minimize overheads.

E language and capability model

https://www.combex.com/papers/index.html

Note: Embedding the capability model as constructs in the language, esp RPC's, can make for interesting abilities.

https://www.microsoft.com/en-us/research/publication/safe-to...

Note: Nucleus is literally stolen from a 70's-era mainframe that did same stuff along with Per Hansen. The idea is you wrap all the low-level stuff behind an interface that forces it used safely & consistently in above layers. Then, above stuff is easy to do in high-level language. The how of this has many possibilities. Safety enforced statically with type systems or Design-by-Contract (e.g Spec#); or dynamically with argument checks; or both.

I'm super excited about the idea of removing the artificial boundaries between kernel and userspace. Equally, static and dynamic compilation.

Are there any technical or practical reasons why systems like Symbolics Genera are inferior to todays mainstream operating systems? Or do you think it's only social / economic processes that they weren't adopted?

It was economics like with most hardware of the time. Those were expensive, custom machines. The CISC and RIZC processors kept getting cheaper and faster to point that users, mostly wanting performance, were better off buying them. Genera itself eventually got hosted as an emulator or something on Alphas. Then Alphas bit the dust haha. Wait, it's not funny cuz PALcode was amazing.

Anyway, economics and market demand as usual. That's what killed it.

There is an OS named "Atomic" (it is a Red Hat project, so not particularly obscure), which seems pretty similar to "AtomOS" and "Atomix": http://www.projectatomic.io/

I see a lot of concepts simply borrowed from Cosmos, rewriting it and seeking copyright - Especially the IL2Native compiler is very similar.

Not sure how it could deal with GC pause.

It does not. new operator internally calls Heap.kmalloc https://github.com/amaneureka/AtomOS/blob/master/src/Kernel/...

To free any object instance I have to call Heap.Free

So random including random c# snippets would probably leak memory? I imagine it would produce an uncanny valley feeling.

How is it different to https://github.com/FlingOS/FlingOS/ ?

Not trying to be difficult, I'm just wanting to learn more about your project.

I see it at least has a better license.

Linux has done pretty well with the "worse" GPL license.

This is fantastic. I have heard of a few projects like this. I'm guessing you're natively compiling the C# code. I'd love to contribute but I'd probably just get in the way. Good luck - a glimpse of the future perhaps.

No way to build on macOS..?

Yet another "multitasking monolithic kernel based x86 targeting operating system" isn't that useful. Something new would help. A fast microkernel. A hypervisor that runs containers. A kernel with better security for IoT.

Being written in C# makes it useful, because in this industry we lack visionaries, and most only believe what is put in front of them.

That looks good!

(P.S. turns out we are from same college _and_ school)

oh! what's your name?

Does your compiler handle generics?

Yes! https://github.com/amaneureka/AtomOS/blob/master/src/Kernel/...

commits messages like "Open Sourced!" annoying

Reply on news.ycombinator.com