Building a system on bare hardware is one of the most inspiring and exciting engineering project I can think of. Blow life into dead hardware: no libraries (Iíll make them), no run-time (where is malloc?), no debug, everything is new and have to be (re-)written.
For me itís getting my hands dirty: get an old pentium from the garbage with floppy, connect to my pc with a null-modem cable, put some old pci graphics card in it I have register documentation to, boot my small multitask os with gui and start hacking, try out different design structures, tasks scheduling methods, watch raw performance, program a few devices, build reusable system components, pass messages, run out of stack, crash, write a C++ string library, try different callbacks, semaphores, anything and everything!
It starts from design ideas on paper, reading and learning tons of documents, implementing and testing over and over again on both virtual and real machines. Getting lost and finding the way back again. It is everything from making null-modem cables to C++ virtual inheritance because of the GUI design... it covers every aspect of computers and system programming.
Of course every OS developer is somehow biased. Iím towards the GUI. The interface, we humans, meet simultaneously running programs in a computer. This highly shared, 2D bunch of pixels, heavily hardware accelerated visual component. It is an euphoria to watch graphics, video acceleration, windows, fonts, happening in front of the eye, enormous amount of data manipulated by these chips at a blazing fast speed!
Still, performance and user experience depend on the software that drives the computer. The operating system and other components. How these invisible layers are doing their jobs, how efficient, big, fast, general, re-usable the os components are determine the system. Just compare the user experience (not the technology and number of colors) of a 7MHz MC68000 Amiga and a 2.4GHz Pentium. Subjective, but I felt much better knowing Iím using the first one..
This is my motivation. To design and implement an operating system software layer for a multitask GUI. The system now is an x86-based PC; a nightmare to deal with but the most commonly accessible hardware and documentation - except exactly the video hardware, but this is another chapter.
My OS is not for x86 anyway.. it only runs on it.
Sure, but very difficult. What to show? WOndERoS is booting on the cga screen and found a 8259 interrupt controller? Hm.. not.. That 2 tasks are displaying 2 gif animations on the true-color screen by re-entrant GUI calls? I like that, it is something but doesnít tell anything what is under the surface. Very difficult.
I think most OS developers fall into the trap of making hardware drivers for the PC instead of developing an OS. I donít blame anybody, I also deal with hardware development, I could say, 70% of dev time(!) instead of designing how to share the screen between tasks and the system, who is responsible for what, where are the boundaries, interfaces where components communicate and how.
And thatís the beauty of osdev. But it is a different design process: one should always think in the implementation in the same time. Ok, I have an idea how 2 tasks can communicate, but can this easily be put in code, C or assembly? How can I use it later, ie. build another communcation layers, on top of it? Sometimes I donít know the answer and when I made a Publisher/Subscriber pattern I had to go back a little bit to the core os messages and change something...