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.
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.
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!
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).
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....
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...)
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.
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.
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.
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.
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).
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.
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.
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. ;)
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!
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:
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.
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.
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.
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.
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.
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/
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.
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.
