gaf wrote:
Generic device drivers are by no means inferior to others. The standard defines how to access the device and how to use its funtionality, there are no hidden switches that a specific driver could use.
Sorry if I implied that they were inferior, that wasn't my intention. From a personal preference, I prefer to squeeze as much functionality out of a particular device that I can, for personal pleasure. Generic drivers have their place...
gaf wrote:
It's quite similiar for USB where you only have to write a three drivers to support all available controllers (UHCI/OHCI = USB 1.0, EHCI = USB 2.0). Hardware connected to the USB bus gets divided into a number of classes that consist of somewhat similiar devices. All devices of a class use the same command set and can thus be run by a common driver: If you, for example, support the mass-storage class, your system should be able to handle all usb-sticks, cameras, and hard-disks.
I'll have to take your word for these as I have yet to delve into USB.
gaf wrote:
It's only sound, graphics and networking that really require you to write many drivers. Even there you can still cover a big portion of the available hardware with a a relativly small number of drivers as cards are often based on the same chip-family (AC97, NE2000, RTL8139).
I agree that there are some basic functionalities, but again I'd much rather squeeze all the functions out of the device I can (to my own satisfaction).
gaf wrote:
Dex wrote:
From a hobby OS point of view, how do you get high-res graphics and how do you change graphic modes from PM, without writing drivers for all cards.
To my knowledge the 2D part of most cards hasn't been changed considerable in the last few years as there's hardly any inovation in that area. This allows you to use the same driver for almost all graphic-cards of a manufacturer. If intel, nvidia and radeon compatibles are soppurted by your operating system most of the market should already be covered.
This is an area outside my expertise, however I seem to recall that there are some basic VGA, XVGA, etcetera, functions out there. I seem to recall there are some basic port functions out there for VESA too, but I don't know the specifics.
gaf wrote:
My post is from a mostly theoretical/speculative point of view. Unfortunately I just don't know enough about the Windows driver model to come to any concrete conclusions..
The driver model used by the more recent versions of Windows is called WDF. It seems to be documented quite well and there should be a lot of tutorials explaining the basic ideas behind it.
Just like any of Microsoft's interfaces, WDF is probably a complex and bloated API consisting of zillions of headers. If you want to port it to your OS a lot of time and many developers will be necessary: Expect it to be a big and demanding task comparable with the Wine project.
If the WDF interface manages to separate kernel and drivers there shouldn't be too many problems with the Windows binaries. All communication between driver and operating system should go through the API allowing you to change the kernel without breaking anything. I have some doubts whether Brendan is right when he says that your kernel would have to simulate windows in most aspects to run its drivers. As the internal design of Windows changes quite frequently you can probably expect that Microsoft was smart enough to encapsulate the drivers from the rest of the system.
Running Windows drivers on other systems should be feasible. But at least for a hobby operating system the amount of work required to port WDF is just too huge to make it a real option. Apart from that I somehow refuse to jump through all these hoops just because some manufacturers can't provide documentation for the products. At the very least they could release platform independant binaries...
There was an initiative out there for a standard driver interface but it hasn't taken hold unfortunately. Was it UDF? Anyhow, with so many manufacturers wanting to make their devices proprietary it makes it difficult to do what I like to do and that is squeeze everything out of the device possible. IBM used to sell technical references, but I haven't check on other manufacturers to see if they do, perhaps that is another avenue?
xavmoss wrote:
I'm sorry to ask again. I want the interrupt DOS work in protected. I tried to copy IVT segment to IDT. But it can work, can you give me any sugestion. Thanks
No sweat, you're delving into the history of what is what within the PC, which isn't entirely openly available on the web. In order to use the DOS interupts, as gaf points out, you'll have to go back to real mode to use them. Unfortuneately it isn't as simple as copying the 16-bit (this is a key component) IVT into the 32-bit IVT, well actually you can, but in most cased a call to a 16-bit INT will run into issues. Your main issue is running into the useage of 16-bit memory for variables and the associated registers for the CPU. Calling them from protected mode can have unexpected results. Another problem is that in protected mode the first few INT are reserved. A read of the Intel manuals.
If you use the code I posted you'll want to insure you don't write over areas that both DOS and BIOS use for updating. Otherwise you should be ok using the interrupts from the routine above.