EDIT: through another question on the forum, I learned that DeviceIoControl can be async, so question 4 is now just question 2
The extensive Windows driver documentation says little, that I've found, about how a client user-mode app can communicate directly to a specific device. I understand that normally such operations are managed by the Win32 api, but in the case of specific devices or (what I'm interested in) software drivers, I don't know many ways in which it can be done
The docs say that one can use CreateFile, ReadFile, WriteFile etc. to "open" the driver as a "file" and then r/w from/to it, maybe asynchronously if you want. That sounds good but it feels like that can't be the best option for everything, nor is it the only option. DeviceIoControl can have specific control codes and you can command a driver like that, but I can't see any async capabilities in the docs there.
In the driver docs, it's clear a driver must write its callbacks routines for dispatch calls which are sent to it, but I don't understand where these dispatch calls come from, or how a user-mode client might interact with that directly.
Using Valorant's Vanguard as an example software driver, I highly doubt it just r/w'd from a "file" in operation - it seems too abstract to be fast, or not specific enough for a complex system, as all you can do in fileapi.h is read, and write, without any real parametrisation - right?
My questions are:
Must a software driver write routines for all dispatch calls that the docs recommend even though they have nothing to do with hardware?
Are there other techniques than the R/W file api and the DeviceIoControl function to communicate with a specific (software) driver?
Are there efficient, "lean and mean" solutions, when our software driver is entirely custom to the targeted user app, as Vanguard was?
(ignore) Are the async R/W file operations the only way to get this done in a multi-threaded async manner, where the client submits many possibly overlapping calls, or can DeviceIoControl leverage threading and asynchronicity?
To answer your questions
No. Not all dispatch calls needs to be implemented for a software driver. I think only CREATE/CLOSE/DEVICE CONTROL needs to be implemented. You dont even need to implement unload but then you will not be able to unload the driver, which is required for testing. If there are any other required dispatch methods, you can simply return not implemented from those implementation.
Yes. You can use named pipe between driver and application as another way to communicate.
Not sure how much more lean can you get than just implementing the minimum dispatch methods.
You can use multiple threads and synchronous operations OR you can use single thread and asynchronous operation. Depends on what model is best for you.