We are developing a File Monitoring Device Driver for Win NT/Win 2K/Win
XP.
We want to pass some data from the driver to an application…
Are there any ready made Win APIs available for the same…
for e.g. if we want to share or pass data at application level we can use
Shared Memory or Pipes.
Is IPC possible between driver and application? If yes, how ?
Can we use shared memory etc … Which is the easiest way if not the best
?
Subodh
Hi,
DeviceIoControl is arguably the easiest.
Regards.
Hi Vikram,
Can you give some more details about the usage ?
Regards
Subodh
Hi Subodh,
This is a extract from the MSDN … hope it helps…
DeviceIoControl
The DeviceIoControl function sends a control code directly to a specified device driver, causing the corresponding device to perform the corresponding operation.
BOOL DeviceIoControl( HANDLE hDevice, // handle to device DWORD dwIoControlCode, // operation LPVOID lpInBuffer, // input data buffer DWORD nInBufferSize, // size of input data buffer LPVOID lpOutBuffer, // output data buffer DWORD nOutBufferSize, // size of output data buffer LPDWORD lpBytesReturned, // byte count LPOVERLAPPED lpOverlapped // overlapped information);
Parameters
hDevice
[in] Handle to the device on which to perform the operation, typically a volume, directory, file, or alternate stream. To retrieve a device handle, use the CreateFile function.
dwIoControlCode
[in] Specifies the control code for the operation. This value identifies the specific operation to be performed and the type of device on which to perform it.
For a list of the control codes and a short description of each control code, see Device Input and Output Control Codes .
For more detailed information on each control code, see its documentation. In particular, the documentation provides details on the usage of the lpInBuffer, nInBufferSize, lpOutBuffer, nOutBufferSize, and lpBytesReturned parameters.
lpInBuffer
[in] Pointer to a buffer that contains the data required to perform the operation.
This parameter can be NULL if the dwIoControlCode parameter specifies an operation that does not require input data.
nInBufferSize
[in] Specifies the size, in bytes, of the buffer pointed to by lpInBuffer.
lpOutBuffer
[out] Pointer to a buffer that receives the operation’s output data.
This parameter can be NULL if the dwIoControlCode parameter specifies an operation that does not produce output data.
nOutBufferSize
[in] Specifies the size, in bytes, of the buffer pointed to by lpOutBuffer.
lpBytesReturned
[out] Pointer to a variable that receives the size, in bytes, of the data stored into the buffer pointed to by lpOutBuffer.
If the output buffer is too small to return any data, then the call fails, GetLastError returns the error code ERROR_INSUFFICIENT_BUFFER, and the returned byte count is zero.
If the output buffer is too small to hold all of the data but can hold some entries, then the operating system returns as much as fits, the call fails, GetLastError returns the error code ERROR_MORE_DATA, and lpBytesReturned indicates the amount of data returned. Your application should call DeviceIoControl again with the same operation, specifying a new starting point.
If lpOverlapped is NULL, lpBytesReturned cannot be NULL. Even when an operation produces no output data, and lpOutBuffer can be NULL, DeviceIoControl makes use of the variable pointed to by lpBytesReturned. After such an operation, the value of the variable is without meaning.
If lpOverlapped is not NULL, lpBytesReturned can be NULL. If this is an overlapped operation, you can get the number of bytes returned by calling GetOverlappedResult. If hDevice is associated with an I/O completion port, you can get the number of bytes returned by calling GetQueuedCompletionStatus.
lpOverlapped
[in] Pointer to an OVERLAPPED structure.
If hDevice was opened with the FILE_FLAG_OVERLAPPED flag, lpOverlapped must point to a valid OVERLAPPED structure. In this case, the operation is performed as an overlapped (asynchronous) operation. If the device was opened with FILE_FLAG_OVERLAPPED and lpOverlapped is NULL, the function fails in unpredictable ways.
If hDevice was opened without specifying the FILE_FLAG_OVERLAPPED flag, lpOverlapped is ignored and DeviceIoControl does not return until the operation has been completed, or an error occurs.
Return Values
If the function succeeds, the return value is nonzero.
If the function fails, the return value is zero. To get extended error information, call GetLastError.
Remarks
If hDevice was opened with FILE_FLAG_OVERLAPPED and the lpOverlapped parameter points to an OVERLAPPED structure, the operation is performed as an overlapped (asynchronous) operation. In this case, the OVERLAPPED structure must contain a handle to a manual-reset event object created by a call to the CreateEvent function. For more information on manual-reset event objects, see Synchronization.
Requirements
Windows NT/2000: Requires Windows NT 3.1 or later.
Windows 95/98: Requires Windows 95 or later.
Header: Declared in Winbase.h; include Windows.h.
Library: Use Kernel32.lib.
See Also
Device Input and Output Overview, Device Input and Output Functions, CreateEvent, CreateFile, GetOverlappedResult, GetQueuedCompletionStatus, OVERLAPPED
“Subodh G. Karode” wrote:Hi Vikram,
Can you give some more details about the usage ?
Regards
Subodh
—
You are currently subscribed to ntfsd as: xxxxx@yahoo.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
---------------------------------
With Yahoo! Mail you can get a bigger mailbox – choose a size that fits your needs
Oh just lovely. Thank you so much for COPYING that documentation and PASTING it, verbatim, into a post when a simple RTFM, nicely put of course, would have surficed. So, if he asks about the links to other articles are you then going to COPY and PASTE all of them!?!?!
Hell … why not just copy and paste the entire frigging documentation and be done with it.
–
Gary G. Little
Have Computer, will travel …
909-698-3191
909-551-2105
Hi Subodh,
Just thought Id elaborate a little on the solution since it took me some
time to work out the details.
Basically DeviceIoControls (henceforth Ioctls) can be used to send a
buffer to the driver. In the driver you can intercept such a message (in
the dispatch function for DeviceIoControls). You can mark it pending and
return in the driver. Save the Irp and get its buffer before you return,
ofcourse.
Later when the driver is ready to send the application some data, you can
copy it in the Ioctl Irp’s buffer and complete that Irp.
Meanwhile the application can be made to wait for the results of the Ioctl
when it finds that the request was marked pending (details are given in
that MSDN article). When you get the results you will have the message
from the driver in the buffer you sent with the Ioctl.
Hope that helps,
Jagannath