Hey, so I thought about partaking a small kernel like a DOS-similar system with only 16-bit computing, no virtual memory, text-based graphics memory only, and input/output done all on one drop-down text screen.
In x86 Real Mode I would have to best implement a flat memory model as best as possible, since I find paging and segmentation to be overly complicating to implement such a basic nature of memory use.
But all in all, what part do you think would be the hardest to manage?
1.Drivers, data control, and/or hardware device access.
2.Memory management across and for the whole OS.
PS: This is no multitasking system and has no "graphics", so that saves time and complexity of PITs, virtual memory managing, graphics mode set ups, and inter-process communication, along with context switches, and even bulk writing work, since a kernel of this moderation can be accomplished in less than 20,000 lines of x86 Intel "DOS/MASM" style Assembly syntax.
The hardest part of writing a kernel is not writing a kernel, but dealing with the native architecture, i.e., call stack, registers, data, processes/threads, memory control directly from and to RAM, I/O with interrupts, drivers, user interface from nothing, no API, etc., etc.
In application programming you virtually never deal any of that, at least not on the architecture level.
You always have an OS under your application to hold your hand.
If your system uses basic I/O then writing drivers for basic hardware should not be terribly difficult.
The difficulty of memory management depends on whether you intend on having only a kernel running, or other programs as well (and if so how many). Over all I think most modern CPU's handle a lot of that for you, you just need to set up the memory (please do not quote me on this).
A file system is also dependent on whether or not other programs are accessing it or not. If so, you would need to set up restrictions so that not any program can access every file.
IMO the hardest part of writing a kernel is ensuring consistency and inter-connectivity between all of the modules so you don't end up with a huge bloated mess of code that becomes un-maintainable almost immediately.
Higher level design concepts are often times harder than low level code implementation.
It depends if you're writing it in cursive or not. On average, of those characters, I think that the "K" is the hardest letter for most people. In cursive, the transition from the "k" to the "e" can be a little tricky.
It's been a long time since my last attempt at kernel development. I've learned a lot more about hardware and it's interaction with software, as well as had a lot more practice with assembly. I think I'll take another stab at it soon O:
int spiderman(int x) // every OS has a spiderman function
return main(x - 1, NULL);
int howdoi(int x)
int shot(int x)
int web(int x)
int main(int argc, char* argv)
I think the hardest part would be adding support for multiple keyboard&mouse pairs that allow multiple people to use the same computer and each have their own window focus. It would be very useful with multiple monitors, too.