MultiportSerial vs. Ports class Architectural Question

NTDEV
1

I have a black box (tcp/ip) that has 4 serial ports on it. I’m developing a
UMDF driver that makes these 4 serial ports available as (4) standard COM
ports to the system.

I’m a little unsure if my driver falls into the MultiportSerial class, the
Ports class or both. My feeling is that a single device should appear under
the MultiPortSerial class represending the black box (hardware), and then 4
ports be added to the Ports class representing the available COM ports, but
I need someone smarter than me to give me some architectural advice.

Thanks in advance to anyone who posts.

Greg

2

How is the black box physically connected to the machine? You said TCP/IP, does that mean these are virtual ports and the hardware is remote?

Usually I put a bus driver in the hardware’s setup class. For example, a USB generic parent driver would go in the USB group, but any function drivers that load on top of it might go in Modem, Ports, Net, etc.

3

>>How is the black box physically connected to the machine? You said

>TCP/IP, does that mean these are virtual ports and the hardware is remote?

Yes, the black box is remote with its serial ports available via standard
sockets (winsock2).

4

I think that you want to be in the MultiportSerial class since you’re
going to have a single device with multiple COM port interfaces hanging
off of it.

-p

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Greg Thomson
Sent: Thursday, February 01, 2007 1:14 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] MultiportSerial vs. Ports class Architectural Question

I have a black box (tcp/ip) that has 4 serial ports on it. I’m
developing a
UMDF driver that makes these 4 serial ports available as (4) standard
COM
ports to the system.

I’m a little unsure if my driver falls into the MultiportSerial class,
the
Ports class or both. My feeling is that a single device should appear
under
the MultiPortSerial class represending the black box (hardware), and
then 4
ports be added to the Ports class representing the available COM ports,
but
I need someone smarter than me to give me some architectural advice.

Thanks in advance to anyone who posts.

Greg

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

5

There are 3 issues here.

  1. you need to get 4 COM port names. If each port was its own device
    stack, this would be no problem. You install each in the ports class
    and the ports class installer gives you a COM port name. If each port
    is not its own device stack, you will need to call the ComDB on your own
    to claim the names

  2. once you get the names, there is a registry key you need to write to
    (HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP\SERIALCOMM) which you do not have
    sufficient rights to do so in the UMDF process. Most apps use this reg
    key as the way to find ports

  3. if each port is not its own device stack, you will need a way to
    know which COM port is being opened. I don’t think the UMDF apis which
    let you create a symbolic link let you specify a reference string to let
    you differentiate the port name in your create file handler

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Greg Thomson
Sent: Thursday, February 01, 2007 1:36 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] MultiportSerial vs. Ports class Architectural
Question

>How is the black box physically connected to the machine? You said
>TCP/IP, does that mean these are virtual ports and the hardware is
remote?

Yes, the black box is remote with its serial ports available via
standard
sockets (winsock2).

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

6

3 - they don’t right now. We’re working on it - release indeterminate
so don’t hold breath. However whatever agent creates the SERIALCOMM
entries could also create the symbolic links. We think one could build
a small KMDF driver to do these two things for you. It doesn’t get all
the code out of the kernel, but it does make a lot of it go away.

-p

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Thursday, February 01, 2007 1:53 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] MultiportSerial vs. Ports class Architectural
Question

There are 3 issues here.

  1. you need to get 4 COM port names. If each port was its own device
    stack, this would be no problem. You install each in the ports class
    and the ports class installer gives you a COM port name. If each port
    is not its own device stack, you will need to call the ComDB on your own
    to claim the names

  2. once you get the names, there is a registry key you need to write to
    (HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP\SERIALCOMM) which you do not have
    sufficient rights to do so in the UMDF process. Most apps use this reg
    key as the way to find ports

  3. if each port is not its own device stack, you will need a way to
    know which COM port is being opened. I don’t think the UMDF apis which
    let you create a symbolic link let you specify a reference string to let
    you differentiate the port name in your create file handler

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Greg Thomson
Sent: Thursday, February 01, 2007 1:36 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] MultiportSerial vs. Ports class Architectural
Question

>How is the black box physically connected to the machine? You said
>TCP/IP, does that mean these are virtual ports and the hardware is
remote?

Yes, the black box is remote with its serial ports available via
standard
sockets (winsock2).

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

7

I guess you could install the driver as a filter in KM to do this so
that you don’t have the KM driver running all of the time…

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Peter Wieland
Sent: Thursday, February 01, 2007 2:16 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] MultiportSerial vs. Ports class Architectural
Question

3 - they don’t right now. We’re working on it - release indeterminate
so don’t hold breath. However whatever agent creates the SERIALCOMM
entries could also create the symbolic links. We think one could build
a small KMDF driver to do these two things for you. It doesn’t get all
the code out of the kernel, but it does make a lot of it go away.

-p

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Thursday, February 01, 2007 1:53 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] MultiportSerial vs. Ports class Architectural
Question

