Hi, I'm Sortie. Guess what, I made an operating system! I'd list all the nice features it supports, but somehow the only interesting part for normal people is that you can play Pong.
Edit: A couple years passed, you can now play Quake.
Edit: Another year. I am now self-hosting. I demand I'm eligible to never hear of Windows again!
Edit: Another two years. My OS is installable and self-hosting and the latest release was built under itself. I may have heard of Windows again.
Please realize my recommendations aren't applicable in your case this if:
- You are making a microkernel or any other design where my personal experience isn't relevant.
- Your design goals are incompatible with my recommendations.
- You insist on osdeving in ways I cannot approve of.
- You are not trying to make a good operating system.
Let me know if I am wasting my time trying to give inapplicable advise.
- Don't ask questions on #osdev, wait 30 seconds, and then ragequit. I'm upstairs getting my coffee and I can't prepare it that fast.
- Don't follow tutorials that can't be edited by the community.
- Don't follow tutorials that haven't been peer reviewed. The scientific method is important at the University of Osdev.
- Don't follow tutorials made by the inexperienced.
- Don't follow tutorials without obviously consulting #osdev whether the tutorials are bad and whether there are errata.
- Don't blindly follow tutorials: Some tutorials give very bad advise. Some are buggy. The best ones have bugs only experts notice and you won't until things explode.
- Don't write a bootloader unless you must. Use an existing one.
- Don't write an operating system in assembly.
- Don't do crazy real-mode stuff.
- Don't do FAT lest you give your VFS brain damage.
- Don't make it hard to turn your half-assed work into something proper lest you spend lots of time fixing it.
- Don't assume your small project never goes anywhere.
- Don't use \ as a path separator.
- Don't use flat binaries: They are too simple and contain no information where they are loaded. Use ELF instead.
- Don't listen to your own advise. He is a newbie and might not know it. You'll hate his code deeply a few years down the road.
- Don't try to replace C or Unix without truly knowing what's wrong with it and what's good about it.
- Don't use newlib. Use musl.
- Don't do black magic. You're trying to be cool and failing at it. If this is the proper way to do it, declare this the normal approach and think nothing special of it; otherwise do it the proper way instead.
- Don't use code you developed while sleeping. You were unconscious. Do you code well when you are really tired?
- Don't leave proving the code is correct as an exercise for the reader.
- Don't follow operating systems development tutorials on Youtube: They are not community edited and tends to be made by the inexperienced.
- Don't proclaim me a master of osdev and quote my holy words in #osdev.
- Don't write tutorials if you're inexperienced.
- Understand what your goals truly are and what you want from osdev.
- Take osdev seriously and do things well.
- Don't play the role of an operating systems developer, be one.
- With every incompatibility come a price that must be paid.
- Corollary: Pick your battles.
- Read instructions carefully.
- Take correctness seriously.
- Correct code is secure.
- Know your programming language well.
- Know your ABI well.
- Know your toolchain well.
- Be truly afraid of undefined behavior.
- Use a modern, good Unix for osdev.
- Use UTF-8 (no BOM, Unix line terminators).
- Your operating system should be itself, not fight what it is.
- What other operating systems do: Embrace it, or fight it. Don't half-adopt it.
- Use a cross-compiler.
- Follow Bare Bones.
- Follow Meaty Skeleton.
- Initialize at compile, link or load time, not run-time.
- Enable paging as soon as possible.
- Have a pre-emptive kernel early on.
- Implement Ext2 as your first filesystem.
- Make a OS Specific Toolchain when you add a user-space.
- Quote me in your forum signature.
- Be an expert.
Naively Closed Source
- Main article: User:Sortie/Naively Closed Source
Just release your hobbyist OS source code already.
It would seem customary to have such a list on your user page, so here goes:
- Bare Bones (Rewrite)
- Building GCC
- Calling Global Constructors
- Creating a C Library
- GCC Cross-Compiler (Rewrite)
- Why do I need a Cross Compiler? (Rewrite)
- Meaty Skeleton
- OS Specific Toolchain (Rewrite)
- Hosted GCC Cross-Compiler
- Stan Dard
- Cross-Porting Software
- System V ABI
- James Molloy's Tutorial Known Bugs
- Host Triplet
- Stack Smashing Protector (Rewrite)
- C Library (Rewrite)
- Thread Local Storage
- Hard Build System
- (and various other stuff)