Port names such as COM1, LPT1 and etc

[foreverbeginner]

I am new, and I have some basic qustions;

My computer has XP installed, and I use ‘HyperTeminal’ often. When I set it up to use, one of the choices is ports, such as COM1, COM2, and TCP/IP and etc. My questions are;

1. How do these port names get to appear in the HyperTerminal’s ‘Connect To’ setup? And why not LPT1, and LPT2, USB and etc that are ports also. Is it built in HyperTerminal (and other similar applications)?

2. Does HyperTerminal behave differently based on the choices one makes? For example, does it excute a part of the program for COM1, and another part for TCP/IP? Or, is it the responsiblility of the ports to provide proper services to HyperTerminal?

The reason I ask these questions is I wish to write an application that would (kind of) replace the hardware that normally would be connected to the COM port. So, I thought I would use a made up port name, such as MYFAKEHARDWAREPORT, in place of COM1, or COM2 and etc, and let HyperTerminal connect to this made up port name.

Would this work? Or, is there a better way to do this? Your comments are highly appreciated.

In the mean time, I am back to the forum board reading up as much as I can.

Thank you.

A Beginner

[Chris_Aseltine]

foreverbeginner wrote:

1. How do these port names get to appear in the HyperTerminal’s
   ‘Connect To’ setup?

They are enumerated from HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP\SERIALCOMM.

2. Does HyperTerminal behave differently based on the choices
   one makes? For example, does it excute a part of the program
   for COM1, and another part for TCP/IP? Or, is it the responsiblility
   of the ports to provide proper services to HyperTerminal?

COM ports use standard Win32 serial I/O, modems use TAPI, and the “TCP/IP” selection is telnet.

So, I thought I would use a made up port name, such as
MYFAKEHARDWAREPORT, in place of COM1, or COM2 and
etc, and let HyperTerminal connect to this made up port name.

Yes, you can do this, but not from an “application”, you need a driver.

[foreverbeginner]

Hello Chris,

Thank you for your response. I have downloaded DDK from Microsoft, and they have a bunch of ‘sample’ drivers. If you are familiar with them, which one would you recommend for me to get started to get my feet wet for my situation?

I have tried ‘fakemodem’, but, I can not install it following the given instruction since I do not have an actual hardware, and the installation assumes a piece of hardware, I think.

Thanks again.

[Faris_Yau]

Do you need something that has to look like a serial port, or do you
simply need to write something that sits on “the other end” of
HyperTerminal? If that is the case, you may consider writing a socket
application that listens on a TCP port and connect to it using the
TCP/IP option in HyperTerminal instead of the COM port option. That
would be significantly easier than writing a virtual serial port driver.

xxxxx@yahoo.com wrote:

I am new, and I have some basic qustions;

My computer has XP installed, and I use ‘HyperTeminal’ often. When I
set it up to use, one of the choices is ports, such as COM1, COM2,
and TCP/IP and etc. My questions are;

1. How do these port names get to appear in the HyperTerminal’s
   ‘Connect To’ setup? And why not LPT1, and LPT2, USB and etc that are
   ports also. Is it built in HyperTerminal (and other similar
   applications)?

2. Does HyperTerminal behave differently based on the choices one
   makes? For example, does it excute a part of the program for COM1,
   and another part for TCP/IP? Or, is it the responsiblility of the
   ports to provide proper services to HyperTerminal?

The reason I ask these questions is I wish to write an application
that would (kind of) replace the hardware that normally would be
connected to the COM port. So, I thought I would use a made up port
name, such as MYFAKEHARDWAREPORT, in place of COM1, or COM2 and etc,
and let HyperTerminal connect to this made up port name.

Would this work? Or, is there a better way to do this? Your
comments are highly appreciated.

In the mean time, I am back to the forum board reading up as much as
I can.

Thank you.

A Beginner

— 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

[Chris_Aseltine]

foreverbeginner wrote:

I have tried ‘fakemodem’, but, I can not install it following the
given instruction since I do not have an actual hardware, and
the installation assumes a piece of hardware, I think.

fakemodem is probably a decent place to start, you can also build the “toaster” sample and have it enumerate a PDO on which you can load fakemodem.

[Jake_Oshins]

I’ve seen a lot of posts like this recently and they worry me. Perhaps I’ve
misunderstood them, but it seems like people think that they need to install
a variant of the Toaster bus driver to enumerate their drivers that actually
do the work that they need. So, even if this isn’t the case here, I’d like
to clear this up.

If you want the PnP manager to load your driver, you can install it as a
“root enumerated” device node. This usually involves either using
devcon.exe to install something in the root* namespace or going into device
manager and specifying that you need to “add hardware” that the PnP system
couldn’t find on its own. This also installs nodes in the root* namespace.
You can, of course, also write your own installer that is equivalent to
devcon.exe which calls SetupApi itself to do this.

