Write to screen inside kernel driver

NTDEV
21

On 6/9/2010 10:49 AM, b@if0.com wrote:

Hi Peter, no, I’m afraid, it has to work on any computer, Win2k, WinXP, or Vista. Not 7 yet thank God! :smiley:

Windows 7 is easier to work with than Vista, in my opinion.

I spent my day trying stuff of the sort of EngCreateBitmap, with no result.

That won’t work, for several reasons. Only a GDI driver can call into
Win32k.sys, and you still can’t get a handle to the visible surface to
display anything.

Jan, I guess I will have to look into the DirectX memory window idea of yours, but will it work even on a plain Windows2k machine, without any additional DirectX installations?

You should always be able to use DirectDraw to get a pointer to the
primary surface. Although I guess I don’t actually know whether that
works with WDDM.

Philip D. Barila, not sure what you mean about someone else. The system stays in Kernel mode for up to 1 hour, being 100% busy with the driver, nothing else works, no dispatcher, no other threads.

Interesting. Then, why have Windows involved at all? Why not reboot
into an RTOS environment where you are in complete control, where you
don’t have to worry about being a good neighbor, where you can dance on
the graphics bits with impunity?

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

22

OP, I had missed that you are trying to meet a hard realtime requirement in
your first query. You do know that Windows doesn’t do realtime, right? At
best, you are approximating it by hogging the system for a long period of
time.

My question to you was, what was the use case. The answer to that is you
are trying to make it realtime. My follow up is, why are you trying to
approximate realtime on an OS that just can’t do realtime without
third-party extensions? What is the problem you are trying to solve by
burning all cores for an hour in the kernel? Surely there must be a better
way than trying to do that in Windows.

Phil

Philip D. Barila

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of b@if0.com
Sent: Wednesday, June 09, 2010 11:49 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Write to screen inside kernel driver

Hi Peter, no, I’m afraid, it has to work on any computer, Win2k, WinXP, or
Vista. Not 7 yet thank God! :smiley:

I spent my day trying stuff of the sort of EngCreateBitmap, with no result.

Jan, I guess I will have to look into the DirectX memory window idea of
yours, but will it work even on a plain Windows2k machine, without any
additional DirectX installations?

Don, thanks, I might have to go the good old Text Mode way, and then reset
the computer when finished, I have an Out port from the good old days that
still seems to work, does a hardware reset :smiley:

Philip D. Barila, not sure what you mean about someone else. The system
stays in Kernel mode for up to 1 hour, being 100% busy with the driver,
nothing else works, no dispatcher, no other threads.

23

Jan, thank you very much, looks very promising, will play with it tomorrow and let you know, that’s exactly the dream of getting a simple video memory area of a fixed format (e.g. 16 bit/pixel) where I can easily write some thin vertical lines, one at a time for my progress bar, so that users have any idea when it will finish!
I remember the DD overlay working with TV adapters as far back as Win 95!

Phil, the way I’ve done my driver, it runs so well in Real Time, no delays or problems (I can hear it, I have the sound going, good old PC speaker I/O), as no other threads are running, only hardware interrupts. That was my first thought too months ago, to make it without Windows, but Windows is so useful for having the drivers ready; I do use some of them in my driver, and of course the internet connected user interface. It has to work on ANY computer with W2k till Vista.

24

Modern graphics cards still have to support VGA mode and text mode. The good old registers/int 10 call still have to work in the old way because most PC system boots from text mode. if you got an ATi or nvidia card designed for Apple, it might be different.

What the OP could do is write an app to enter full screen mode, then set the video to VGA and take control of it as any dos program, when it’s done, exit back to windowed mode. The OS should/would call video driver to set mode if I recalled correctly.

Modern display driver has many funny interactions with the OS as well as the SBIOS and VBIOS. To get a better chance not to crash, I’d suggest not to install the vendor video driver at all.

Personally, this doesn’t qualify an engineering solution but I don’t have a better suggestion.

And people are right here saying video/graphics systems do not use IRP to draw.

Calvin Guan
Former ATi Radeon Driver Developer
Now network & storage

25

> -----Original Message-----

From: xxxxx@lists.osr.com [mailto:bounce-414186-
xxxxx@lists.osr.com] On Behalf Of b@if0.com
Sent: Wednesday, June 09, 2010 2:02 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Write to screen inside kernel driver

