Hello,
You can choose different ways for communication with your driver. It is also depend on what type of the driver you are going to use and the framework which you plan to use as the base. For virtual COM port enough to have UMDF driver, I think.
The basic communication level which is easy to implement for the all drivers is the
IOCTL
You should define you own IOCTL control code and prepare handler in the driver (
IRP_MJ_DEVICE_CONTROL
). You can call
DeviceIoControl
to execute driver function. It also allowed to pass the parameters and receive results.
To use it you should find you device by using the SetupAPI by your driver interface. You can use the base interface in the driver (in your case it is COM port enumerator) or define your own interface for the communication(defined in inf file, you can look at the
IoRegisterDeviceInterface).
If you are using the base interface you need to check the device by the hardware id (defined in inf file). After just call the CreateFile API with that interface.
In KMDF and UMDF you have predefined functions which you should override in your driver: .
For
UMDF in additional you have the COM service which can support your own interface which you can use to execute specified functionality on the driver, but this will require some system privileges and may not work for the regular applications.
Another also basic method to execute driver code, but not so easy to implement is the WMI. In UMDF it is easy to integrate compare to kernel as in user space WMI worked as the COM, but also possible to have it in the kernel.
Examples how to organize IOCTL communication with the drivers you can find in my articles.
Also you can check WDK samples for implementation IQueueCallbackDeviceIoControl::OnDeviceIoControl for UMDF, EvtIoDeviceControl of the WDF_IO_QUEUE_CONFIG for KMDF and IRP_MJ_DEVICE_CONTROL handler for WDM and non-WDM drivers without frameworks.
Regards,
Maxim.