It’s important to note that this is how you get the toaster bus driver
installed. The toaster INF is written to match root\whateverdrivernamehere.
So if you’re installing the toaster bus driver just to avoid root
enumeration, then you’re just adding another layer of code and complexity
for no reason.

• Jake Oshins
  Windows Kernel Team

wrote in message news:xxxxx@ntdev…
> foreverbeginner wrote:
>
>> I have tried ‘fakemodem’, but, I can not install it following the
>> given instruction since I do not have an actual hardware, and
>> the installation assumes a piece of hardware, I think.
>
> fakemodem is probably a decent place to start, you can also build the
> “toaster” sample and have it enumerate a PDO on which you can load
> fakemodem.
>

[foreverbeginner]

Hello Faris,

What I wish to do is;

1. When I start HyperTeminal (or any other similar terminal programs), and go to the setup, I would like to see as a part of choices of COM1, COM2, TCP/IP and etc, the driver (thanks to Chris Aseltine, I now know it has to be a driver) that I would write. For the moment let’s call it ‘MyFakeHardware’.

2. Once I setup HyperTerminal to use ‘MyFakeHardware’ to connect, (and for the moment let’s assume, ‘MyFakeHardware’ is written such a way that HyperTerminal is expecting ‘MyFakeHardware’ to be a COM port, and therefore uses ‘Win32 serial I/O’ calls, again thanks to Chris), all I wish to do is to respond to HyperTerminal’s requests with ‘canned responses’.

For example, if I want to check out a modem firmware but actually have no finished modem hardware, I could use ‘MyFakeHardware’, and give responses to HyperTerminal. Of course, I assume I would have the proper ‘simulation’ modem responses, sort of, linked to ‘MyFakeHardware’.

Now to respond to your comment, I think once I get it going, I will need to write TCP/IP driver as well (say, call it MyFakeTCPHardware). But, for the moment, I need first to do the COM device like ‘MyFakeHardware’.

Thank you.

(I think I am confusing myself more…)

[foreverbeginner]

Hi Chis and Jake,

Thank for the comments. Between your comments, and going through DDK samples, I am beginning to get some ideas, but, not very confident with myself.

So, in general, it appear that the best thing to do is to write the drive such that it lets the system, the pnp manager, load the drivers upon power up (once intalled). But, in my case, there is no hardware involved at all. So, is it then my best choice to let devcon.exe install my driver? If so, and if I need to base my driver on the ‘fakemodem’ DDK example, how will I do it? Please remember that the ‘fakemodem’ DDK example expects to have a piece of hardware to go with it. Well, at least the instruction that came with the example seems to indicate so.

Again, thanks for the comments. I realize that all these questions must put you experts to sleep. But, your answers/comments do help/encourage me.

(still a beginner)

[OSR_Community_User]

* Jake Oshins [2007-07-09 02:46:24]:

Jake,
You are right… I think sometimes people use toaster to make plug-in/eject
more easier to be controlled.

>I’ve seen a lot of posts like this recently and they worry me. Perhaps I’ve
>misunderstood them, but it seems like people think that they need to install
>a variant of the Toaster bus driver to enumerate their drivers that actually
>do the work that they need. So, even if this isn’t the case here, I’d like
>to clear this up.
>
>If you want the PnP manager to load your driver, you can install it as a
>“root enumerated” device node. This usually involves either using
>devcon.exe to install something in the root* namespace or going into device
>manager and specifying that you need to “add hardware” that the PnP system
>couldn’t find on its own. This also installs nodes in the root* namespace.
>You can, of course, also write your own installer that is equivalent to
>devcon.exe which calls SetupApi itself to do this.
>
>It’s important to note that this is how you get the toaster bus driver
>installed. The toaster INF is written to match root\whateverdrivernamehere.
>So if you’re installing the toaster bus driver just to avoid root
>enumeration, then you’re just adding another layer of code and complexity
>for no reason.
>
>- Jake Oshins
>Windows Kernel Team
>
>
> wrote in message news:xxxxx@ntdev…
>> foreverbeginner wrote:
>>
>>> I have tried ‘fakemodem’, but, I can not install it following the
>>> given instruction since I do not have an actual hardware, and
>>> the installation assumes a piece of hardware, I think.
>>
>> fakemodem is probably a decent place to start, you can also build the
>> “toaster” sample and have it enumerate a PDO on which you can load
>> fakemodem.
>>
>
>
>
>—
>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
>
>
>

£­-
¡°»Ø¡±×ÖÓÐËÄÖÖд·¨£º
RE¡¢rE
Re¡¢re

[Matthew_Carter]

