"This code was written several years ago as one of my first projects when I was in High School so it's normal if some parts of the code looks like "crap"."
In other words: "I'm doing a (free) operating system (just a hobby, won't be big and professional like gnu)..."
Please don't insult yourself by writing 'not great' on things that you wrote. You know it's not great, I know it's not great, but you made an effort and have a basic workable system. Don't kid yourself, and don't put yourself down. Not everyone can be a 'great programmer'. If there are maybe 20 great programmers in the world that you look up to, there are 200,000 programmers who are average at best. So don't compare your code to the top 0.01% - no way any of us can be that good.
Agreed, unfortunately posting this with just "check out this basic OS I wrote" would yield a ton of flamey comments like "WTF, why would I use this instead of Ubuntu?! Lame."
I attempted the very same in my first year of college (in the UK, so about the same age). I only got as far as a memory manager, FAT16 filesystem driver and basic bootloader though so congratulations for making it so far!
Here's some great resources for OS dev, if you wanted to take this further (or if anyone else in this thread fancies a shot):
Ironically the institutions and society thought I was wasting my time, being from school when I was making my own LinuxFromScratch at home. Even going so far as to threaten to expel me from the school, for not being there at classes.
I came back about 4,5 years later to that school, then as a teacher of their newly founded IT classes. Chuckle.
To get back on post, this guy making his own OS is a wizard.
I think OS designers have too small a vision. The basic principle separating 'OS' from any other support is: sharing. Device, process, hardware, access, network, anything.
There are so many things to share that are usually exclusive, they should be pushed back into the 'OS'. So many lame devices surface a serial streams - the OS doesn't allow sharing those. Lots of OSs don't allow multiple clients access to a webcam, microphone or other capture devices.
Even the model of 'process, thread, priority' is inadequate today. I'd much rather schedule latency than priority. And I'd like virtual hardware to be mapped into app space to remove copy/interrupt/stack switch time from drivers (and reduce latency to zero). I'd like to schedule network traffic across purposes/apps.
I'd like the 'file system' to abandon the ceremonial file tree, and expose a persistent object store. Objects could (should) be uuid-labelled at root, have no fixed location. The local file system could be thought of as a cache of resources, with the authentic directory cloud-based. Access should be through attributes and relations.
I guess my point is, there's so much more to what an OS should be, than page table/scheduler/disk drivers.
> Lots of OSs don't allow multiple clients access to a webcam, microphone or other capture devices.
Does the multiplexed access need to be at the kernel level? It could be done with a user space server.
> And I'd like virtual hardware to be mapped into app space to remove copy/interrupt/stack switch time from drivers (and reduce latency to zero).
There have been efforts to eliminate copies, and to allow direct access to network devices from userspace.
> I'd like the 'file system' to abandon the ceremonial file tree, and expose a persistent object store. Objects could (should) be uuid-labelled at root, have no fixed location. The local file system could be thought of as a cache of resources, with the authentic directory cloud-based. Access should be through attributes and relations.
I'm in agreement that the filesystem tree is problematic. It's inefficient to traverse a directory tree when it's structured as a persistent linked list, and it's brittle. The tree is intuitive, but you could create a tree interface even if there isn't a literal metadata tree on disk.
You might be surprised by all of the zany things that have been proposed and tried in the OS community. The abstractions that have stuck around are oldies but goodies that are simple but work. A lot of things don't need to be done at OS level, like cosmetic changes to the interface of some resource. You can usually do that in userspace. Linux is pretty remarkably flexible with filesystems, too. FUSE is about as flexible as you can get.
The best argument to change the kernel is when something simply can't be done efficiently in userspace. If there's a way to implement something useful in userspace on top of existing kernel functionality, that's the way to go.
The ceremonial file tree doesn't 'work' for nearly anybody. All significant apps embed their own structured data inside a big file, effectively implementing their own filesystem. The OS could have done so much to help.
In particular, no single OS can reimplement a distributed object store by themselves - there has to be an ecosystem. Somebody big has to invent that. Then, how to shim that under the file tree without changing the OS? E.g. I want an entire enterprise to get their apps from ... wherever its convenient for them to be stored today. Not from c:\xyz on their local disk. And I want some subset of my users to change to a new version without obsoleting the old, by changing the directory record in my enterprise cloud, NOT by triggering some binary update monstrostrosity, then writing another script to back out the update etc.
I'd say its universities that are letting us down, by continuing to teach the obsolete ideas current in the 1980s.
> The ceremonial file tree doesn't 'work' for nearly anybody. All significant apps embed their own structured data inside a big file, effectively implementing their own filesystem. The OS could have done so much to help.
Do you mean like a SQLite file? You have to consider how much there is to gain from embedding this stuff deeper.
> In particular, no single OS can reimplement a distributed object store by themselves - there has to be an ecosystem. Somebody big has to invent that. Then, how to shim that under the file tree without changing the OS? E.g. I want an entire enterprise to get their apps from ... wherever its convenient for them to be stored today. Not from c:\xyz on their local disk. And I want some subset of my users to change to a new version without obsoleting the old, by changing the directory record in my enterprise cloud, NOT by triggering some binary update monstrostrosity, then writing another script to back out the update etc.
This doesn't necessarily need to be in the OS. Look at it as a technical problem to solve. Is there a way to meet this need without changing the OS? There's usually a creative solution.
Ever try playing with plan9? It persuaded me that, yes, the modern tree filesystem sucks, but not because organizing persistent data into heirarchies is bad, but because you don't always want the physical translation presented to you. Plan9 was pervasively virtual, with an applications filesystem view being radically different than anothers, and with everything accessable through file read / writes (including OS system calls besides open, read, write, and close).
I've never tried Plan9. Doing searches over deep source code hierarchies has been my most recent experience with the inefficiency of the directory tree (nevermind the inefficiency of overly-complex source code). Really, there's no fundamental reason why `find /usr -name foo` has to take all day. While installing software, also, I was struck by how long it took, while it was apparently updating all the filesystem metadata. For the problem of long installs, I had a brainstorm: what if userspace could hand the filesystem an entire archive in a single transaction, and let the filesystem handle materializing it into a directory tree at its leisure? Just give the filesystem a tarball, rather than the application having to piece together the subtree step by tiny step? It would certainly make it more ACID, and it's not like tarfiles are bleeding-edge technology. Maybe that's a good project for someone who wants to hack filesystems.
This is the reason I learned Assembly in high school. I wanted to write my own OS and well it seemed at the time (around 2000) that I would need to know ASM to a bunch of the low level stuff. I didn't really have anyone to tell me I could write a whole OS in C or C++.
I got a floppy to boot into my os and print hello world and I learned a ton about how to program a processor. It was fun. Oh the crazy things you do as a teenager...
Bravo indeed! I only started programming in my senior year of high school. I wanted to write an operating system for my senior project, but I thought that was WAY too ambitious. Kudos!
I forget where I read it but I remember a quote the basically boiled down to "The only people willing to attempt writing an OS are those too naive to know how much work it really is." Part of that probably explains why you can learn so much when just starting out...you just don't realize, yet, how much of you're life it will consume.
I realized over the years that it's those high school and college years where you can really expand your skill sets where as once the real world starts throwing things at you you start to stagnate. Makes me regret a lot of the time I wasted in those years.
The OP (SamyPesse), is my co-cofounder and we're currently building our own Startup together (https://friendco.de).
I thought you might be interested in seeing what he's (and I are) working on now. (We've got some cool open source components here: https://github.com/FriendCode/, that you might want to check out).
freefull@freefull-hp ~/c/o/devos> make all
Building Kernel
make -C ./kernel
make[1]: Entering directory `/home/freefull/code/other/devos/kernel'
makefile:9: runtime/Makefile: No such file or directory
makefile:10: core/Makefile: No such file or directory
makefile:11: modules/Makefile: No such file or directory
makefile:12: arch/x86/Makefile: No such file or directory
make[1]: *** No rule to make target `arch/x86/Makefile'. Stop.
make[1]: Leaving directory `/home/freefull/code/other/devos/kernel'
make: *** [all] Error 2
make looks for [Mm]akefile if you run it with no arguments, but here it's being run recursively (or included). On OSX, filenames are case-insensitive, which could be a possible reason why it works for some people. On Linux, filenames are case sensitive.
That seems to be the case, since running file on one of the existing .o files says that they are Mach-O i386 objects. The readme doesn't mention OS X though, only Ubuntu
I too wrote unix like kernel when I was student (around 8-9 years ago). My kernel was also in C++ and and little bit of asm (nasm)
It was very fun experience. Probably that was my most enjoyable time in programming. I learned a lot about many things: OS internals, compilers, device drives, software engineering etc. Also spent good amount of time in exploring C++ object mode. Much later I wrote an online (short) article on C++ object model and how C code is translated into assembly (http://www.avabodh.com/cxxin/cxx.html, http://www.avabodh.com/cin/cin.html)
This just makes me feel inadequate...you wrote this in highschool? How old where you back then if I may ask and what made you take the challenge?
Also, how does one even start to write their own OS, I mean after you say "I'm going to write an OS form scratch", what's the first step, what's the first line of code and how do you figure out which components you need to implement and how? This is what really boggles me as a 30 year old crud guy, how do you design these sort of systems from scratch (OS's, emulators, compilers, etc)? It just makes me feel...completely useless compared to guys like you, you are so far ahead of the curve its not even funny, I could never reach your level.
I thought this was pretty cool. It would be fun to do something like this and I'm sure I'd learn a lot. I found a lot of helpful information, books, and websites on this Stack Overflow question: http://stackoverflow.com/questions/1224617/how-can-i-build-a...
Nice! And I wouldn't call it "very basic". It's inspiring to see how far you've gone, even at such a young age.
I took a shot at os development and it took me almost a month of reading to get something that boots and handles interrupts (https://github.com/raaapha/sos), and I'm in college. Now _that_ is "very basic"!
Never too late. The only problem with writing an OS is that you are exposed to the x86 architecture - which is HORRIFIC, but even something as small as booting to "hello world" gives you a wealth of knowledge about the underlying layers that we take foregranted.
I looked at the teaching kernels xv6 from MIT, and Pintos from Stanford. They are both x86, and I've heard the same sentiment that you express, which makes me a bit hesitant to dive in.
Does anyone know of something similar for x64? Or maybe ARM? Online course materials would be nice.
I doubt x64 would be less horrific. As for ARM, there is Cambridge's Baking Pi course http://www.cl.cam.ac.uk/projects/raspberrypi/tutorials/os/, which has you develop an "Operating System" for the Raspberry Pi. Although, from looking at it, it seems more like an embedded systems course than an OS course. It talks about controlling hardware like LEDs, monitor, and keyboard, but it doesn't talk about stuff that full-fledged operating systems have, like scheduling of userspace processes, memory mapping, filesystems, etc.
I'm not really qualified to say, but isn't modern ARM also quite horrific from osdev point of view. At least x86 has some sort of standards imposed by intel, but with ARM every manufacturer is doing it's own thing with the peripheral functions. Wasn't that what Linus was complaining some time back that Linux ARM support files are blowing up because there is too little code shared between platforms?
That's only an issue if you're building a general purpose OS that tries to target every ARM board out there. If you're just making a hobby OS on a simple device, then you don't really need to worry about it. In the x86 world it would be analogous to saying that you don't need to worry about writing an ACPI engine into your hobby OS.
Unfortunately, I'm not allowed to put my 236376 Operating Systems Engineering course project online, due to the licensing issues with JOS-based project code.
It took me like a year to really understand how everything works and come to this version (it was 4 years ago). I really learned C/C++ (and some assembly) with doing this, so I wasn't really good at C++ before (and if you take a look at the code, you'll see that it's not really pretty).
Hey! I wrote a kernel in Highschool too, after being inspired by Linus' "Just For Fun". Amazing experience, although mine was in C and nowhere near as complete as yours. Well done!
In other words: "I'm doing a (free) operating system (just a hobby, won't be big and professional like gnu)..."