User:Sortie

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!

Warranty

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.

Let me know if I am wasting my time trying to give inapplicable advise.

Discouragements

• 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 aren't community-edited.
• 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 and instead 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.
• 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?

Recommendations

• 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 and write secure code.
• Know your programming language well.
• Know your ABI well.
• Know your toolchain well.
• Be truly afraid of undefined behaviour.
• 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.

Wiki Contributions

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)
• Cross-Porting_Software
• 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
• libgcc
• Stack Smashing Protector (Rewrite)
• C Library (Rewrite)
• (and various other stuff)