OS Development: GPU Drivers?

[BenBowen]

Okay, I am quite curious; I want to know how practical it would be to make a brand new OS capable of interfacing with a graphics card, using a driver which may be designed for other circumstances (a different OS). Honestly, I don't know any thing about video-device drivers...

1. Is there an efficient method?
2. How hard would it be to do? (e.g. making an OS compatible with another OS's video-device drivers)
3. Is it legal? Would it require reverse engineering? Doesn't Microsoft provide a plenty of information about Windows?

My reason I want this:
I want to develop an OS which can support accelerated-graphics and handles its GUI flawlessly (more careful with the painter's algorithm .etc), however rather than windows or linux, it will use a philosophy much different than the concept of "files" and "folders" (entirely different). I also want the experience and bragging rights, you know.

[Mike]

Hello,

Some video card manufacturers release specs for their cards allowing device driver development for those cards to support hardware acceleration. Thus an alternative solution is to simply write your own drivers.

1) There is no efficient method. Windows and Linux provide driver APIs that device drivers use, a long with MMIO and PIO hardware access. In order for these drivers to function under a different OS, not only do you need to provide the support for it in a driver API, but you will need to maintain binary compatibility.

2) Very hard. Not impossible however.

3) It might not be legal - probably depends on the licensing terms for the driver program.

An alternative solution would be to implement a standard, such as UDI. By supporting UDI completely your OS will be capable of running any UDI compliant device driver regardless of OS, in binary form.

[BenBowen]

Thank you.

http://www.projectudi.org/

[Andyhhp]

Just to add my comments:

1) And also play "guess what cryptic assumptions the driver makes about memory layout etc" which is arguably an order of magnitude harder than the already challenging "write an OS shim" so the driver thinks it is running on 1 operating system while it is actually running on another.

2) Harder than trying to reverse engineer the current driver and see how it prods the hardware to make things happen.

3) Almost certainly not legal under the licencing terms vendors tend to ship with. [1]

~Andrew

[1] For comedic value, do you realise that you are explicitly fobidden from using any Apple software to develop, design, produce or manufacture any form of nuclear missiles, checmial or biological weaponary.