Newbie questions - Serial device driver

NTDEV
1

Hello OSR community,

I jumped head first into windows driver development a week ago and I am stuck now.

Coming from C++, I looked at some C tutorials and I understand how it works now basically - I have a big lack in experience though.

After working through documentation, examples and tutorials for a week now, I definitely learned a lot about how drivers work in windows, but on a very abstract level. Seriously, every tutorial out there seems to be about drivers that don’t do anything or that are for devices that do not physically exist.

So, to put it in questions (data about the driver/project is below the questions):

(1) I read it is possible to write drivers in C++, but every tutorial and example
is in C. I also read that there is not much C++ support.
Did those two sentences actually mean the same or does the latter mean
that C++ drivers won’t work in certain machines/configurations?
(2) In my situation, would it be advisable to try and code it in C++?
(3) If the answer to (2) is ‘no’: Do I have to get years of C experience first before I
will be able to write a decent driver?

Hmmm… If the answer to (2) is ‘Don’t even think about it’ and the answer to 3 is ‘yes’ then you don’t have to bother about the rest of the questions, I guess.

(4) Are filter drivers more like an enhancement to a standard
(a bit like a subclass) or more like the data for a template?
(5) Should I use KMDF or UMDF?
(6) Does UMDF have disadvantages?
(6a) And in my specific situation?
(7) What kind of driver would fit my situation best?
(filter, mini, wdm, etc; I lost overview over which means what)
(8) I actually have provisioned my desktop PC (I am coding on my Laptop);
According to the other answers, will it be necessary to use it for
debugging?
(I can imagine a graphic tablet driver not being as system-critical as
e.g. the processor driver, but I could also imagine a stupid USB powered
light crashing a system with a misconfigured driver.)
(9) I have the parts ‘around’ the driver: I know what data I get from the device
in what format and I know what should happen in the OS,
but neither do I have an idea where the values from the device enter the
driver, nor do I know how the driver would e.g. set the mouse position.
Where does this happen?
(10) Maybe there is a working driver that I can use as-is while only changing
the part about the data getting in and the mousepointer control.
If yes, where is it?
(11) How close am I to my primary goals? (or how difficult is it)
(12) How close am I to my secondary goals?
(13) How close am I to my tertiary goals?
(14) If I missed the point somewhere (and most certainly I have):
Where and how?

================================================
Current state of the project:

Target OS (as well as dev machine) is win7 x64.

Device: Graphical tablet “Wacom UltraPadA5”

  • very old (drivers for x64 do not exist)
  • connection via serial port
  • connected to test machine via a third party usb-to-serial adapter
    Is potentially able to do (well, what wacom says):
  • absolute mouse position movement
    (pen in upper right corner -> mouse jumps to upper right corner of screen)
  • relative mouse position movement
  • left click, right click, double left click
  • ‘erase’ functionality with the back of the pen (like a pencil with eraser)
  • 16 buttons; first 5 user programmable, 6-14 are equivalent to key
    combinations (cut, copy, paste, undo, del, new, open, save, print),
    15 and 16 are for switching between absolute and relative movement

Reading out the serial (at 9600 baud), I saw that a package consists of 7 bytes:

  • [0] kind of message (button pressed, moving pen over tablet,
    writing, erasing, pen moved out of range)
  • [1] X position value before floating point
  • [2] X position value after floating point
  • [3] indicates left click, right click or double left click; on left click it takes
    values 0,4,8 or 12 - could be pressure value before floating point
  • [4] Y position value before floating point
  • [5] Y position value after floating point
  • [6] when [0] indicates a button was pressed, this gives the button number,
    else it could be pressure value after float

My primary goals for this driver are:

  • move the mouse pointer (doesn’t matter if relative or absolute)
  • perform a mouse click when the pen is put down
  • perform a mouse drag when the pen is put down and moved
    (I don’t know if that’s a difference to mouse click)
    Secondary goals include:
  • both types of movement and switching between them
  • right click and double left click
    Tertiary goals (at this stage, I don’t care about this at all) are:
  • from the buttons, make the key combinations work
  • make the pressure work like it does in other graphic tablets
    (so it can be used in graphic tools for line strength etc.)
    Finally, IF it is rather easy and there’s a win library for it, I would like to make the buttons user programmable.

Thanks for reading this novel, the book will be out soon. :wink:
OK seriously, thanks for reading all this and thanks in advance for the answers!

2

C is a subset of c++. If you go with umdf, you have all of the c++ features at your disposal, kernel mode is where the restriction is. You want a hid miniport to accomplish your goal. That will allow you to report both relative and absolute pointing devices. They have to be distinct separate top level collections in your hid descriptor (you can get both up and running with the same driver, hidclass will make the new devices for you).

