I was thinking the other day that one reason why many hobby OSs end up being used by just one person and for a brief period of time, besides the project being abandoned unfinished, is that it takes a lot of work to develop all the drivers necessary for an OS to be able to do all the things OSs do. An OS without sound or without Internet... or without wide screen is reasonable for a hobbyist, but one would like to be able to build his one OS to actually be the one we use everyday on our PC.

Please correct me if I'm wrong, but without open specs, hobby OS drivers have to rely on reverse-engineering drivers made for other OSs or reading source code of drivers already made for free OSs such as GNU. This is already hard work, but besides, if we want to support more than the most common hardware, it'd take prohibitively long.

Now, somebody must have thought before me that if hobbyists agree to a certain level on the format of their drivers, the same drivers could be used, with little changes, for every hobby OS. Is there any project like this anywhere? If there is an obvious answer to this, please forgive my ignorance and show me the way Thank you, guys!

Perhaps EFI can once and for all solve the driver problem?

But I'm not holding my breath waiting for it to happen.

Uhm... I don't know... BIOS was supposed to do that work too and you see what happened. Besides, the code within UEFI is not free, so a free OS "should not" use it. Also, if we begin to rely on UEFI, then how about Coreboot?

Now going back to shared drivers in theory, I've read somewhere sometime that reverse-engineering proprietary software is prohibited. Yet, I've heard Richard Stallman himself mention in an interview that GNU drivers were developed by doing just that. How is that possible? The man knows about law, there must be a catch. And then... what about publishing specs? Say I find out how to access a certain hardware, so I write my own specs to it (not the original ones). Is it legal for me to distribute these specs I wrote?

It first started with Compaq (IIRC) doing a BIOS clone. If you do it "correctly" you have something like "dirty" people that reverse and read the original code and turn it into a spec. And then "clean" people that have never seen the original code; they take the spec and write new code. Or something like that anyway. Besides, not all countries have such laws that require measures like that.

There are a lot of contributing factors that make this difficult and I've hit plenty myself. Be it standards/specifications and their degree of openness (plus working around implementations that don't adhere to these standards), the design/layout of your particular OS (runtime, built-time interfaces/API and code base), the tools you use, the architectures you wish to support (which may impact all of the previous) and many others.

While this doesn't make it impossible, it requires a lot of supporting code/wrapping to accommodate all of these variations, making it hard to maintain; particularly when it comes to the security vs speed question. Basically there will be at least two implementations of everything - probably closer to 10 to cover all the cases. Then it has to be well-documented as well as actually usable

You are right that most hobby OSs end up duplicating the "basic" stuff that could potentially be wrapped up into a nice little library and ease the pain for some

Thanks! Yes, it's sad that we have to get stuck just when the OS would start to become useful. This, of course, isn't coders' fault, but it's the fact that the PC is not just one thing, but lots of different (and very dynamic) technologies that have to be supported in order to have a complete system up and running.

I think that, without some level of cooperation, only a few hobby OSs will reach the "useful" level. But my concern is that most hobby OSs, that is, the typical hobby OSs... say... a one-person work, is doomed to be abandoned. Of course, coders learn from working on them, but it'd be nice to go further. Certainly, OSs that are already designed from scratch without looking for driver-compatibility with others will be hard to support under a common driver structure, but on the other hand, new OSs could be designed thinking of this in advance. It's not necessary to make the whole system compatible; just the drivers. And well, this is FASM, so we're talking about Intel/AMDs and Assembly. We wouldn't need to provide support for other platforms. At most... 32bit vs 64bit.

Anyway, you are right. I realise it's still hard. I just would like this idea to remain in people's mind from time to time so that at some point, maybe we can build something on it I mean, it can't be harder than what we're already doing by building one OS per person alone!

> only a few hobby OSs will reach the "useful" level

IIRC only one hobby OS reached a "useful" level (more accurately: useless but used by everybody nevertheless) so far: MS-DOG (later renamed into "Windows" ...).

> takes a lot of work to develop all the drivers necessary for an OS

very true

> somebody must have thought before me that if
> hobbyists agree to a certain level on the format

This (create a common driver standard for multiple OS'es) had been thought and tried already 1'000'000'000'000 times. Result: failure. The only thing people can agree about is, that everything must be 100% compatible with Windaube, so they end up with the situation that nobody uses hobby OS XXX, not even the author oneself, but everybody uses Windaube, and YES, it must be the latest and greatest one (XP is dead, welcome Windaube 9/XXX64 !!!

By the way, I have a slightly different opinion: don't create a "new" driver standard for old hardware, but create a new (much simpler) hardware standard, together with a new FS (much simpler and more efficient), and new programming language (much safer than C and with better syntax).

perhaps the single greatest part of "hobby" is the freedom to let your imagination run wild. imposing "standards" within the kernel has far reaching implications in OS development so "standard" drivers are not something to take seriously.

It SHOULD be possible to do this in UEFI, in the form of EFI Drivers. That would be your multiOS "compatibility layer". May also want to read this
http://board.flatassembler.net/topic.php?t=17261



The current status is not comparable to what happened originally with the BIOS. The BIOS provided services for OSes, but these services were hardcoded and pretty much only worked for the original Hardware supported functions of the PC IBM Hardware. You still needed OS level Drivers for any other non supported Hardware. Basically, as newer Hardware appeared with its own Drivers needs, BIOS became obsoleted for that purpose. But in the current API-driven world, you could make EFI Drivers, a standarized API, and let hobby OSes it.
Also, this is not related to Coreboot at all. Coreboot itself just initializes Hardware, it implements BIOS compatibility and services via SeaBIOS, and can also support UEFI with TianoCore.

Maybe this should help? http://wiki.osdev.org/Uniform_Driver_Interface
Beware though, UDI is quite complex to implement, not really of a killer but hard.

Lately, I'm thinking the same like the OP but in wider scope such as an initiative to collect all of those open source OS source codes and turn it into a reusable OS building libraries in FASM includes tree similar to FASM libraries itself.

Various bootloaders, kernels, drivers, memory management, so on and so forth. Even the original OS creator also contribute to these OS building libraries under FASM so a new hobbyist OS no longer stuck in the beginning level. By objectify every level possible in OS making, the progress could advance into intermediate and advance level for hobbyist OS maker.

DexOS/MikeOS, Kolibri/Menuet, Linuxes and ReactOS could be a good resource to be started with to build this OS Building Libraries for FASM.

There's also these interfaces, for your review:
EDI - http://forum.osdev.org/viewtopic.php?f=15&t=16592
CDI - http://lpt.tyndur.org/cdi/english/