How To use INT DOS in Protected Mode

[smiddy]

Nevetheless all modern operating systems (f.ex. linux, windows) use their own low-level drivers. The x86 BIOS is merely a relic of the 16bit real-mode days that is today hardly ever used for anything more than boot-strapping. It never managed to make the step to a modern architecture and its support for modern devices is still very limited.

No argument from me here, I agree. However, I think you can learn a wealth of information by programming an initial cut at an OS, especially in the learning mode. I don't believe this is a professional setting either...{More below}

In my opinion the decline of the PC BIOS is mainly due to its limited interface. The services it provides are too high-level taking control from the operating system. Another point is the lack of a official standard that would allow the operating system to rely on the services.

Point taking, I think hardware manufacturers are getting out of the game of providing a standard for a Basic Input Output System. I believe the industry is heading down the ACPI path too, which is a lot to digest for someone just starting out, in my humble opinion.

In last few years the PC BIOS regained some importance as ACPI and SMBIOS became mainstream. At the same time hardware companies are developing the UEFI standard to establish a more powerful and modern firmware system. If this attempt succeeds I'll be more that happy to use the built-in graphics driver, rather than having to write my own support. For the time being you're in my opinion better off ignoring the BIOS.

Uhm, this is a tough point seeing as I think ACPI and SMBIOS are BIOS works, just more evolved perhaps than their predecessors. Unfortunately I think the lack of a standard increases the hobby-ists workload in trying to make their OS compatible without it.

Why bother about a proper system design if DOS does everything for you ?

I think in order to learn. I believe there are several stages of the learning process in order to get to a more evolve position, which is where I surmise you must be.

You seem to somewhat overestimate the amount of drivers that would be needed. Almost all of the devices that can be found in a modern computer are based on an open standard, so that you only have to write a single driver for each device class. I would also be very surprised if the BIOS supported any of the non-standard device..

You may be right, I think I say that mainly out of ignorance, but I think more because I expect to use every aspect of every device. If I can do that I think I can use the device more fully. This may be too anal I my own part. I think a basic device driver for classes of devices is somewhat weak in that you can't fully realize the full potential of the device. I submit though you can have a working OS otherwise, and that that is my own opinion due to my own anal approach to devices.

Though over all, from your theme, I think we're here as hobby-ist of OS design and are not pushing the potential of the latest OS designs. Most people here are eager to learn the basics first and then if so inclined after realizing the task at hand, can peruse more evolved designs.

[Dex]

@gaf, 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.
Note: prof is a example, not a doc that says you can do it.

[gaf]

Uhm, this is a tough point seeing as I think ACPI and SMBIOS are BIOS works, just more evolved perhaps than their predecessors.

Actually I was mostly refering to the traditional 16bit BIOS when I wrote that paragraph. ACPI is something different, not only as it's much more advanced and modern, but also because it provides some functionality that is impossible to achieve otherwise.

Nevertheless I wouldn't try to implement it as a hobby OS developer. Its huge complexity makes it a large project in itself that would just keep you from working on your actual operating system. In my opinion power management isn't that important for a hobby operating system anyway. For device detection I can still use PCI probing, which should be way easier to implement.

I think a basic device driver for classes of devices is somewhat weak in that you can't fully realize the full potential of the device.

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.

An example would be the ATA/ATAPI interface that is used by all IDE devices. If you have a driver supporting it you should be able to access all hard-disks, cd-drives and dvd-drives that have been built in the past last two years, except for SCSI devices of course.

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.

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).

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.

I admit that it's quite a lot of work to develop 3 graphic drivers, even if you can copy and paste from the linux source. As there are also no real advantages of a driver (except for the basic 2D acceleration) I'm actually planning to use a VESA framebuffer for my operating system. It should be simple enough to tell GRUB to set the LFB mode while still in real-mode, especially as the necessary memory structures are already there.

regards,
gaf

[Dex]

@ gaf, Well written answers, but from writing alot of these drivers myself, they are not all they seem, for example many drivers Mouse, ATAPI, need parts setup in realmode, if not you can get problems, also take AC97 as a example, one codex one driver, but its not as easy as that differant vendors set them up totally differant, you need at least 10 AC97 drivers to cover most.

[smiddy]

Sorry about this quick reply, I'll come back when I have time, but I saw this on mega-tokyo: http://www.mega-tokyo.com/forum/index.p ... 0#msg88616

Thoughts?

[xavmoss]

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

[gaf]

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...

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.

It's impossible to call DOS services from protected-mode. The only solution is to return to real-mode for the interrupt. Just have a look at the code smiddy posted to find out how it can be done.

regards,
gaf

[smiddy]

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...

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.

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).

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.

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?

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.