OSDev.org

I have done similar things before. I need something that starts form the very basics and is more complete. Similar to all those books you have on amazon, but with examples and real code. Something that shows general overview of how to interface and program hardware at the lowest level. Terminology, concepts, approaches, and the way I interface with it, starting from the very beginning.

osmaster wrote:Something that shows general overview of how to interface and program hardware at the lowest level.

There are hardware registers. Just like those the CPU has. But now the registers are used for a different piece of hardware. Examples of it - keyboard controller, USB controllers, video card, sound card, etc. To work with a hardware you should know addresses of the registers. The address can be a memory offset (just a plain memory address) or IO port number. If you know the address then you can interact with the hardware. The interaction looks like this - you write some number (a code) into the hardware register using mov or out CPU instructions. Next, the hardware goes through a long C-style switch (you can think of it this way) and executes an internal operation, corresponding to the found code match. After the operation is executed hardware can call your code using interrupts. But sometime it requires you to poll the result yourself. Anyway, to get the result you always need another address - the address of the output register. You access the register's value using mov or in CPU instructions. The result is another code that you should convert in an action, specific for your goal. And it's almost all you have to know to interact with hardware.

But for your interaction to have at least a bit of common sense you should know what you want, what hardware can do and what is the mapping from your wishes to the hardware actions. Usually the hardware can be represented as a logical model of something (a finite state-machine or a channel which supports some protocol or something else). So, you must know the model to work with the hardware. Here the work means something sensible and not just a dumb interaction. But the hardware's models are complex today. However, you can start form something very simple.

Something very simple in the x86 architecture is the interaction with textual display. The model here is as such - you have an array of characters with every N items dedicated for a particular line on the screen. Most usual value of the N is 80. The total length of the array is calculated as N*M, where M is the number of lines on the display (usual value for it is 25). Next, the model includes the color for every character. But for the simplicity let's concentrate on the sensible work instead of complete description. The sensible work in this case can be something like writing a character at a particular row and column on the display. So, you first need to calculate the offset in the modeled array where you can write your character. Let's suppose you want to write to the row 2 and column 75. So, the array's offset should be -> (2-1)*80+75-1 = 154. Next you should know the address of the hardware's register you need to write to. In case of the textual display it is calculated as such -> 0x000b8000 + arrayIndex * 2. For our example it will be 0x000b8134. So, you need to write an ASCII character (one byte) to the address 0x000b8134. Just like this - mov byte [0x000b8134], 0x21. And you'll get the '!' sign on the screen at the position 2*75. That's all. You've done some sensible work.

Next you should read OSDev wiki and it's Hardware part in particular. There you can find the logical models for different hardware and some register addresses. At least now you know what to do with the addresses you will find there (but only if you are a real OS master).

Thanks embryo, but you got me back in time, almost 20 years ago when I was a teenager and was doing this. The Windows Driver Model (WDM) has kernel and user mode drivers. The APIs used by kernel mode drivers are roughly 1000, so it's possible to implement loading of kernel mode drivers. Though, the user mode ones use the full Win 32 APIs as indicated here:
https://msdn.microsoft.com/en-ca/librar ... s.85).aspx
So it's not possible ti implement all the Windows APIs for this. I have no idea how many of the drivers are user mode and how many are for free by their vendors.
Also, how many APIs are being used by Linux/Unix drivers. Implementation of the KMDF is not such a big task, it's reasonable if this is less overhead than writing the kernel drivers itself.
UMDF was introduced in 2004 and 2006 with Vista, I guess it builds on the KMDF, so for the utilization of the hardware KMDF is enough. The question is how do we get the number of free drivers that are KMDF, and how many of them are used in Windows.

I just need to get a job and then dedicate time to this. I can't do it on my own, the people in Russia do not want to put a few millions for a good OS, I need serious team to do that. But Kernel framework is more or less what you can come with so you can load the Microsoft drivers ! And have your own framework ! I think it is the right thing to do, it is IO, sync. all basic things, every device functions that way.

I'd just like to point out that the graphics pipeline is as complicated as it is for a very good reason. It's a good idea to learn modern graphics programming before complaining that it's stupid. Additionally, Intel's implementation maps fairly directly to current APIs. In fact, it is likely easier to implement support for the latest version of OpenGL/Vulkan/DX12 than it is to implement the older stuff. This is also how many drivers work these days, they simply emulate the functionality of the old fixed function pipeline in the newer API. Also, the argument that you need a new driver for each device is quite wrong, since every device isn't a complete redesign, incremental updates mean that adding support for multiple devices from around the same time by the same manufacturer is pretty easy. For instance, for Intel HD graphics, even if you wanted to do one driver per generation, you would have a lot of shared code for initialization and memory management (assuming a well designed driver).