If you are on the Kernel Development Team and this worries you then perhaps
you should suggest they make an explanation of it more accessible in the WDK
documentation. First I check the index in my 6000 WDK and find “enumerating
PnP devices [WDK PnP]”. On this page, the word “root” does not appear
anywhere. The only explanations of enumerating devices is that bus drivers
enumerate them. There’s no suggestion of any possibility of enumerating
them in another way. I type in “root” as the first word in my index search
hoping to find “root enumerated devices” as an index entry, but there’s no
similar topic. If I use a keyword search I find over 500 entries that match
the keywords “root enumerated device” in them but at the top of the list is
not something that actually explains what a root enumerated device is or how
or when to use it.

“Jake Oshins” wrote in message
news:xxxxx@ntdev…
> I’ve seen a lot of posts like this recently and they worry me. Perhaps
> I’ve misunderstood them, but it seems like people think that they need to
> install a variant of the Toaster bus driver to enumerate their drivers
> that actually do the work that they need. So, even if this isn’t the case
> here, I’d like to clear this up.
>
> If you want the PnP manager to load your driver, you can install it as a
> “root enumerated” device node. This usually involves either using
> devcon.exe to install something in the root* namespace or going into
> device manager and specifying that you need to “add hardware” that the PnP
> system couldn’t find on its own. This also installs nodes in the root*
> namespace. You can, of course, also write your own installer that is
> equivalent to devcon.exe which calls SetupApi itself to do this.
>
> It’s important to note that this is how you get the toaster bus driver
> installed. The toaster INF is written to match
> root\whateverdrivernamehere. So if you’re installing the toaster bus
> driver just to avoid root enumeration, then you’re just adding another
> layer of code and complexity for no reason.

[Jake_Oshins]

That’s a good point. But keep in mind that the instructions for how to
install the toaster driver are instructions for installing a root-enumerated
device.

• Jake

“Matthew Carter” wrote in message news:xxxxx@ntdev…
> If you are on the Kernel Development Team and this worries you then
> perhaps you should suggest they make an explanation of it more accessible
> in the WDK documentation. First I check the index in my 6000 WDK and find
> “enumerating PnP devices [WDK PnP]”. On this page, the word “root” does
> not appear anywhere. The only explanations of enumerating devices is that
> bus drivers enumerate them. There’s no suggestion of any possibility of
> enumerating them in another way. I type in “root” as the first word in my
> index search hoping to find “root enumerated devices” as an index entry,
> but there’s no similar topic. If I use a keyword search I find over 500
> entries that match the keywords “root enumerated device” in them but at
> the top of the list is not something that actually explains what a root
> enumerated device is or how or when to use it.
>
> “Jake Oshins” wrote in message
> news:xxxxx@ntdev…
>> I’ve seen a lot of posts like this recently and they worry me. Perhaps
>> I’ve misunderstood them, but it seems like people think that they need to
>> install a variant of the Toaster bus driver to enumerate their drivers
>> that actually do the work that they need. So, even if this isn’t the
>> case here, I’d like to clear this up.
>>
>> If you want the PnP manager to load your driver, you can install it as a
>> “root enumerated” device node. This usually involves either using
>> devcon.exe to install something in the root* namespace or going into
>> device manager and specifying that you need to “add hardware” that the
>> PnP system couldn’t find on its own. This also installs nodes in the
>> root* namespace. You can, of course, also write your own installer that
>> is equivalent to devcon.exe which calls SetupApi itself to do this.
>>
>> It’s important to note that this is how you get the toaster bus driver
>> installed. The toaster INF is written to match
>> root\whateverdrivernamehere. So if you’re installing the toaster bus
>> driver just to avoid root enumeration, then you’re just adding another
>> layer of code and complexity for no reason.
>
>
>

[foreverbeginner]

Afer going back, and reading again the DDK documents, I understand what Jake is saying about the toaster sample, that it is not intended to be the prefered way of installing another driver, I think.

I have some more beginner’s questions;

a. I am able to build all the DDK (3790.1830) sample codes. but, I can not install any of them using DEVCON. It always fails. Why? No changes have been made to any of the codes, files, or etc.

b. I am able to install toaster sample following DDK (3790.1830) instructions, but, not able to do it following DDK (6001) instructions. Does it have anything to do with KMDF?

