OSDev.org

as seen on "Gui Desing" thread ...

mystran wrote: If 3d acceleration was not such a pain to support (that is, if 3d card vendors where a little more cooperative) one could even make each window a texture, and do all the fancy effects in hardware!

That might lead to nothing, but i collected all i could figure out from NVidia drivers into the WikiFAQ. I'm not 100% sure about it, but i think it could be possible to use the closed-source nv-kernel.o in the same binary as the OpenGL library so that you could bypass linux "/dev/nvidia?" thing and directly perform OpenGL operations from your video driver...

The underlying question is, how hard will it be to support Windows Drivers? (Not Windows programs)

If you support the Windows file format, it's mostly downhill from there. Other than that, hope your OS hits big and gets its own drivers. Some might be into dis-assembling the driver.

Supporting Windows drivers is easier than supporting apps but still not that easy, the Kernel API provided to drivers consists of almost 2000 functions (HAL.dll, NTOSKRNL.exe, BOOTVID.dll and KDCOM.dll), it would also seem possible for drivers to load other DLLs in as well but these 4 are the main ones. [This is for XP, 95/98 have a different model, NT has a different one again, ME has its own as well, 2000 and XP have similar (but still slightly different) models, "Longhorn" has a new driver model again as well]

Not to mention the fact that it also puts your OS as a slave to Windows (you may have to change your Kernel design, be forced to have a monolithic kernel, or at least a kernel space C library in the form of a NTOSKRNL.exe emulator, and you also get "virus drivers" and the other joys of Windows too).

I personally would rather examine and adapt Linux drivers, it'll be more work porting individual drivers but at least I'm in control of the driver model. If your OS becomes popular enough, the fact that the drivers are GPL (since they're based on Linux) means that someone else can do the work of maintaining them for you .

One should also remember that "a windows driver" might not actually be a pure driver. There are quite some windows drivers that need half of Win32 to function.

Hi,

AR wrote:Not to mention the fact that it also puts your OS as a slave to Windows (you may have to change your Kernel design, be forced to have a monolithic kernel, or at least a kernel space C library in the form of a NTOSKRNL.exe emulator, and you also get "virus drivers" and the other joys of Windows too).

Not to mention that some these device drivers probably have copyrights - you may not be able to distribute them as part of your own OS (e.g Microsoft's floppy disk driver code). Expecting potential users to get the device drivers from a Windows installation CD before using your OS wouldn't exactly look professional.

Using device drivers from any other OS makes your OS (and/or OS design) a slave to the other OS.


Cheers,

Brendan

ALL YOUR hWnd's ARE BELONG TO US!!!

But really, if you come up with your own design it's best to first write your own drivers for standardized hardware, then try and get specialized ones. But never expect Windoze or Linux or Mac drivers to be compatible with yours.

Crazed123 wrote: But never expect Windoze or Linux or Mac drivers to be compatible with yours.

I never meant binary compatible. I just mentionned the specific fact of nvidia driver for linux, which is closed source but made in a way that it could be easier to integrate in your own system that what it could look at first sight. i thought ppl could be interrested by this.

Of course, there will be glu to write and that glu will have to be maintained when nvidia release a new driver. I don't think that makes you a "slave" of linux nor of nvidia. That makes you able to use the 3D power of your video card.

And again it's time for me to point out that, in the late 90'ies, a driver architecture was conceived that would have brought us drivers that are binary compatible across operating systems, and source compatible across hardware platforms.

It didn't hit big because a) apparently the money spent on the project by the big 'uns ran out, and b) the oh-so-"free" Richard Stallman had an axe to grind with what would ultimately result in an even ground for all operating systems to compete in. (That was when I lost the last bit of sympathy I held for this dinosaur.)

Granted, it currently works "only" for SCSI, NICs and USB (example implementation available at SourceForge), but the concept could be extended to work for graphics and sound as well.

If asked for the number one thing that should have hit it big, I tend to name UDI even before Amiga, and that should mean something. ::)

I was wondering if someone reverse engineer a close source driver to understand how to use the hardware, is it allowed to do a new driver using this information ? I mean a completely new driver, just using information learned by reverse engineering...

I know that was done for a lot of drivers, like usb modems for linux, but I think the manufacturers were fine with that. But with the hardware graphic war, maybe it will not go through.

By the way, I know that graphic driver does a lot more than just hardware abstraction, but we just need to talk to the hardware, after we can do whatever we want.

Reverse Engineering is permitted in some countries under a "you may reverse engineer this product to achieve compatibility" clause that cannot be denyed by the author, it will depend on where you are though.

But if i do that and then send the info i got (not source, just info) to someone that is located in a country where it's illegal?

bubach wrote: But if i do that and then send the info i got (not source, just info) to someone that is located in a country where it's illegal?

In all countries (except the US) that's legal to do. You got the information in a legal way, you wrote it down because you figured it out and somebody else got your notes which is also legal.

The US will sue the sh*t out of you though, even though you didn't do anything wrong in that country. Too bad they kind of got a way to convince other countries (for those who didn't notice, cynical) whereby you might be extradited to the US to suffer punishment for your awful acts of not behaving according to the law some 5000 km away. Bunch of arrogant ******.

Anybody actually has a list of where you can and where you cannot do stuff like this? It seems like a cool thing to do, but I'm currently in Northern-Ireland for half a year, and will be 'back home' after that in the Netherlands. Thing is, I'm not really in the mood to get my *** kicked because I got something working and told my friends about how to do it.

Twisted world...
"Look, I got it working this way!"
"You what?? We sell you a product and you're able to use it?? You CRIMINAL!"

has anyone try to study the file format of the drivers. The driver file would have a list of function that the file "implements" and its offset into the file, so all you would have to do is load the file and change that part of the call table to reference the function in memory. or how else would depends work (show the dependencies of a binary file).

Loading a driver is easy, that shouldn't be a problem for anyone, the problem is that the driver calls out into other OS specific libraries (the kernel, dll files) which also need to be emulated, as I said with Windows, there are 2000 functions that MUST be provided at the minimal level, and as mystran said, quite a few drivers also have a user level counterpart which requires half of Win32 to work properly.

Binary compatibility with Linux Kernel modules would be easier to achieve since there are less functions to provide but it would require a lot of maintenance since drivers are part of the kernel, every kernel revision means having to update the compatibility layer.

As to reverse engineering, I found a document on Google: http://www.jenkins-ip.com/serv/serv_6.htm it essentially says that in Europe and US [doesn't mention anywhere else unfortunately] you may reverse engineer to create a compatible product, here's the provided list of requirements:

# It must be indispensable to reverse engineer to obtain the necessary information.
# The reverse engineering has to be by a licensee or authorised user.
# The necessary information must not already have been readily available to those people.
# Only the parts of the program necessary for interoperability (i.e. the interfaces) can be reproduced.
# The information generated by the reverse engineering cannot be used for anything other than achieving interoperability of an independently created program.
# The information cannot be passed on to others except where necessary for this purpose.
# The information obtained cannot be used to make a competing program (rather than just an interoperable one).
# The "legitimate interests" of the copyright owner or "normal exploitation" of the program must not be prejudice.

Apparently you have to satisfy every one to reverse engineer legally, they don't look hard to satisfy but unfortunately we can't share any information we accquire unless the other person is a member of the same project