I would recommend a umdf hid mini port given your inexperience, start withhttp://code.msdn.microsoft.com/windowshardware/WudfVhidmini-Sample-b304f83a . You will be able to read a serial port from a umdf driver, if the device is serial enumerable, you can install on that device. Open device manager and view by connection. Find the serial port it is connected to, see if there is a child node. Otherwise you will have to create a root enumerated device.

d

dent from pjone

From: xxxxx@gmx.netmailto:xxxxx
Sent: ?12/?9/?2012 10:55 AM
To: Windows System Software Devs Interest Listmailto:xxxxx
Subject: [ntdev] Newbie questions - Serial device driver

Hello OSR community,

I jumped head first into windows driver development a week ago and I am stuck now.

Coming from C++, I looked at some C tutorials and I understand how it works now basically - I have a big lack in experience though.

After working through documentation, examples and tutorials for a week now, I definitely learned a lot about how drivers work in windows, but on a very abstract level. Seriously, every tutorial out there seems to be about drivers that don’t do anything or that are for devices that do not physically exist.

So, to put it in questions (data about the driver/project is below the questions):

(1) I read it is possible to write drivers in C++, but every tutorial and example
is in C. I also read that there is not much C++ support.
Did those two sentences actually mean the same or does the latter mean
that C++ drivers won’t work in certain machines/configurations?
(2) In my situation, would it be advisable to try and code it in C++?
(3) If the answer to (2) is ‘no’: Do I have to get years of C experience first before I
will be able to write a decent driver?

Hmmm… If the answer to (2) is ‘Don’t even think about it’ and the answer to 3 is ‘yes’ then you don’t have to bother about the rest of the questions, I guess.

(4) Are filter drivers more like an enhancement to a standard
(a bit like a subclass) or more like the data for a template?
(5) Should I use KMDF or UMDF?
(6) Does UMDF have disadvantages?
(6a) And in my specific situation?
(7) What kind of driver would fit my situation best?
(filter, mini, wdm, etc; I lost overview over which means what)
(8) I actually have provisioned my desktop PC (I am coding on my Laptop);
According to the other answers, will it be necessary to use it for
debugging?
(I can imagine a graphic tablet driver not being as system-critical as
e.g. the processor driver, but I could also imagine a stupid USB powered
light crashing a system with a misconfigured driver.)
(9) I have the parts ‘around’ the driver: I know what data I get from the device
in what format and I know what should happen in the OS,
but neither do I have an idea where the values from the device enter the
driver, nor do I know how the driver would e.g. set the mouse position.
Where does this happen?
(10) Maybe there is a working driver that I can use as-is while only changing
the part about the data getting in and the mousepointer control.
If yes, where is it?
(11) How close am I to my primary goals? (or how difficult is it)
(12) How close am I to my secondary goals?
(13) How close am I to my tertiary goals?
(14) If I missed the point somewhere (and most certainly I have):
Where and how?

================================================
Current state of the project:

Target OS (as well as dev machine) is win7 x64.

Device: Graphical tablet “Wacom UltraPadA5”
- very old (drivers for x64 do not exist)
- connection via serial port
- connected to test machine via a third party usb-to-serial adapter
Is potentially able to do (well, what wacom says):
- absolute mouse position movement
(pen in upper right corner -> mouse jumps to upper right corner of screen)
- relative mouse position movement
- left click, right click, double left click
- ‘erase’ functionality with the back of the pen (like a pencil with eraser)
- 16 buttons; first 5 user programmable, 6-14 are equivalent to key
combinations (cut, copy, paste, undo, del, new, open, save, print),
15 and 16 are for switching between absolute and relative movement

Reading out the serial (at 9600 baud), I saw that a package consists of 7 bytes:
- [0] kind of message (button pressed, moving pen over tablet,
writing, erasing, pen moved out of range)
- [1] X position value before floating point
- [2] X position value after floating point
- [3] indicates left click, right click or double left click; on left click it takes
values 0,4,8 or 12 - could be pressure value before floating point
- [4] Y position value before floating point
- [5] Y position value after floating point
- [6] when [0] indicates a button was pressed, this gives the button number,
else it could be pressure value after float

My primary goals for this driver are:
- move the mouse pointer (doesn’t matter if relative or absolute)
- perform a mouse click when the pen is put down
- perform a mouse drag when the pen is put down and moved
(I don’t know if that’s a difference to mouse click)
Secondary goals include:
- both types of movement and switching between them
- right click and double left click
Tertiary goals (at this stage, I don’t care about this at all) are:
- from the buttons, make the key combinations work
- make the pressure work like it does in other graphic tablets
(so it can be used in graphic tools for line strength etc.)
Finally, IF it is rather easy and there’s a win library for it, I would like to make the buttons user programmable.

