Expose functions from a windows driver into user space

Question

0.00/5 (No votes)

See more:

I am exposing a virtual com port as a Windows OS driver that my app needs to be able to send and receive data from.

My app a user space application, so how do I expose functions from my driver that can then be used by loading a DLL and calling some functions?

What I have tried:

I haven't tried anything yet because I'm not sure what to do.

Posted 20-Sep-23 7:23am

honey the codewitch

Add a Solution

2 solutions

Solution 1

I don't have an exact answer for you but I suspect you could find one at : Windows driver samples | Microsoft Learn[^]

Posted 20-Sep-23 7:52am

Rick York

Comments

honey the codewitch 20-Sep-23 14:07pm

That's what I've started with, but I can't find that. I'll look again.

raddevus 20-Sep-23 14:33pm

Have you looked at the Trusted Execution Environment sample ==> https://learn.microsoft.com/en-us/windows-hardware/drivers/samples/tree-driver-samples

Then within that, (code at github) take a look at the sample test code ==> https://github.com/microsoft/Windows-driver-samples/blob/main/TrEE/Test/SampleTest.cpp

It may show you how to make the calls. Hopefully this helps.

honey the codewitch 20-Sep-23 15:08pm

thanks. i'll give it a look

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Maxim Kartavenkov · Accepted Answer · 2023-09-20T21:27:00

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.