Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results
The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.
Check out The OSR Learning Library at: https://www.osr.com/osr-learning-library/
I'm following this article to create a noise cancelling app: https://community.osr.com/discussion/292250/help-with-design-decision-using-sysvad-virtual-driver-as-base/p1
But there is a difference that instead of using ioctl to communicate between user-mode and kernel-mode, I'm using named pipe. Everything seem to be working fine so I wonder if named pipe has any limitation or disadvantage comparing to ioctl?
Thank you.
Upcoming OSR Seminars | ||
---|---|---|
OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead! | ||
Developing Minifilters | 24 May 2021 | Live, Online |
Writing WDF Drivers | 14 June 2021 | Live, Online |
Internals & Software Drivers | 2 August 2021 | Live, Online |
Kernel Debugging | 27 Sept 2021 | Live, Online |
Comments
Named Pipe vs IOCTL
Well, these are very different mechanisms. An IOCTL will be far less overhead. A named pipe can be opened remotely. It is rather unusual to use a named pipe to communicate to a driver that’s local to the requestor. But... if it works... that’s not something to so quickly dismiss.
Peter
Peter Viscarola
OSR
@OSRDrivers
I think that the performance of a local named pipe IO won't be much different than a double buffered IOCTL - but the CreateFile part will be much different as it opens the handle on both ends. also knowing which side operates as the 'server' end of the pipe and knowing when that is available from the 'client' end of the pipe are clear issues that have well defined solutions with standard IOCTLs. Be aware that using a named pipe creates a potential security vulnerability because the network redirector will expose this end point over the network. Without an appropriate security descriptor, that may allow a remote system to either block real data (i.e. calls fail with ERROR_PIPE_BUSY) or to inject synthetic possibly malicious data. The default configuration of windows firewall mitigates this to a large extent for non-AD joined machines, but many features of windows require RPC enabled
noise cancelation is not something that should generally be performed on a system that is remote from the one actually playing the audio i would think