Thanks for reading this novel, the book will be out soon. :wink:
OK seriously, thanks for reading all this and thanks in advance for the answers!

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer</mailto:xxxxx></mailto:xxxxx>

3

xxxxx@gmx.net wrote:

After working through documentation, examples and tutorials for a week now, I definitely learned a lot about how drivers work in windows, but on a very abstract level. Seriously, every tutorial out there seems to be about drivers that don’t do anything or that are for devices that do not physically exist.

So, to put it in questions (data about the driver/project is below the questions):

(1) I read it is possible to write drivers in C++, but every tutorial and example
is in C. I also read that there is not much C++ support.
Did those two sentences actually mean the same or does the latter mean
that C++ drivers won’t work in certain machines/configurations?

Kernel C++ has been a bit controversial in the past, although the
controversy has pretty much abated in the Windows 8 WDK. Note that
multimedia drivers (like audio and video capture) have long been written
in C++, including the Microsoft samples.

The issues are largely related to compiler assumptions. The kernel does
not have support for C++ exceptions, so nothing with exceptions will
work (including STL). Further, a driver writer has to be able to
dictate whether code gets placed into paged or non-paged memory. The
Microsoft compiler did not (until VS2012) provide a way for you to
specify where compiler-generated code gets placed. That means templates
as a whole a problematic (although there are ways to handle this).

They key is knowing what constructs to avoid. As long as you do that,
C++ works great. And, as I said, most of these issues have been
resolved in the Win 8 WDK.

(4) Are filter drivers more like an enhancement to a standard
(a bit like a subclass) or more like the data for a template?

Neither, really. Think of a stack of kernel drivers as a bunch of
telegraph stations connected by a wire. Each driver receives a telegram
by wire, modifies it to some extent, and sends it down to the next
station. A filter driver essentially splices itself into the wire
either before or after one of the existing stations. That filter driver
has all of the capabilities of any other driver. It can modify the
requests, or create new requests, or route requests to other places, etc.

So, let’s say I add a special command to my otherwise standard device.
I can put an upper filter on the standard system driver, intercept those
requests, convert them to hardware requests, and send them along,
bypassing the standard driver.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

4

> (1) I read it is possible to write drivers in C++, but every tutorial and example

is in C. I also read that there is not much C++ support.
Did those two sentences actually mean the same or does the latter mean
that C++ drivers won’t work in certain machines/configurations?

Traditionally, only C was recommended for system-level development. One of the reasons are a) no C++ SEH runtime in the kernel, which means - no STL (unless you will rework it a lot) b) no paged/nonpaged pragmas for template-generated code.

Nevertheless, audio drivers were always using C++, though not exceptions and templates - only virtual methods.

KMDF is also C+±based internally, and also (according to its authors) only uses virtual methods, and not exceptions and templates.

With Win8 WDK, C++ is officially supported - though again without exceptions and thus STL.

(2) In my situation, would it be advisable to try and code it in C++?

Depends on what C++ features do you use.

(3) If the answer to (2) is ‘no’: Do I have to get years of C experience first before I
will be able to write a decent driver?

You must know your tools before writing any code.

(4) Are filter drivers more like an enhancement to a standard
(a bit like a subclass) or more like the data for a template?

Filter drivers are GoF’s decorators.

(5) Should I use KMDF or UMDF?

KMDF yes. UMDF is only for some device classes.

Also, for storage controller drivers, you should use another framework of StorPort.

For NIC drivers, you should use another framework of NDIS.

(6) Does UMDF have disadvantages?

Slower a bit, and lack of support of some features. For instance, you cannot develop a proper serial port driver using it.

(10) Maybe there is a working driver that I can use as-is while only changing
the part about the data getting in and the mousepointer control.

For mouse, you should use the HID stack.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

5

Hello Everybody,

Thanks for the answers.
I will try an umdf hid mini port.

One thing I am not yet sure about is if it is serial enumerable though.
In device manager (view by connection) I see:
…
…Generic USB Hub
…- Prolific USB-to-Serial Comm Port (COM4)
…- WACOM UD

IS ‘WACOM UD’ the child node or should it have another child node?

But thanks again, I know which direction to go now.

Have a nice day!

6

WACOM UD is a child device. Open up its properties, go to the details tab and look at the hardware IDs. The first SERENUM\xxxx value is probably going to be the one you want to use in your INF

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmx.net
Sent: Wednesday, December 12, 2012 10:58 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Newbie questions - Serial device driver

Hello Everybody,

Thanks for the answers.
I will try an umdf hid mini port.

One thing I am not yet sure about is if it is serial enumerable though.
In device manager (view by connection) I see:
…
…Generic USB Hub
…- Prolific USB-to-Serial Comm Port (COM4)
…- WACOM UD

IS ‘WACOM UD’ the child node or should it have another child node?

But thanks again, I know which direction to go now.

Have a nice day!

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer