Windows-使用内核驱动程序直接写入视频显示吗？

Question

I am in the process of writing a windows 7 kernel driver. Today, I want to have it output debug information via the display. Now I know that I can just use the DbgPrint or the KdPrint functions, but I want to output my string or anything, directly to my monitor. This way, I don't have to fire up Debug View to see my output. This also serves as an educational exercise.

As I understand it, I will have to access the frame buffer for the display and write my values to it, correct? However, I have no clue how to do this. Basically, I want to be able to write something onto the monitor directly, thus it would overlap anything that windows is displaying. I know this might sound weird, but its just for fun.

The main goal is to do this from a KERNEL DRIVER. Not inside a userland process. Note that I am only wanting to use a 640x480 resolution. Not anything higher. If I understand correctly, anything higher than this would require me to write my own display driver for my current video card.

My system setup: Windows 7 SP1 x86 Intel Pentium 4 @ 3.00Ghz Nvidia GeForce FX 5200

Thanks for all of you help in advance!

Answer 1

Now I know that I can just use the DbgPrint or the KdPrint functions, but I want to output my string or anything, directly to my monitor.

You'll have to go through the display driver. Who says that your computer running windows has a monitor at all?

Even if it has, there won't be a MSDOS-style single framebuffer in RAM that stores your current picture. Modern GPUs just don't work that way any more – instead, operating systems ask them to compose the whole screen of single buffers they hand over for compositing – in simplification: Every window is its own framebuffer, and it's the GPU's job to compose everything to a whole screen picture.

You also can't just write to some memory region from your kernel driver just because you like to do so – a) you don't know where that would be and b) you'd compete with other components, and that would be a bad thing.

EDIT I feel like I should add this for posteriority:

the point is very simple: write a driver that is a driver and not a user interface. That's not the job of a driver. Putting UI functionality into a driver is a bad idea for many reasons, and you simply shouldn't do it.