Phil, the way I’ve done my driver, it runs so well in Real Time, no delays
or
problems (I can hear it, I have the sound going, good old PC speaker I/O),
as
no other threads are running, only hardware interrupts. That was my first
thought too months ago, to make it without Windows, but Windows is so
useful
for having the drivers ready; I do use some of them in my driver, and of
course the internet connected user interface. It has to work on ANY
computer
with W2k till Vista.

So you’ve turned your windows system into a single-tasking DOS box. Bravo.
I’m going to stop asking why.

Phil

Philip D. Barila

26

On 6/9/2010 1:17 PM, Philip D Barila wrote:

So you’ve turned your windows system into a single-tasking DOS box. Bravo.
I’m going to stop asking why.

As someone who does work for companies doing telemetry and real-time
data acquisition, I can think of lots of reasons WHY you would want to
do this. What I don’t quite get is why you would want Windows there in
the first place. There are a number of simple, single-task, embedded
operating systems that would seem to be a better fit.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

27

> So you’ve turned your windows system into a single-tasking DOS box.
Bravo.

I’m going to stop asking why.

Since we now have 8 or more processor cores on many machines, I actually
think it would be reasonable to have a way to give a driver dedicated use of
some of the cores (like a registry setting to reserve some cores during boot
and an API or two to start/stop executing on those cores). It seems a bit
silly that a $2 microcontroller can respond to hardware events faster than a
modern $300 x86 CPU. There are interesting hardware designs you could do if
you knew there was a processor sitting there polling the hardware. This way,
you could pretty easy have the rich features of an Internet connected GUI
operating systems, while you also get real time hardware access.

Jan

28

“Jan Bottorff” wrote in message
news:xxxxx@ntdev…
. This way,
> you could pretty easy have the rich features of an Internet connected GUI
> operating systems, while you also get real time hardware access.
>

Now that comment makes a lot of sense to me and it’s beyond my imagination
to have an idea why this isn’t happening. It would be trivial to add a
reserved CPU feature to the scheduler and that would add some great features
to the OS.

//Daniel

29

> Don, thanks, I might have to go the good old Text Mode way, and then reset the computer when

finished

Well, this is possible.

InbvEnableDisplayString.

Also consider using Server Core for the machine with your driver.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

30

“Jan Bottorff” wrote in message
news:xxxxx@ntdev…
> You could potentially write a DirectX app that maps a display surface
> bitmap. You could then pass the address of that surface into a driver and
> if
> you write to it, the bitmap will show up as bits on the screen. You can’t
> call any of the API’s, like for text output, so you need to deal with
> bitmaps directly. This is not unlike a video capture preview window, where
> the hardware DMA’s directly to a overlay surface. Not sure how any this
> will
> interact with modern display technology like DirectX 10.
>
> Jan

If you remember SoftICE, it could draw its text window on top
of graphic screen, without switching to the “real” text mode.
But, IIRC, it drawed text using its own fonts rather than use BIOS
int10-like fonts.
Perhaps this is a bit more difficult chore than the OP wants to implement.

Regards,
– pa

>> -----Original Message-----
>> From: xxxxx@lists.osr.com [mailto:bounce-414091-
>> xxxxx@lists.osr.com] On Behalf Of b@if0.com
>> Sent: Wednesday, June 09, 2010 5:47 AM
>> To: Windows System Software Devs Interest List
>> Subject: [ntdev] Write to screen inside kernel driver
>>
>> Hi, I’m developing a real time W2k/XP/Vista kernel mode driver that uses
>> 100% of CPU (all cores!) and works for minutes/hours.
>> I would love to display a progress bar or anything simple on the
>> screen/window so users can still know it’s working. (At the moment I’m
> just
>> making a PC speaker sound by flipping the I/O port!) Is there a way to
> show
>> something simple on the screen, a pixel, a line, a progress bar,
>> anything,
>> generated from this driver? (The driver is real time, the Windows
> dispatcher
>> is off, therefore cannot have a user mode thread)
>>
>> I hope there is, if not, there must be a way to turn the screen into full
> screen
>> text mode before entering the driver, same as the console does, and then
>> just write ASCII characters directly to the display memory (good old
> days!).
>>
>> Any advice will be much appreciated :slight_smile:
>>
>> Michael.
>

