Idea for a new kernel - amateur, so be nice, please!

[LieutenantHacker]

Ok guys, so I have been gone a while, learned some more stuff, but still have no actual experience writing any kind of low-level software, albeit I have studied on it a lot.

I thought about this kernel (32-64 bit, backwards/upwards compatible, emulation support, multiple file format support) that would have some system software that it comes with (no loader, the software comes natively built within a kernel process), and here are some examples:

1.Kernel process natively designed with multi-clipboard capabilities (the text you copy, ASCII/UTF-8, etc.) will be a kernel process rather than a user-level process. This is a "system-built" process that works with any compatible GUI/text UI system to hold many "slots" of clipboard data, and by hitting the right key combination (e.g. ALT+slot number) the user can bring up whatever copied characters up, and the slot table can be re-order, arranged, and cleared from a GUI program, or through a command interpreter/command line, etc. This has never been done before, and this way if any user-level program crashes you can always still retain the data as long as the kernel process is executing normally.

2.Native emulation support (backwards and upwards compatible execution) enables the kernel to parse/load executable formats in 16, 32, or 64-bit code, and execute them as if they were native (emulation). Also, supports formats from other top executables, and can use native kernel supported processes to create a software compatibility layer. Advantage? No extra programs need to be installed/downloaded, and no user-level programs can stall this as it's a kernel process.

3.Some device drivers are "built in" as well.

Also, higher-design implementations must be taken appropriately to enhance the concept of the "monolithic kernel".

By giving better support to other binaries, having it natively implemented within the kernel, and having the bridge between user and kernel processes shortened makes for a much more speedy system call.

What do you guys think? Any constructive criticism? Remember to keep an open mind!

[Nable]

"Smells like MS Windows spirit."

[dozniak]

Keeping clipboard data in the kernel does not make it safer to save, but opens up various ways to inject malicious data and code into the kernel space.

It is much safer to keep it in a separate user space process.

[bluemoon]

Also note that for 32-bit OS the kernel address space (or global accessible address space) is very valuable, the less required by kernel, the more application can make use of them.

Keeping multiple clipboard data in the address space, may greatly reduce the usable address for application, try copying a few screenshot images of each 8mb, or in extreme case a few photoshop layers which take hundreds mb of memory.

[bwat]

I think everything you mention has been done before, or solved in a better way: the clipboard in Smalltalk-80 (the language is the OS), backwards compatibility with any microcoded system. Note that these ideas are at least 30-35 years old.

That said, you should probably go for it. By your own admission you only have "know what" experience, and making a real go at implementing these facilities will give you that "know how" experience you lack. Succeed or fail, you will have gained something. Good luck!