Hi.
I wrote the Mirror Display Driver and I have a problem with sharing memory between driver and usermode app.
I want to know what are another ways to make general memory between driver and app except for file mapping and DrvEscape?
xxxxx@gmail.com wrote:
I wrote the Mirror Display Driver and I have a problem with sharing memory between driver and usermode app.
I want to know what are another ways to make general memory between driver and app except for file mapping and DrvEscape?
What problem do you have that these solutions do not solve?
You can always have your mirror driver call into a miniport. Once in a
miniport, you have the whole kernel API available to you. However, even
there, it’s not clear what communication scheme you would choose that
would do any better than what you have.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
File Mapping is problem with Widows Vista.
As I assume If I use miniport driver as a intermediate I won’t be able to do one memory for driver and app. I’ll need to copy memory? I am afraid that I can lose speed. But it’s possible not.
I just need pass a block of memory to app. (I calculate it inside the driver).
If have understood correctly. I need to do following steps to pass the memory block.
Call DrvEscape function from the win32 app -> inside DrvEscape calculate changes -> call DeviceIoControl in miniport and pass block of changes -> someway pass this block of changes to Win32 app.
I’m think in right way?
Sorry If something isn’t correct.
xxxxx@gmail.com wrote:
File Mapping is problem with Widows Vista.
As I assume If I use miniport driver as a intermediate I won’t be able to do one memory for driver and app. I’ll need to copy memory? I am afraid that I can lose speed.
Why? You’re just passing pointers. Sharing memory between a display
driver and its miniport is much easier than between a display driver and
a user-mode app, because they’re both in the same address space.
I just need pass a block of memory to app. (I calculate it inside the driver).
If have understood correctly. I need to do following steps to pass the memory block.
Call DrvEscape function from the win32 app -> inside DrvEscape calculate changes -> call DeviceIoControl in miniport and pass block of changes -> someway pass this block of changes to Win32 app.
I’m think in right way?
Actually, I was thinking that you would call the miniport exactly once
to create your shared memory object, instead of calling EngMapFile. The
miniport can create the shared section using the necessary security
attributes, which EngMapFile does not allow. After that, the rest of
your code wouldn’t change at all.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Hmm it’s good that they’re both in the same address space.
But how can I pass pointer address from miniport driver to mirror driver?
Actually, I was thinking that you would call the miniport exactly once to create your shared memory >object
No sometimes I need to create not once. Because if user changes screen resolution I’ll need to get more or less memory for the screen.
xxxxx@gmail.com wrote:
Hmm it’s good that they’re both in the same address space.
But how can I pass pointer address from miniport driver to mirror driver?
EngDeviceIoControl. That’s the only way to communicate from the driver
to the miniport.
> Actually, I was thinking that you would call the miniport exactly once to create your shared memory >object
>
No sometimes I need to create not once. Because if user changes screen resolution I’ll need to get more or less memory for the screen.
Yes, but what I meant is that you won’t need to call into it for every
request.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
I tried to include ntddk.h inside miniport driver (\src\video\displays\mirror\mini\mirror.c) and I got errors (example - ntdef.h(388) : error C2011: ‘_QUAD’ : ‘struct’ type).
If I understood correctly I need to include ntddk.h to use kernel API?
I found here http://www.osronline.com/showThread.cfm?link=76132 post #4 that it can be fixed by isolating all functions referencing kernel routines into a file and include ntddk.h in that file. But I try to do this and I still get errors. Maybe I didn’t it correctly.
If i do
- Make new file newfile.c and write #include “ntddk.h” there -> write in mirror.c #include newfile.c -> compile - errors.
OR - Make new file newfile.c -> open sources file -> write newfile.c in sources sections -> compile successful but how can I access from mirror.c
You can’t include NTDDK.H in a miniport because miniport’s aren’t
supposed to use any functions other than those exported by videoprt.sys.
Good luck,
mm
xxxxx@gmail.com wrote:
I tried to include ntddk.h inside miniport driver (\src\video\displays\mirror\mini\mirror.c) and I got errors (example - ntdef.h(388) : error C2011: ‘_QUAD’ : ‘struct’ type).
If I understood correctly I need to include ntddk.h to use kernel API?
I just read what Tim wrote, and although my understanding is what I
wrote, he knows a lot more about this that I do, so I think I’m missing
something here.
Martin O’Brien wrote:
You can’t include NTDDK.H in a miniport because miniport’s aren’t
supposed to use any functions other than those exported by videoprt.sys.Good luck,
mm
xxxxx@gmail.com wrote:
> I tried to include ntddk.h inside miniport driver
> (\src\video\displays\mirror\mini\mirror.c) and I got errors (example -
> ntdef.h(388) : error C2011: ‘_QUAD’ : ‘struct’ type).
> If I understood correctly I need to include ntddk.h to use kernel API?
Okay.
As I have understood shared section it isn’t file mapping?
I want to know which exported function from videoprt.sys I need to use to do the shared section and how I can access it from app(user mode) side?
xxxxx@gmail.com wrote:
I tried to include ntddk.h inside miniport driver (\src\video\displays\mirror\mini\mirror.c) and I got errors (example - ntdef.h(388) : error C2011: ‘_QUAD’ : ‘struct’ type).
If I understood correctly I need to include ntddk.h to use kernel API?
Yes, a certain amount of experimentation is required for this. Play
with the order of the includes, provide your own definitions for missing
types, etc.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
xxxxx@gmail.com wrote:
I found here http://www.osronline.com/showThread.cfm?link=76132 post #4 that it can be fixed by isolating all functions referencing kernel routines into a file and include ntddk.h in that file. But I try to do this and I still get errors. Maybe I didn’t it correctly.
If i do
- Make new file newfile.c and write #include “ntddk.h” there -> write in mirror.c #include newfile.c -> compile - errors.
OR- Make new file newfile.c -> open sources file -> write newfile.c in sources sections -> compile successful but how can I access from mirror.c
Surely you know enough C to know how to define a function in one file
and call it from another file.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Martin O’Brien wrote:
You can’t include NTDDK.H in a miniport because miniport’s aren’t
supposed to use any functions other than those exported by videoprt.sys.
“Can’t” is a very strong word…
“Aren’t supposed to” is accurate. “Can’t” is not. A video miniport
can, in fact, call any kernel function. It’s not like the display
driver, where such extramarital relations are actively prohibited.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Hmmm…
What did you meant “shared section”, how can I use this?
What way or what function do you think I need to use?
xxxxx@gmail.com wrote:
Hmmm…
What did you meant “shared section”, how can I use this?
What way or what function do you think I need to use?
Once you are into the miniport, you have the full kernel resources
available to you. There are many ways to share memory between user-mode
apps and kernel-mode apps, most of which have been discussed and
critiqued on this forum at one time or another. Allocate in kernel and
map to user, allocate in user and lock in kernel, shared section, mapped
file, etc. You need to do some reading.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
I still don’t get all kernel resources.
I tried all the ways I can, but I doesn’t work.
How can I define a function in one file and call it from another file? What steps I need to do this?
Tim, are you sure that miniport driver can call kernel function?
As I have understood, I read here
http://groups.google.com/group/microsoft.public.development.device.drivers/browse_thread/thread/25afa8659e9db6e9/055651f73bd54a5c?lnk=gst&q=Miniport+ntddk.h#055651f73bd54a5c
that the video miniport driver can call only VideoXxxx and AgpXxx functions.
I’m a display driver author. Miniport drivers and Display Drivers cannot call ANY standard Windows NT service routines. In fact, for display drivers, if you even attempt to link to something besides Win32k.sys, Windows will refuse to load your driver and you’ll be stuck in VGA mode. As far as I know the same is true of video miniport drivers. This ultrarestrictive linkage approach is part of the reason that Microsoft was able to port display drivers out of the kernel and into user mode.
Additionally, video display drivers are frequently called within the address space of a user-mode process. If you want to share memory between the user-mode process and the display driver, the simplest way may be to use and Escape trick. When I had to do this, what I did was to create a DIB section in user-mode, and then pass a handle to the DIB section down to the display driver itself via an escape call. As it turns out, handles returned by user-mode bitmap creation steps are identical in kernel mode. If you call EngLockSurface on such a handle, you have instant access to the memory inside the handle itself.
Of course, there are no address space transition functions available to the display driver, so you’ll end up having to do a memory copy if you’re interested in getting data *out*. To do this, use EngMapEvent (XP only) to wire up a user-mode event to a kernel-mode event, and then wait on the event when you get a particular escape. You’ll also need a kernel-mode buffer to store data from out-of-process that you can use in-process.
I just read your last post. Are you serious about being unable to call one function from another file? That’s kind of basic…how long have you been writing C?
Thank you, for your useful information.