nb3m on Thu, 03 Jan 2019 11:55:22
I am quite new to Driver Development. I red online documentation and went through different examples how to make driver. I need to prepare virtual serial driver that will connect to socket endpoint. I have to keep backward compatibility until Windows 7 so
if I am correct I need to make Kernel Mode driver with WSK module. Can anyone point me a direction where should I start or where can I find any tutorial that will explain driver basics? Windows documentation explain how different functions works but does not
answer why it is needed.
Looking forward to hear from you. Cheers.
Pavel A on Thu, 03 Jan 2019 21:51:48
Kernel drivers are complicated. Most likely you don't want one. Instead, can the application just work with a socket? Like putty, hyper-terminal and so on and so on?
nb3m on Fri, 04 Jan 2019 09:29:42
I would be more than happy to find other solution but I am afraid I don't have much choice on that. Application works only with serial ports and there is no way I can modify it. I know it would be easier.
I have started from msdn documentation and early steps are quite easy. The problem is that documentation jumps from simple steps directly to advanced level. I am missing some intermediate steps and that's something I am looking for.
Thanks for your replay!
Brian Catlin on Fri, 04 Jan 2019 17:52:32
You will need to write a WDF driver where its upper-edge implements the serial driver IRPs, as documented here. You may be able to implement this using UMDF and use the WinSock APIs for your network access, or you can implement using KMDF and then you will need to use WSK to communicate with your remote system. Luckily for you, there are samples in the WDK that will get you most of the way there. Look at WDK\Serial and WDK\Network\WSK\EchoSrv. The samples can be found here
Pavel A on Fri, 04 Jan 2019 21:57:57
Have you heard about Detours or similar ways to alter application behavior?
Also, com0com may do what you need.
Brian Catlin on Fri, 04 Jan 2019 22:01:39
An excellent suggestion, Pavel
Andrew E. _ on Sun, 06 Jan 2019 04:59:02
Maybe the best site is OSR
OSR & NT Insider,basically only write Windows drivers,they work with Microsoft/MSDN
nb3m on Mon, 07 Jan 2019 10:44:21
Thanks for your help. I am already following WDF and WSK documentation. I am familiar with IRPs. Currently I am trying to get through WDK examples (EchoSrv, Virtual Serial) and com0com. I will check Detours but I don't know how it might help me. OSR - reading community topics right now.
I think I have many topics to read now. I will come back later. :)
nb3m on Mon, 07 Jan 2019 13:56:16
About WSK. If I am correct, WSK subsystem has it's own queue that handles IPRs. I am implementing WSK NPI client in my driver that will communicate with WSK subsystem. Examples I saw create queues to handle IRPs from I/O manager. Do I need to implement queue inside my driver or can I just pass I/O IRPs to the WSK subsystem directly?
To be precise, I would define EvtIoWrite to write data into the socket. Socket has its own queue so I don't need to bother with it :)
Brian Catlin on Tue, 08 Jan 2019 18:25:30
Most driver models are wildly different from each other. WSK and WDF and WDM are no exception. The WDF or WDM drivers you've likely seen get IRPs (typically) from user-mode applications and queue them so that they can process them one at a time, because most devices can only do one thing at a time (seek-reordering disk controllers being a notable exception). A WSK driver will queue IRPs as descriptors of buffers for incoming or outgoing data.
nb3m on Wed, 09 Jan 2019 10:54:06
Lets assume that I have defined serial IRP write function EvtIoWrite and socket callback event WskReceiveEvent to keep asynchronous communication. Am I correct that I need IRP queue to handle both calls so that they don't process at this same time?
Brian Catlin on Wed, 09 Jan 2019 18:07:43
No. Due to the nature of a serial device, the user I/Os need to be processed serially; however, that can be decoupled from the WSK interface. You will need to manage the serial I/O requests (assuming WDF) separately from the IRPs that you're queueing to WSK. Think about two state machines communicating. One for the serial I/Os and another for the WSK I/Os.