What methods should I use to share a memory allocated by a user mode
application with a device driver? Here's what I want to do:

1. Allocate memory in the GUI app
2. Pass a handle or an address of it to my device driver
3. Get access to this memory region from the device driver (read access)

Can I use MemoryMappedFile's to accomplish this task?

Thank you,
Anatoly

Well first off why do you want to do this? Once you have set this
up you would still need a method to indicate that there is data for
the device driver, unless this is a chunk of memory you initialize
once and the device driver is using as a table? This is a common
question and it comes down that most folks don't have the rest
of the scheme figured out.

Tell us what problem you want to solve (the below is a implementation
not a problem) and the group will give you a solution.

Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting

"Anatoly Smelkov" <anatoly@smelkov.com> wrote in message
news:%23qBpIK9kDHA.964@TK2MSFTNGP10.phx.gbl...

The user mode part and the driver work in conjunction allowing several
applications to use the same video capture source at the same time. The user
mode application grabs the video stream and saves frames in the shared
memory. The driver, which acts as a video capture driver and looks like a
video source to other applications, passes the frames taken from the shared
memory to other apps connected to it. Sorry if I put it too clumsy. You see
that I need the fastest way to exchange data between user and kernel modes
and I don't need any synchronization -- some video distortions are quite
acceptable.

"Don Burn" <burn@acm.org> wrote in message
news:vosvj7qrgd3550@corp.supernews.com...

Why don't you just pass READ or DEVICE_CONTROL IRPs to the driver, with
DIRECT mode, and the driver would save the frame directly into that buffer
and complete the IRP. The buffer could reside in your memory-mapped area
shared by applications. This way you get synchronization and zero-copy
performance.

This is very straightforward way, compatible even with Win98. And cost of
DIRECT_IO is very little.

"Anatoly Smelkov" <anatoly@smelkov.com> wrote in message
news:e5NeVy%23kDHA.644@TK2MSFTNGP11.phx.gbl...

Thank you. I think this would be the best solution. Now there's another
problem: the driver is a stream minidriver and I don't know what I must do
to implement IO requests handling in such driver types. I tried to open a
handle to my driver using CreateFile() but failed with the error code
0x00000002 (The system cannot find the file specified. )

"Alexander Grigoriev" <alegr@earthlink.net> wrote in message
news:OOKkhL$kDHA.2456@TK2MSFTNGP09.phx.gbl...

Proxy the driver with KSProxy and QI KSProxy for IKsObject and use
IKsObject::KsGetObjectHandle to get file handle. Then use the file handle to
do DeviceIoControl.
You could also use KsSynchronousDeviceControl exported by ksproxy.ax or even
better QI KSProxy for IKsPropertySet to get/set properties on your driver.

In reality I don't think you need all that. Just implement your own media
sample allocator in downstream user mode DShow filter and then use DShow to
connect this filter to your driver.
Your filter will have to insist on using its own allocator and implement it
to allocate buffers from memory mapped file.
After that what your driver will get (provided it sets DMA flag in its
device descriptor) is this shared memory based buffer. Once you put your
frame in there and complete IRP the sample will become available to your
DShow filter from where you can fire an event to let others know that they
can access it.

-- Max.


"Anatoly Smelkov" <anatoly@smelkov.com> wrote in message
news:%236fzUS$kDHA.392@TK2MSFTNGP11.phx.gbl...