How to Make a Computer Operating System in C/C++ (opens in new tab)

> write a very simple UNIX-based operating system in C++ (does anyone else smell a contradiction?)

I'm going to use this as an opportunity to champion C++ for systems programming despite the fact that it wasn't really your argument. I feel obligated to do this because I agreed with you for a long time on this but have changed my mind over the past year or two.

The argument against C++ as a systems programming language has always been that it gives you too much freedom to hide complexity, but I've written systems code in both C and C++ professionally and it's been my experience that the extra burden of having to write every damn thing over again in C (or use a relatively poorly tested container library, as compared to something like the STL) is not worth the "obvious performance characteristics."

I'd further contend that in non-trivial software all perf characteristics are non-trivial, so even though a + b might be doing all kinds of crazy things in C++, you're much more likely to run into problems invoking store_value() which might interact with a number of underlying libraries and system calls. At the end of the day you're hopelessly screwed without profiling and the utility perf works just as well on C++ programs as it does on C programs.

Finally, the majority of code in my experience is either slow path or at least not the bottleneck anyway. You can almost always optimize a systems program by making smarter system calls (or hardware invocations), while optimizing CPU is rarely worth it. Even if you're CPU bound, it's likely that it's in doing something like SSL, wherein you're almost definitely wrong to try to jump into a project like OpenSSL with micro-optimizations. With that in mind, why not allow yourself to move faster by creating a std::vector? When you use the proper conventions, it's generally as fast anyway.

Just because people can (and have, a lot) misused C++ and created way too much complexity with it doesn't mean that it's not the preferred language in the hands of someone who knows what they're doing. (And yes, it's much harder to learn how C++ works in a meaningful way to avoid these pitfalls, but if it's your job, learn it anyway).

Hm, it doesn't claim it's one language. And it has indeed C code and C++ code...

I used to put C/C++ in my curriculum until I realized that my C++ code was getting a lot less "C-like" each year. Now I put it separatedly, which also allows for a nice explanation whenever I'm asked about it in a job interview.

I thought it was a reference to this* when I read the title, but after reading them both I'm not sure there is any connection.

*http://i.imgur.com/fQ1ST8w.jpg

You are correct. Usually I see this in CVs. It usually means that the person is proficient in C++ but knows a little C as well. But C/C++ can be a language. It could be a code written in C++ but looks more like C than C++. Some people e.g. use character arrays instead of string class, avoid STL as much as possible, don't use object-oriented aspects of the language, etc. The end result uses some C++ libraries, compiles on a C++ compiler but resembles C more than anything. I think it would be appropriate to call it C/C++.

I think that AMD Developer Guides & Manuals [1] are very good resources for x86_64 System Programming (better than Intel Manuals). They are better explained and focus on x86_64 arch.

[1]: http://developer.amd.com/resources/documentation-articles/de...

There's absolutely a void when it comes to a full amd64 assembly (and associated low level) code. It's a shame, because amd64 is actually rather plesant (as opposed to x86) -- and now rather ubiqutous.

I haven't really looked at the code, but I guess the following at least contains a bit of example code:

http://www.returninfinity.com/baremetal.html

Menuetos also looks rather interesting, unfortunately, as I recall the license for the 64bit version puts the code in a bit of a limbo as far how it's actually useful. There's a fork, but not for amd64 afaik..

http://menuetos.net/

http://kolibrios.org/en/

Building OS' is fun. I wish I could spend all day doing it but I've been pushed so far up the stack that I spend most of the time arguing with analysts and preparing documentation...

I've built two so far which were (and I think still were until recently) used in production equipment. One Forth system (all 8k of it) that ran a PLC system and a tiny (16k) kernel for an M68k system that was a router for a modbus-like protocol over RS485.

Nothing x86_64 but nevertheless the most fun I've ever had with a computer.

There's some stuff about 64 bit over at http://xomb.org

Why?

(I'm curious as I know little of these kinds of things, and because citing sources or giving arguments is always a good thing)

I've been looking for good OS dev tutorials for ARM. Does anyone know of any besides Baking Pi?

BeOS was primarily written in C++, although the kernel was dominantly C. For actual parts that require user interaction, C++ and the object model makes a whole lot of sense, although there are probably more mature languages out that would be better candidates now.

Yes it's very early stages I'm looking for feedback on how to structure the course.

No I don't think so, I just want to an informative resource from what I've learned.

You forgot to add in your list: making a completely new processor ;) Which the linked project actually achieves.

Our school used Pintos, a derivative of Nachos. Taking the OS course there was an eye-opener for a student as technically immature and inexperienced as I was at that time, but it was also a tremendous learning experience. I've always wished I could go back and retake that course, the 'right way'...with these resources, though, maybe there's a better way.