c. If I try to install fakemodem using the toaster sample (either, enum -p #, or notify.exe), I get the ‘New Hardware Wizzard’ pop up, and I am able to follow all the way to the last click, then the Wizzard comes back with an error message;

An error occured during the installation of the device.
The specified resource name cannot be found…

At this point, the only choice I have is to click ‘Finish’, and the end result is that I can not install.

d. The same problem as in c above, if I try to install fakemodem using ‘Add new Hardware’ route.

I sure appreciate if someone may offer me some guidance.

Thank you.

[OSR_Community_User]

Reading between the lines(as in, this may not be all of your trouble, but it is at least a part of it) b through d suggest something.

You CANNOT build the 6001 WDK WDF (KMDF or UMDF) samples with that WDK and use them on ANYTHING except the Longhorn Server Beta (6001) builds. The WDF coinstallers in the 6001 WDK cannot install the framework, and only the beta builds contain the KMDF/UMDF versions you build with the kit. This will change RSN, but I’m certain it hasn’t quite yet.

Use the 6000 WDK. Your INF files have to list kmdf or umdf version as 1.5, and you need to use the 1.5 coinstallers from that WDK in your package.

Answering the first question would require specifics- what driver? What OS? How was it installed (where were the files, how did you invoke devcon)? What is in the setupapi logs?

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@yahoo.com
Sent: Monday, July 16, 2007 6:21 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Port names such as COM1, LPT1 and etc

Afer going back, and reading again the DDK documents, I understand what Jake is saying about the toaster sample, that it is not intended to be the prefered way of installing another driver, I think.

I have some more beginner’s questions;

a. I am able to build all the DDK (3790.1830) sample codes. but, I can not install any of them using DEVCON. It always fails. Why? No changes have been made to any of the codes, files, or etc.

b. I am able to install toaster sample following DDK (3790.1830) instructions, but, not able to do it following DDK (6001) instructions. Does it have anything to do with KMDF?

c. If I try to install fakemodem using the toaster sample (either, enum -p #, or notify.exe), I get the ‘New Hardware Wizzard’ pop up, and I am able to follow all the way to the last click, then the Wizzard comes back with an error message;

An error occured during the installation of the device.
The specified resource name cannot be found…

At this point, the only choice I have is to click ‘Finish’, and the end result is that I can not install.

d. The same problem as in c above, if I try to install fakemodem using ‘Add new Hardware’ route.

I sure appreciate if someone may offer me some guidance.

Thank you.

[foreverbeginner]

Hi Bob,

Thank you for your response. I will get a copy of 6000 WDK, and try again.

As for devcon, I would like to discuss the fakemodem sample driver.

1. I have XP system.
2. Set up the ‘xp checked’ environment.
3. CD to \fakemodem subdirectory.
4. Do the ‘Build’.
5. CD to \tools\devcon\i386 subdirectory.
6. Copy mdmfake.inf and fakemodem.sys files to \tools\devcon\i386.
7. Edit mdmfake.inf to change the hardware id from, ‘PCI\VEN_9999&DEV_9999’ to ‘testmodem’
8. From \tools\devcon\i386 subdirectory, do

devcon install mdmfake.inf testmodem

The resulting display is as following;

Devcie node created. Install is complete when dirvers are updated…
Updating drivers for testmodem from c:\WINDDK\3790.1830\tools\devcon\i386\mdmfake.inf.
devcon failed.

As for the setupapi logs, Please tell me where I can find them.

Thanks again.

[Doron_Holan]

To find the logs, read
http://blogs.msdn.com/doronh/archive/2006/08/31/734412.aspx

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@yahoo.com
Sent: Tuesday, July 17, 2007 10:12 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Port names such as COM1, LPT1 and etc

Hi Bob,

Thank you for your response. I will get a copy of 6000 WDK, and try
again.

As for devcon, I would like to discuss the fakemodem sample driver.

1. I have XP system.
2. Set up the ‘xp checked’ environment.
3. CD to \fakemodem subdirectory.
4. Do the ‘Build’.
5. CD to \tools\devcon\i386 subdirectory.
6. Copy mdmfake.inf and fakemodem.sys files to \tools\devcon\i386.
7. Edit mdmfake.inf to change the hardware id from,
   ‘PCI\VEN_9999&DEV_9999’ to ‘testmodem’
8. From \tools\devcon\i386 subdirectory, do

devcon install mdmfake.inf testmodem

The resulting display is as following;

Devcie node created. Install is complete when dirvers are updated…
Updating drivers for testmodem from
c:\WINDDK\3790.1830\tools\devcon\i386\mdmfake.inf.
devcon failed.

As for the setupapi logs, Please tell me where I can find them.

Thanks again.

---

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

[foreverbeginner]

Hi Doron,

I found log files, setupapi and setupact. I will study them. Thanks. By the way, I am not sure what I did last night (I was too tired), but, this morning I found a ‘fakemodem’ had been installed in my XP. What a surprise. I am able to see ‘fakemodem’ with my HyperTerminal, and get responses for the three commands, AT, ATA, and ATD###. Now, I have to figure out what I did to make this happen. Rats!

Also, I did download WDK 6000, and I will try to work with it.

Thanks folks.