31

“Jan Bottorff” wrote in message
news:xxxxx@ntdev…
…
> Since we now have 8 or more processor cores on many machines, I actually
> think it would be reasonable to have a way to give a driver dedicated use
> of
> some of the cores (like a registry setting to reserve some cores during
> boot
> and an API or two to start/stop executing on those cores). It seems a bit
> silly that a $2 microcontroller can respond to hardware events faster than
> a
> modern $300 x86 CPU. There are interesting hardware designs you could do
> if
> you knew there was a processor sitting there polling the hardware. This
> way,
> you could pretty easy have the rich features of an Internet connected GUI
> operating systems, while you also get real time hardware access.
>
> Jan

IMHO this is a good idea. QNX or some other RT OS I’ve read about, seem to
have
this ability.
–pa

32

[Allow “core allocation” to Win / RTOS tasks]
JB> This way you could pretty easy have the rich features of an
JB> Internet connected GUI operating systems, while you also
JB> get real time hardware access.

On 06/09/2010 11:11 PM, xxxxx@resplendence.com wrote:

Now that comment makes a lot of sense to me and it’s beyond my
imagination to have an idea why this isn’t happening.

Security problem: If one or more of the cores are not under OS control,
all your expensive DRM protection efforts go down the drain.

(Just to help your imagination… :slight_smile: )

It would be trivial to add a reserved CPU feature to the scheduler
and that would add some great features to the OS.

Until five different program(mer)s want to reserve one core each for
RTOS tasks on a quad-core system.

Hmmm… what about running a Windows GUI in a VM on a system that can
be configured to dedicate one (or more) of its processors to an RTOS?

Not as “clean” as having a Windows box with e.g. a PCI card running
another processor/RTOS, or as having one box for the GUI and another one
for RTOS processing.

33

SOLVED SOLVED SOLVED SOLVED SOLVED SOLVED SOLVED SOLVED SOLVED SOLVED

Dear Jan Bottorff, thank you very much for the DirectDraw idea.
I spent days on this, trying overlays etc, which wouldn’t work properly, until I tried a different easier strategy allocating the whole screen as a primary buffer. It took a long time as there is no decent documentation for direct draw anymore.

Anyone who is interested in displaying graphics in Kernel mode by accessing the display memory here it is:
(it’s in C, not C++)

a=DirectDrawCreateEx(NULL, (LPVOID *)&lpDD7, (LPVOID)&IID_IDirectDraw7, NULL);
if FAILED(a) {ErrorPopup(a); return 0;}
a=IDirectDraw7_SetCooperativeLevel(lpDD7, hwnd, DDSCL_NORMAL);
if FAILED(a) {ErrorPopup(a); return 0;}
// primary surface: whole screen!
memset(&ddsd, 0, sizeof(ddsd));
ddsd.dwSize = sizeof(ddsd);
ddsd.dwFlags = DDSD_CAPS;
ddsd.ddpfPixelFormat.dwSize = sizeof(ddsd.ddpfPixelFormat);
ddsd.ddpfPixelFormat.dwFlags = DDPF_RGB;
ddsd.ddsCaps.dwCaps = DDSCAPS_PRIMARYSURFACE | DDSCAPS_VIDEOMEMORY | DDSCAPS_LOCALVIDMEM;
a=IDirectDraw7_CreateSurface(lpDD7, &ddsd, &videosurface, NULL);
if FAILED(a) {ErrorPopup(a); return 0;}
a=IDirectDrawSurface7_Lock(videosurface, NULL, &ddsd, DDLOCK_WRITEONLY | DDLOCK_WAIT | DDLOCK_SURFACEMEMORYPTR, NULL);
if FAILED(a) {ErrorPopup(a); IDirectDraw7_Release(lpDD7); return 0;}
return ddsd.lpSurface; // video buffer addr

I passed the video buffer and all the other screen size parameters to my driver via IOCTL, and now have a wonderful big animated progress bar moving, I remembered my assembly direct screen writing days, made a great colourful and animated progress bar in half day.

34

I found this thread very interesting and must say thank you for posting the
solution.

It seems a good way of transitioning between a Windows environment and “I’ve
got this very fast and cheap hardware on my desk that could do some
fantastic dedicated realtime stuff from time to time if only I could put
Windows on hold”. Then when it’s done you’re back in Windows.