There are 3 issues here.

  1. you need to get 4 COM port names. If each port was its own device
    stack, this would be no problem. You install each in the ports class
    and the ports class installer gives you a COM port name. If each port
    is not its own device stack, you will need to call the ComDB on your own
    to claim the names

  2. once you get the names, there is a registry key you need to write to
    (HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP\SERIALCOMM) which you do not have
    sufficient rights to do so in the UMDF process. Most apps use this reg
    key as the way to find ports

  3. if each port is not its own device stack, you will need a way to
    know which COM port is being opened. I don’t think the UMDF apis which
    let you create a symbolic link let you specify a reference string to let
    you differentiate the port name in your create file handler

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Greg Thomson
Sent: Thursday, February 01, 2007 1:36 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] MultiportSerial vs. Ports class Architectural
Question

>How is the black box physically connected to the machine? You said
>TCP/IP, does that mean these are virtual ports and the hardware is
remote?

Yes, the black box is remote with its serial ports available via
standard
sockets (winsock2).

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

8

Yes, that’s what I ment. Thanks for actually *saying* it :slight_smile:

Basically you’d setup a KMDF filter on your device stack which accepted
one I/O control from your driver which told it the COM port name and the
device interface to link to. The KMDF driver can determine the rest and
setup the symbolic links and registry entries directly.

-p

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Thursday, February 01, 2007 2:21 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] MultiportSerial vs. Ports class Architectural
Question

I guess you could install the driver as a filter in KM to do this so
that you don’t have the KM driver running all of the time…

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Peter Wieland
Sent: Thursday, February 01, 2007 2:16 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] MultiportSerial vs. Ports class Architectural
Question

3 - they don’t right now. We’re working on it - release indeterminate
so don’t hold breath. However whatever agent creates the SERIALCOMM
entries could also create the symbolic links. We think one could build
a small KMDF driver to do these two things for you. It doesn’t get all
the code out of the kernel, but it does make a lot of it go away.

-p

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Thursday, February 01, 2007 1:53 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] MultiportSerial vs. Ports class Architectural
Question

There are 3 issues here.

  1. you need to get 4 COM port names. If each port was its own device
    stack, this would be no problem. You install each in the ports class
    and the ports class installer gives you a COM port name. If each port
    is not its own device stack, you will need to call the ComDB on your own
    to claim the names

  2. once you get the names, there is a registry key you need to write to
    (HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP\SERIALCOMM) which you do not have
    sufficient rights to do so in the UMDF process. Most apps use this reg
    key as the way to find ports

  3. if each port is not its own device stack, you will need a way to
    know which COM port is being opened. I don’t think the UMDF apis which
    let you create a symbolic link let you specify a reference string to let
    you differentiate the port name in your create file handler

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Greg Thomson
Sent: Thursday, February 01, 2007 1:36 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] MultiportSerial vs. Ports class Architectural
Question

>How is the black box physically connected to the machine? You said
>TCP/IP, does that mean these are virtual ports and the hardware is
remote?

Yes, the black box is remote with its serial ports available via
standard
sockets (winsock2).

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

9

My game plan to avoid writing a KMDF filter driver, was to construct a
property page.

While the user (adminitrator) is explicitly selecting the black box’s IP
address and starting COM port #, I could implicitly be acquring the ports
via the COM port database, setting up the SERIALCOMM registry, and
performing whatever other persistent tasks needing to be performed.

10

Unfortunately neither the SERIALCOMM registry entries nor the COMx:
symbolic links are persistent.

-p

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Greg Thomson
Sent: Thursday, February 01, 2007 4:50 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] MultiportSerial vs. Ports class Architectural
Question

My game plan to avoid writing a KMDF filter driver, was to construct a
property page.

While the user (adminitrator) is explicitly selecting the black box’s IP

address and starting COM port #, I could implicitly be acquring the
ports
via the COM port database, setting up the SERIALCOMM registry, and
performing whatever other persistent tasks needing to be performed.

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

11

Thanks, I glossed over that point…

I wonder if I could use a KM bus driver in the hardware’s setup class as
per Chris’s comments, and then use a UM function driver for each of the
device stacks. The bus driver could assist in setting up the some of the
registry settings.

–Going to have to review the toaster example a little more.

Greg,

12

If you go the KM bus driver route, a few things are simplified. You should install each child port in the Ports class. This way you will get the COM port numbers assigned to your devices w/out any additional work. Then in EvtDevicePrepareHardware for the enumerated PDO, you can write out the registry value into SERIALCOMM on behalf of hte function driver (the port name will be in the devnode under a value called “PortName”)

d

13

If I don’t develop a KM bus driver and simply develop a Ports class UM
driver, will the Ports class installer setup the SERIALCOMM registry as
well, or does it just setup the ‘non legacy’ aspects of the device?

Question: What are the generally accepted practises for ‘manual install
devices’. For example, if I take the KM bus driver route and the user wants
to install a second black-box. A simple setup app? Device property page?
Other ?

Thanks,

14

The ports class installer *assigns* you a port name by writing the “PortName” value into the device node. That’s it. It does not write out anything else liek teh SERIALCOMM key. It has no notion of legacy or not.

You could create a property page on the parent bus driver which lets the user add/remove ports at will. You could also deploy an app. You could do both. IT is up to you really.

d