I’d like to ask a couple of questions:

  • Does it in fact it transition back to Windows ok or are the warnings that
    it would screw up Windows screen handling true?
  • Does it violate any Windows rules so this might break in a Windows update?
  • Given that everything else is on hold, which I suppose would include power
    and disk management etc, is there any possibility of hardware damage?
  • Does anyone else see any major drawbacks to this?

Many thanks,

Mike

>>>>>>>>>>

----- Original Message -----
From: b@if0.com
To: Windows System Software Devs Interest List
Sent: Saturday, June 12, 2010 7:04 PM
Subject: RE:[ntdev] Write to screen inside kernel driver

SOLVED SOLVED SOLVED SOLVED SOLVED SOLVED SOLVED SOLVED SOLVED SOLVED

Dear Jan Bottorff, thank you very much for the DirectDraw idea.
I spent days on this, trying overlays etc, which wouldn’t work properly,
until I tried a different easier strategy allocating the whole screen as a
primary buffer. It took a long time as there is no decent documentation for
direct draw anymore.

Anyone who is interested in displaying graphics in Kernel mode by accessing
the display memory here it is:
(it’s in C, not C++)

a=DirectDrawCreateEx(NULL, (LPVOID *)&lpDD7, (LPVOID)&IID_IDirectDraw7,
NULL);
if FAILED(a) {ErrorPopup(a); return 0;}
a=IDirectDraw7_SetCooperativeLevel(lpDD7, hwnd, DDSCL_NORMAL);
if FAILED(a) {ErrorPopup(a); return 0;}
// primary surface: whole screen!
memset(&ddsd, 0, sizeof(ddsd));
ddsd.dwSize = sizeof(ddsd);
ddsd.dwFlags = DDSD_CAPS;
ddsd.ddpfPixelFormat.dwSize = sizeof(ddsd.ddpfPixelFormat);
ddsd.ddpfPixelFormat.dwFlags = DDPF_RGB;
ddsd.ddsCaps.dwCaps = DDSCAPS_PRIMARYSURFACE | DDSCAPS_VIDEOMEMORY |
DDSCAPS_LOCALVIDMEM;
a=IDirectDraw7_CreateSurface(lpDD7, &ddsd, &videosurface, NULL);
if FAILED(a) {ErrorPopup(a); return 0;}
a=IDirectDrawSurface7_Lock(videosurface, NULL, &ddsd, DDLOCK_WRITEONLY |
DDLOCK_WAIT | DDLOCK_SURFACEMEMORYPTR, NULL);
if FAILED(a) {ErrorPopup(a); IDirectDraw7_Release(lpDD7); return 0;}
return ddsd.lpSurface; // video buffer addr

I passed the video buffer and all the other screen size parameters to my
driver via IOCTL, and now have a wonderful big animated progress bar moving,
I remembered my assembly direct screen writing days, made a great colourful
and animated progress bar in half day.

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

35

This appears to be yet another of the endless “I could do so much more if I
could just get rid of that pesky operating system” class of questions.

It is a common failure mode to think that if you have a bare machine over
which you have exclusive control of every byte, that every other machine you
encounter must allow you do have direct access to everything in the same
way. It is one of the hardest things to teach a hardware designer, who is
likely to say “Well, when I have an embedded system with an x86 chip, I can
do and therefore you driver writers are just a bunch of idiots
because you can’t also do ” and ignores the fact that in general, no
general-purpose operating system (Windows, Unix, linux, Mac OS X, Solaris,
etc.) could EVER allow without compromising reliability, safety, file
system integrity, overall performance, screen management, etc.

Before you decide you MUST bypass the OS to “write directly to the screen”
(and I’d suggest using some internal interface such as Direct2D or
Direct3D), can you PROVE that it won’t work in a supported Windows
environment? I’m doing realtime display of mass spectrometer data without
even stretching what has to be done, so I don’t really buy the usual
excuses.

If you are using Vista or later, look into the MMCSS (Multimedia Class
Scheduler Service) as a means of increasing an app’s responsiveness. But
please, please, stop saying “I can do on a $3 dedicated chip that is
doing absolutely nothing else, and therefore I MUST be allowed to do
under an actual operating system that has to support a huge number of
unknown and unknowable applications, safely”. I get tired of hearing this.
What is truly sad is the number of times I have to explain to hardware
designers “that cannot possibly work in a real operating system” and have
them tell me that it is “not their problem” that real operating systems
won’t support their personal agenda, and if they create hardware that would
work in a real operating system, it might cost an extra $1 or $1.50 per
board. Of course, it doesn’t matter that every driver is going to cost an
extra $100,000 to develop, or just possibly not even be possible. If it
runs on a bare machine, that’s validation of the design! (I first
encountered this attitude in a RISC design that was undebuggable, and the
engineers kept saying “the” software would track everything; so there was no
way to read out the stack pointer! I kept trying to explain that there is
no “the” software, and that a belief that “the” software existed was
ill-founded, and I gave counterexamples, which had no effect because the
design was already perfect; never mind that I could not imagine how to write
a debugger, either in-process or out-of-process. The design got no
acceptance in the marketplace, and disappeared by the late 1980s, because
there was no debugger delivered with the C compiler, and a promise that one
never would be)
joe

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Pavel A.
Sent: Thursday, June 10, 2010 5:26 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Write to screen inside kernel driver

“Jan Bottorff” wrote in message
news:xxxxx@ntdev…
…
> Since we now have 8 or more processor cores on many machines, I
> actually think it would be reasonable to have a way to give a driver
> dedicated use of some of the cores (like a registry setting to reserve
> some cores during boot and an API or two to start/stop executing on
> those cores). It seems a bit silly that a $2 microcontroller can
> respond to hardware events faster than a modern $300 x86 CPU. There
> are interesting hardware designs you could do if you knew there was a
> processor sitting there polling the hardware. This way, you could
> pretty easy have the rich features of an Internet connected GUI
> operating systems, while you also get real time hardware access.
>
> Jan

IMHO this is a good idea. QNX or some other RT OS I’ve read about, seem to
have this ability.
–pa

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

–
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

36

Truer words have never been spoken.

The performance opportunities lost, and CPU cycles wasted, all for lack of a fifty cent part. Oh, the stories I could tell…

Peter
OSR

37

Many times the developers think “I need to run all my threads with realtime priority to get the maximum performance”. But this is a false premise. You only need realtime priority when you have a fixed upper limit for a response time. And even in this case there are factors (ISR, DPC) beyond the dispatcher control. The OP should leave the priorities at the default.

Equally false premise is running the code in kernel mode to maximise throughput. Kernel mode threads aren’t given more preference. And there are more restrictions for them, such as smaller stack.

38

On 6/14/2010 9:50 AM, xxxxx@osr.com wrote:

Truer words have never been spoken.

The performance opportunities lost, and CPU cycles wasted, all for lack of a fifty cent part. Oh, the stories I could tell…

True. On the other hand, I was once in a meeting with a rep from a
“major printer manufacturer” who pointed out, “We ship a million
printers a month. If you want to add 5 cents to the cost of goods, you
need the approval of a corporate vice president.”

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

39

On 6/10/2010 2:19 AM, Pavel A. wrote:

If you remember SoftICE, it could draw its text window on top
of graphic screen, without switching to the “real” text mode.
But, IIRC, it drawed text using its own fonts rather than use BIOS
int10-like fonts.

Correct, and it did so using the DirectDraw primary surface scheme,
exactly as our Mr. B implemented.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

40

Ah yes … the old save a penny … The converse is true also where a bean
counter found a deal on bulk parts for a whole mess of wire wrap boards.
Wow, a penny a part less to get silver plated instead of gold plated
sockets. He was “dismissed with cause” when the silver plated sockets
started growing whiskers and those penny-less-a-sockets started shorting
out.

Gary G. Little
H (952) 223-1349
C (952) 454-4629
xxxxx@comcast.net

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Monday, June 14, 2010 12:20 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Write to screen inside kernel driver

On 6/14/2010 9:50 AM, xxxxx@osr.com wrote:

Truer words have never been spoken.

The performance opportunities lost, and CPU cycles wasted, all for lack of
a fifty cent part. Oh, the stories I could tell…

True. On the other hand, I was once in a meeting with a rep from a “major
printer manufacturer” who pointed out, “We ship a million printers a month.
If you want to add 5 cents to the cost of goods, you need the approval of a
corporate vice president.”

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer