Impact ColorFax Lite - need help with a Com port

[Loonie]

Hello Experts,

I just bought this prog and the existing comport settings were Com 1 and
Com 2. My Zoom fax is set at Com 3 and Coms 1 and 2 are considered to be
for computer-computer discussions. I read through the instructions and
did not find what I wanted.

Here is an extract from the instructions: "For instance, if you are
using 10 COM Ports on your machine, a mouse occupies COM port 1, and COM
port 2 is occupied by a modem not used for faxing, and you want to use
COM ports 3 through 10 for faxing. To do this you would set the maximum
port number to 10."

I raised the number of Comports from 8 to 10 but that changed nothing. I
even rebooted after that but still no move to Com 3.

TIA

 

[Gene E. Bloch]

Hello Experts,

I just bought this prog and the existing comport settings were Com 1 and
Com 2. My Zoom fax is set at Com 3 and Coms 1 and 2 are considered to be
for computer-computer discussions. I read through the instructions and
did not find what I wanted.

Here is an extract from the instructions: "For instance, if you are
using 10 COM Ports on your machine, a mouse occupies COM port 1, and COM
port 2 is occupied by a modem not used for faxing, and you want to use
COM ports 3 through 10 for faxing. To do this you would set the maximum
port number to 10."

I raised the number of Comports from 8 to 10 but that changed nothing. I
even rebooted after that but still no move to Com 3.

TIA

These instructions are from the dark ages.

Mouses have not been on com ports for more than a few years...

Try telling the program to use COM1 or COM2 for the modem. You have
nothing to lose, and if it works, you're home free...

 

[charlie]

Hello Experts,

I just bought this prog and the existing comport settings were Com 1 and
Com 2. My Zoom fax is set at Com 3 and Coms 1 and 2 are considered to be
for computer-computer discussions. I read through the instructions and
did not find what I wanted.

Here is an extract from the instructions: "For instance, if you are
using 10 COM Ports on your machine, a mouse occupies COM port 1, and COM
port 2 is occupied by a modem not used for faxing, and you want to use
COM ports 3 through 10 for faxing. To do this you would set the maximum
port number to 10."

I raised the number of Comports from 8 to 10 but that changed nothing. I
even rebooted after that but still no move to Com 3.

TIA

It's possible that another active fax program, such as the built-in
(sort of anyway) windows fax is active, and has the modem and com port
tied up. A complicating factor may be that the modem does not actually
use a com port (IE internal modem or USB modem.

If it helps, the program does have some level of tech support on the
mfrs web site. Unfortunately, a question similar to yours was asked in
2009, and never answered.

I assume windows recognizes the modem ??

You may have to poke around in the program files. There may be a file
that sets which ports are checked by the program, and in which order.

 

[Paul]

It's possible that another active fax program, such as the built-in
(sort of anyway) windows fax is active, and has the modem and com port
tied up. A complicating factor may be that the modem does not actually
use a com port (IE internal modem or USB modem.

If it helps, the program does have some level of tech support on the
mfrs web site. Unfortunately, a question similar to yours was asked in
2009, and never answered.

I assume windows recognizes the modem ??

You may have to poke around in the program files. There may be a file
that sets which ports are checked by the program, and in which order.

You can use the program "Handle" for debugging serial ports.

For example, on this computer, I have a modem on COM3 and the UPS
shutdown interface is on COM4. COM3 and COM4 are USB to Serial adapters.
In Handle, I can see

94: Thread ups.exe(252): 288
98: File (---) \Device\VCP0

D4: Thread hypertrm.exe(3192): 2084
120: File (---) \Device\VCP1

I'm using WinXP right now, and I used the built-in HyperTerminal program
to make the modem "busy", for the purposes of this test.

The VCP part, stands for "Virtual COM Port", a feature of the
FTDI serial chip driver.

On a computer with a "real" serial port, where the serial port is on
the I/O plate on the back of the computer, and it is hosted by the
SuperI/O chip, you might see

hypertrm.exe pid: 1904 108: \Device\Serial0

Now, Windows 7 could be using yet another naming convention, which
is why using Handle is so much fun. "Handle" is a command line program.
On Windows 7, I'd type cmd.exe in the Start box, then right click
and "Run as Administrator", and once the Window appears, cd
(change directory) to the directory with the program, then type
handle -a > handle_out.txt and have a look at handle_out.txt with
Notepad.

"Handle v3.46 By Mark Russinovich"

http://technet.microsoft.com/en-us/sysinternals/bb896655

It's probably Windows FAX and Scan doing it, but it would be
fun to confirm that.

My track record on figuring this out, is pretty poor, even
with Handle in my possession. I've spent hours staring
at that output, trying to figure out where the serial port
went

Once the serial port is free (i.e. no program "owns it"), it
should disappear from the Handle output, and then you'd expect
the new FAX program to detect it and grab it.

Paul

 

[J. P. Gilliver (John)]

In message <[email protected]>, charlie

It's possible that another active fax program, such as the built-in
(sort of anyway) windows fax is active, and has the modem and com port
tied up. A complicating factor may be that the modem does not actually
use a com port (IE internal modem or USB modem.

[]
Internal MoDems often appear (under DOS and '9x, anyway - I don't know
about XP and Vista/7) as a COM port - often, but far from always, COM3.
(I wouldn't be surprised if USB ones do too - I've not had the chance to
play with one.)

 

[Loonie]

These instructions are from the dark ages.

Mouses have not been on com ports for more than a few years...

Try telling the program to use COM1 or COM2 for the modem. You have
nothing to lose, and if it works, you're home free...

Thanks Gene,

I thought I might get a choice of ports when reinstalling the modem so
deleted Com 3. But, when reinstalling, the modem went again to Com 3.
There was no choice.

Then I deleted Com 2 and tried to install the modem there. It went
through some process but it came back with the old Com 2 - for computer
communications.

 

[Loonie]

It's possible that another active fax program, such as the built-in
(sort of anyway) windows fax is active, and has the modem and com port
tied up. A complicating factor may be that the modem does not actually
use a com port (IE internal modem or USB modem.

I had that in mind too, so I went to Programs and Features with the
intention to repeat what I had done earlier on Fax and Scan - I did
succeed in getting it off the map, or so I thought. However, I soon had
more problems with other fax programs, so I reinstalled the Fax and
Scan. Today I was fed up of that program and I went back to Programs and
Features to dump it. It was nowhere in sight. I searched many other
locations but it was well hidden. Now it's probably locking the modem on
that Com 3.

If it helps, the program does have some level of tech support on the
mfrs web site. Unfortunately, a question similar to yours was asked in
2009, and never answered.

Ouch! maybe I have wasted my money. Their support appears to be very
minimal.

I assume windows recognizes the modem ??
Definitely.

You may have to poke around in the program files. There may be a file
that sets which ports are checked by the program, and in which order.

Life is tough! Thanks Charlie

 

[Loonie]

You can use the program "Handle" for debugging serial ports.

For example, on this computer, I have a modem on COM3 and the UPS
shutdown interface is on COM4. COM3 and COM4 are USB to Serial adapters.
In Handle, I can see

94: Thread ups.exe(252): 288
98: File (---) \Device\VCP0

D4: Thread hypertrm.exe(3192): 2084
120: File (---) \Device\VCP1

I'm using WinXP right now, and I used the built-in HyperTerminal program
to make the modem "busy", for the purposes of this test.

The VCP part, stands for "Virtual COM Port", a feature of the
FTDI serial chip driver.

On a computer with a "real" serial port, where the serial port is on
the I/O plate on the back of the computer, and it is hosted by the
SuperI/O chip, you might see

hypertrm.exe pid: 1904 108: \Device\Serial0

Now, Windows 7 could be using yet another naming convention, which
is why using Handle is so much fun. "Handle" is a command line program.
On Windows 7, I'd type cmd.exe in the Start box, then right click
and "Run as Administrator", and once the Window appears, cd
(change directory) to the directory with the program, then type
handle -a > handle_out.txt and have a look at handle_out.txt with
Notepad.

"Handle v3.46 By Mark Russinovich"

http://technet.microsoft.com/en-us/sysinternals/bb896655

It's probably Windows FAX and Scan doing it, but it would be
fun to confirm that.

My track record on figuring this out, is pretty poor, even
with Handle in my possession. I've spent hours staring
at that output, trying to figure out where the serial port
went

Once the serial port is free (i.e. no program "owns it"), it
should disappear from the Handle output, and then you'd expect
the new FAX program to detect it and grab it.

Paul

Thanks Paul.

I had never heard of Handle until now. I installed it but it seemed to
flash up and then disappear. Will try some more soon.

 

[Stan Brown]

On 20/11/2011 03:58, Paul wrote:

I had never heard of Handle until now. I installed it but it seemed to
flash up and then disappear. Will try some more soon.

Did you read the documentation at the link Paul gave? You have to
run it on the command line.

The same page also says "You can also get a GUI-based version of this
program, Process Explorer[1], here at Sysinternals." I've used
Process Explorer before, but I don't know whether it reveals COM
ports. (If it does, then the help file doesn't explain how to view
that information.)

[1] http://technet.microsoft.com/en-us/sysinternals/bb896653

 

[Loonie]

On 20/11/2011 03:58, Paul wrote:

I had never heard of Handle until now. I installed it but it seemed to
flash up and then disappear. Will try some more soon.

Did you read the documentation at the link Paul gave? You have to
run it on the command line.

The same page also says "You can also get a GUI-based version of this
program, Process Explorer[1], here at Sysinternals." I've used
Process Explorer before, but I don't know whether it reveals COM
ports. (If it does, then the help file doesn't explain how to view
that information.)

[1] http://technet.microsoft.com/en-us/sysinternals/bb896653

Thank you Stan.

Yesterday I downloaded Sysinternals but I have not tried it yet

I always keep the Command prompt on my desktop. I did read Paul's
article but I found using the word Handle did nothing at the Cmd prompt.

Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.

C:\Users\jvalh>handle
'handle' is not recognized as an internal or external command,
operable program or batch file.

Today I tried:

C:\Users\jvalh>handle windows\system
Result:
'handle' is not recognized as an internal or external command,
operable program or batch file.

Next I tried: handle -p exp

Result:

'handle' is not recognized as an internal or external command,
operable program or batch file.

The above came from >
http://technet.microsoft.com/en-us/sysinternals/bb896655

The problems might come from the fact that my Win 7 is the Home Premium
version.

 

[Bob I]

On 20/11/2011 03:58, Paul wrote:

You can use the program "Handle" for debugging serial ports.

http://technet.microsoft.com/en-us/sysinternals/bb896655

I had never heard of Handle until now. I installed it but it seemed to
flash up and then disappear. Will try some more soon.

Did you read the documentation at the link Paul gave? You have to
run it on the command line.

The same page also says "You can also get a GUI-based version of this
program, Process Explorer[1], here at Sysinternals." I've used
Process Explorer before, but I don't know whether it reveals COM
ports. (If it does, then the help file doesn't explain how to view
that information.)

[1] http://technet.microsoft.com/en-us/sysinternals/bb896653

Thank you Stan.

Yesterday I downloaded Sysinternals but I have not tried it yet

I always keep the Command prompt on my desktop. I did read Paul's
article but I found using the word Handle did nothing at the Cmd prompt.

Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.

C:\Users\jvalh>handle
'handle' is not recognized as an internal or external command,
operable program or batch file.

Today I tried:

C:\Users\jvalh>handle windows\system
Result:
'handle' is not recognized as an internal or external command,
operable program or batch file.

Next I tried: handle -p exp

Result:

'handle' is not recognized as an internal or external command,
operable program or batch file.

The above came from >
http://technet.microsoft.com/en-us/sysinternals/bb896655

The problems might come from the fact that my Win 7 is the Home Premium
version.

Any reason you don't go into Device Manager and set the Com Port to be #3?

 

[Paul]

On 20/11/2011 03:58, Paul wrote:

You can use the program "Handle" for debugging serial ports.

http://technet.microsoft.com/en-us/sysinternals/bb896655

I had never heard of Handle until now. I installed it but it seemed to
flash up and then disappear. Will try some more soon.

Did you read the documentation at the link Paul gave? You have to
run it on the command line.

The same page also says "You can also get a GUI-based version of this
program, Process Explorer[1], here at Sysinternals." I've used
Process Explorer before, but I don't know whether it reveals COM
ports. (If it does, then the help file doesn't explain how to view
that information.)

[1] http://technet.microsoft.com/en-us/sysinternals/bb896653

Thank you Stan.

Yesterday I downloaded Sysinternals but I have not tried it yet

I always keep the Command prompt on my desktop. I did read Paul's
article but I found using the word Handle did nothing at the Cmd prompt.

Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.

C:\Users\jvalh>handle
'handle' is not recognized as an internal or external command,
operable program or batch file.

Today I tried:

C:\Users\jvalh>handle windows\system
Result:
'handle' is not recognized as an internal or external command,
operable program or batch file.

Next I tried: handle -p exp

Result:

'handle' is not recognized as an internal or external command,
operable program or batch file.

The above came from >
http://technet.microsoft.com/en-us/sysinternals/bb896655

The problems might come from the fact that my Win 7 is the Home Premium
version.

It's got nothing to do with that.

Command prompt is a "shell", and a shell has things called environment
variables. Environment variables contain "preferences" for the shell
while it's running.

When you type a command, such as

C:> handle

the shell consults a variable called the "path". This is my "path"
variable right now. (I've shortened this a bit for educational purposes.
I've also added space characters, to delimit the chunks. When you
run program installers, such as Xilinx in this example, the installer
can add things to the path, as well as the user adding things.)

%XILINX%\bin\nt; %SystemRoot%\system32; %SystemRoot%; %SystemRoot%\System32\Wbem

Now, each of those chunks is a directory specification. And what I'm
telling the OS with that, is "there are four directories you can
search for that HANDLE program of mine".

Well, guess what, handle isn't stored in there. It's in none
of those directories, so it cannot be found.

What the OS will do though, is search the current working directory.
If I "change directories" with the cd command, I get to control
the current working directory. Say, for example, I unzip the HANDLE
program, into its own directory called handle. Then, what I'd do is:

C:> cd \ # This returns you to top level of C:
C:> cd downloads # Going one level deeper
C:\Downloads> cd handle # Going one level deeper
C:\Downloads\Handle> handle.exe # Now it works, because handle.exe is
# within the current working directory.

So the path search, includes the four chunks in my example,
but also includes the current working directory as a place to
search.

Alternately, I can type an "absolute path" to it.

C:> C:\Downloads\Handle\handle.exe

and by specifying an absolute path, the shell doesn't need to guess
at the location by searching all the chunks in the path variable.
I've told the shell, exactly where it's stored.

If you edit the path variable, it's possible to add elements to the
path. But if you're downloading executables all over the place, that
idea rapidly loses its charm.

If the program happens to be in a directory with a "space" in the
name, then quote characters can be used to protect the parsing
of the directory path. For example, the "Program Files" directory
has a space in the name, so any executable below that, will
need some double quotes for insulation. You can use the
double quotes, whether the path has a space character in it or not.
Now my command is well insulated.

C:> "C:\Downloads\Handle\handle.exe" -a > C:\Downloads\handle_out.txt

will put a list of handles into C:\Downloads\handle_out.txt as the
output file. That particular command syntax, of providing absolute
paths for both the executable and for the output from the command,
means the command is pretty well isolated from all "shell-isms".
If you specify everything in gory details, then the command
can't fail.

HTH,
Paul

 

[Loonie]

On Sun, 20 Nov 2011 21:49:41 +0000, Loonie wrote:

On 20/11/2011 03:58, Paul wrote:

You can use the program "Handle" for debugging serial ports.

http://technet.microsoft.com/en-us/sysinternals/bb896655

I had never heard of Handle until now. I installed it but it seemed to
flash up and then disappear. Will try some more soon.

Did you read the documentation at the link Paul gave? You have to
run it on the command line.

The same page also says "You can also get a GUI-based version of this
program, Process Explorer[1], here at Sysinternals." I've used
Process Explorer before, but I don't know whether it reveals COM
ports. (If it does, then the help file doesn't explain how to view
that information.)

[1] http://technet.microsoft.com/en-us/sysinternals/bb896653

Thank you Stan.

Yesterday I downloaded Sysinternals but I have not tried it yet

I always keep the Command prompt on my desktop. I did read Paul's
article but I found using the word Handle did nothing at the Cmd prompt.

Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.

C:\Users\jvalh>handle
'handle' is not recognized as an internal or external command,
operable program or batch file.

Today I tried:

C:\Users\jvalh>handle windows\system
Result:
'handle' is not recognized as an internal or external command,
operable program or batch file.

Next I tried: handle -p exp

Result:

'handle' is not recognized as an internal or external command,
operable program or batch file.

The above came from >
http://technet.microsoft.com/en-us/sysinternals/bb896655

The problems might come from the fact that my Win 7 is the Home Premium
version.

Any reason you don't go into Device Manager and set the Com Port to be #3?

Hello again Bob.

I played around with Phone and Modem in the Control Panel and ended up with:

Com 1 - Communications cable between two computers
Com 2 - Communications cable between two computers
Com 1 - Standard 56000 bps modem
Com 2 - Standard 56000 bps modem #2
Com 3 - USB Modem

But I am not sure that gets me anywhere useful.

While doing some playing with ColorFax it suddenly came up with a modem
on Com 2. I even snapped an image of that claim. I hopped over to check
the control panel but it had not changed the com port - was still at Com 3.

 

[Loonie]

On Sun, 20 Nov 2011 21:49:41 +0000, Loonie wrote:

On 20/11/2011 03:58, Paul wrote:

You can use the program "Handle" for debugging serial ports.

http://technet.microsoft.com/en-us/sysinternals/bb896655

I had never heard of Handle until now. I installed it but it seemed to
flash up and then disappear. Will try some more soon.

Did you read the documentation at the link Paul gave? You have to
run it on the command line.

The same page also says "You can also get a GUI-based version of this
program, Process Explorer[1], here at Sysinternals." I've used
Process Explorer before, but I don't know whether it reveals COM
ports. (If it does, then the help file doesn't explain how to view
that information.)

[1] http://technet.microsoft.com/en-us/sysinternals/bb896653

Thank you Stan.

Yesterday I downloaded Sysinternals but I have not tried it yet

I always keep the Command prompt on my desktop. I did read Paul's
article but I found using the word Handle did nothing at the Cmd prompt.

Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.

C:\Users\jvalh>handle
'handle' is not recognized as an internal or external command,
operable program or batch file.

Today I tried:

C:\Users\jvalh>handle windows\system
Result:
'handle' is not recognized as an internal or external command,
operable program or batch file.

Next I tried: handle -p exp

Result:

'handle' is not recognized as an internal or external command,
operable program or batch file.

The above came from >
http://technet.microsoft.com/en-us/sysinternals/bb896655

The problems might come from the fact that my Win 7 is the Home
Premium version.

It's got nothing to do with that.

Command prompt is a "shell", and a shell has things called environment
variables. Environment variables contain "preferences" for the shell
while it's running.

When you type a command, such as

C:> handle

the shell consults a variable called the "path". This is my "path"
variable right now. (I've shortened this a bit for educational purposes.
I've also added space characters, to delimit the chunks. When you
run program installers, such as Xilinx in this example, the installer
can add things to the path, as well as the user adding things.)

%XILINX%\bin\nt; %SystemRoot%\system32; %SystemRoot%;
%SystemRoot%\System32\Wbem

Now, each of those chunks is a directory specification. And what I'm
telling the OS with that, is "there are four directories you can
search for that HANDLE program of mine".

Well, guess what, handle isn't stored in there. It's in none
of those directories, so it cannot be found.

What the OS will do though, is search the current working directory.
If I "change directories" with the cd command, I get to control
the current working directory. Say, for example, I unzip the HANDLE
program, into its own directory called handle. Then, what I'd do is:

C:> cd \ # This returns you to top level of C:
C:> cd downloads # Going one level deeper
C:\Downloads> cd handle # Going one level deeper
C:\Downloads\Handle> handle.exe # Now it works, because handle.exe is
# within the current working directory.

So the path search, includes the four chunks in my example,
but also includes the current working directory as a place to
search.

Alternately, I can type an "absolute path" to it.

C:> C:\Downloads\Handle\handle.exe

and by specifying an absolute path, the shell doesn't need to guess
at the location by searching all the chunks in the path variable.
I've told the shell, exactly where it's stored.

If you edit the path variable, it's possible to add elements to the
path. But if you're downloading executables all over the place, that
idea rapidly loses its charm.

If the program happens to be in a directory with a "space" in the
name, then quote characters can be used to protect the parsing
of the directory path. For example, the "Program Files" directory
has a space in the name, so any executable below that, will
need some double quotes for insulation. You can use the
double quotes, whether the path has a space character in it or not.
Now my command is well insulated.

C:> "C:\Downloads\Handle\handle.exe" -a > C:\Downloads\handle_out.txt

will put a list of handles into C:\Downloads\handle_out.txt as the
output file. That particular command syntax, of providing absolute
paths for both the executable and for the output from the command,
means the command is pretty well isolated from all "shell-isms".
If you specify everything in gory details, then the command
can't fail.

HTH,
Paul

Thanks again Paul.

In the following, I suspect your will think our two computers will be
talking like a Chinese and an Arab.

Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.

C:\Users\jvalh>C:> cd \ # This returns you to top level of C:
First Try:
C:\Users\jvalh>C:> cd downloads # Going one level deeper
-Worked

C:\Users\jvalh>C:\Downloads> cd handle # Going one level deeper
'C:\Downloads' is not recognized as an internal or external command,
operable program or batch file.
-Did not work

Alternately, I can type an "absolute path" to it.

Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.

C:\Users\jvalh>C:> cd \ # This returns you to top level of C:

C:\Users\jvalh>
C:\Users\jvalh>C:> cd downloads # Going one level deeper

C:\Users\jvalh>C:\Downloads> cd handle # Going one level deeper
'C:\Downloads' is not recognized as an internal or external command,
operable program or batch file.

C:\Users\jvalh>C:\Downloads\Handle\handle.exe
The system cannot find the path specified.

This is beyond me Paul.

 

[Paul]

On 20/11/2011 23:28, Stan Brown wrote:
On Sun, 20 Nov 2011 21:49:41 +0000, Loonie wrote:

On 20/11/2011 03:58, Paul wrote:

You can use the program "Handle" for debugging serial ports.

http://technet.microsoft.com/en-us/sysinternals/bb896655

I had never heard of Handle until now. I installed it but it seemed to
flash up and then disappear. Will try some more soon.

Did you read the documentation at the link Paul gave? You have to
run it on the command line.

The same page also says "You can also get a GUI-based version of this
program, Process Explorer[1], here at Sysinternals." I've used
Process Explorer before, but I don't know whether it reveals COM
ports. (If it does, then the help file doesn't explain how to view
that information.)

[1] http://technet.microsoft.com/en-us/sysinternals/bb896653


Thank you Stan.

Yesterday I downloaded Sysinternals but I have not tried it yet

I always keep the Command prompt on my desktop. I did read Paul's
article but I found using the word Handle did nothing at the Cmd prompt.

Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.

C:\Users\jvalh>handle
'handle' is not recognized as an internal or external command,
operable program or batch file.

Today I tried:

C:\Users\jvalh>handle windows\system

Result:
'handle' is not recognized as an internal or external command,
operable program or batch file.

Next I tried: handle -p exp

Result:
'handle' is not recognized as an internal or external command,
operable program or batch file.

The above came from >
http://technet.microsoft.com/en-us/sysinternals/bb896655

The problems might come from the fact that my Win 7 is the Home
Premium version.

It's got nothing to do with that.

Command prompt is a "shell", and a shell has things called environment
variables. Environment variables contain "preferences" for the shell
while it's running.

When you type a command, such as

C:> handle

the shell consults a variable called the "path". This is my "path"
variable right now. (I've shortened this a bit for educational purposes.
I've also added space characters, to delimit the chunks. When you
run program installers, such as Xilinx in this example, the installer
can add things to the path, as well as the user adding things.)

%XILINX%\bin\nt; %SystemRoot%\system32; %SystemRoot%;
%SystemRoot%\System32\Wbem

Now, each of those chunks is a directory specification. And what I'm
telling the OS with that, is "there are four directories you can
search for that HANDLE program of mine".

Well, guess what, handle isn't stored in there. It's in none
of those directories, so it cannot be found.

What the OS will do though, is search the current working directory.
If I "change directories" with the cd command, I get to control
the current working directory. Say, for example, I unzip the HANDLE
program, into its own directory called handle. Then, what I'd do is:

C:> cd \ # This returns you to top level of C:
C:> cd downloads # Going one level deeper
C:\Downloads> cd handle # Going one level deeper
C:\Downloads\Handle> handle.exe # Now it works, because handle.exe is
# within the current working directory.

So the path search, includes the four chunks in my example,
but also includes the current working directory as a place to
search.

Alternately, I can type an "absolute path" to it.

C:> C:\Downloads\Handle\handle.exe

and by specifying an absolute path, the shell doesn't need to guess
at the location by searching all the chunks in the path variable.
I've told the shell, exactly where it's stored.

If you edit the path variable, it's possible to add elements to the
path. But if you're downloading executables all over the place, that
idea rapidly loses its charm.

If the program happens to be in a directory with a "space" in the
name, then quote characters can be used to protect the parsing
of the directory path. For example, the "Program Files" directory
has a space in the name, so any executable below that, will
need some double quotes for insulation. You can use the
double quotes, whether the path has a space character in it or not.
Now my command is well insulated.

C:> "C:\Downloads\Handle\handle.exe" -a > C:\Downloads\handle_out.txt

will put a list of handles into C:\Downloads\handle_out.txt as the
output file. That particular command syntax, of providing absolute
paths for both the executable and for the output from the command,
means the command is pretty well isolated from all "shell-isms".
If you specify everything in gory details, then the command
can't fail.

HTH,
Paul

Thanks again Paul.

In the following, I suspect your will think our two computers will be
talking like a Chinese and an Arab.

Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.

C:\Users\jvalh>C:> cd \ # This returns you to top level of C:
First Try:
C:\Users\jvalh>C:> cd downloads # Going one level deeper
-Worked

C:\Users\jvalh>C:\Downloads> cd handle # Going one level deeper
'C:\Downloads' is not recognized as an internal or external command,
operable program or batch file.
-Did not work

Alternately, I can type an "absolute path" to it.

Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.

C:\Users\jvalh>C:> cd \ # This returns you to top level of C:

C:\Users\jvalh>
C:\Users\jvalh>C:> cd downloads # Going one level deeper

C:\Users\jvalh>C:\Downloads> cd handle # Going one level deeper
'C:\Downloads' is not recognized as an internal or external command,
operable program or batch file.

C:\Users\jvalh>C:\Downloads\Handle\handle.exe
The system cannot find the path specified.

This is beyond me Paul.

And if I take your entire post, and paste that into a command
prompt window, I'm baffled by the results as well

It's good to see my effort to explain it, wasn't wasted.

Perhaps the "#" character, was indicating the start of a comment.

Paul

 

[Bob I]

On 20/11/2011 23:28, Stan Brown wrote:
On Sun, 20 Nov 2011 21:49:41 +0000, Loonie wrote:

On 20/11/2011 03:58, Paul wrote:

You can use the program "Handle" for debugging serial ports.

http://technet.microsoft.com/en-us/sysinternals/bb896655

I had never heard of Handle until now. I installed it but it seemed to
flash up and then disappear. Will try some more soon.

Did you read the documentation at the link Paul gave? You have to
run it on the command line.

The same page also says "You can also get a GUI-based version of this
program, Process Explorer[1], here at Sysinternals." I've used
Process Explorer before, but I don't know whether it reveals COM
ports. (If it does, then the help file doesn't explain how to view
that information.)

[1] http://technet.microsoft.com/en-us/sysinternals/bb896653


Thank you Stan.

Yesterday I downloaded Sysinternals but I have not tried it yet

I always keep the Command prompt on my desktop. I did read Paul's
article but I found using the word Handle did nothing at the Cmd prompt.

Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.

C:\Users\jvalh>handle
'handle' is not recognized as an internal or external command,
operable program or batch file.

Today I tried:

C:\Users\jvalh>handle windows\system

Result:
'handle' is not recognized as an internal or external command,
operable program or batch file.

Next I tried: handle -p exp

Result:
'handle' is not recognized as an internal or external command,
operable program or batch file.

The above came from >
http://technet.microsoft.com/en-us/sysinternals/bb896655

The problems might come from the fact that my Win 7 is the Home Premium
version.

Any reason you don't go into Device Manager and set the Com Port to be
#3?

Hello again Bob.

I played around with Phone and Modem in the Control Panel and ended up
with:

Com 1 - Communications cable between two computers
Com 2 - Communications cable between two computers
Com 1 - Standard 56000 bps modem
Com 2 - Standard 56000 bps modem #2
Com 3 - USB Modem

But I am not sure that gets me anywhere useful.

While doing some playing with ColorFax it suddenly came up with a modem
on Com 2. I even snapped an image of that claim. I hopped over to check
the control panel but it had not changed the com port - was still at Com 3.

And when you look in Device Manager?

 

[Gene E. Bloch]

Loonie wrote:
On 20/11/2011 23:28, Stan Brown wrote:
On Sun, 20 Nov 2011 21:49:41 +0000, Loonie wrote:

On 20/11/2011 03:58, Paul wrote:

You can use the program "Handle" for debugging serial ports.

http://technet.microsoft.com/en-us/sysinternals/bb896655

I had never heard of Handle until now. I installed it but it seemed to
flash up and then disappear. Will try some more soon.

Did you read the documentation at the link Paul gave? You have to
run it on the command line.

The same page also says "You can also get a GUI-based version of this
program, Process Explorer[1], here at Sysinternals." I've used
Process Explorer before, but I don't know whether it reveals COM
ports. (If it does, then the help file doesn't explain how to view
that information.)

[1] http://technet.microsoft.com/en-us/sysinternals/bb896653


Thank you Stan.

Yesterday I downloaded Sysinternals but I have not tried it yet

I always keep the Command prompt on my desktop. I did read Paul's
article but I found using the word Handle did nothing at the Cmd prompt.

Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.

C:\Users\jvalh>handle
'handle' is not recognized as an internal or external command,
operable program or batch file.

Today I tried:

C:\Users\jvalh>handle windows\system

Result:
'handle' is not recognized as an internal or external command,
operable program or batch file.

Next I tried: handle -p exp

Result:
'handle' is not recognized as an internal or external command,
operable program or batch file.

The above came from >
http://technet.microsoft.com/en-us/sysinternals/bb896655

The problems might come from the fact that my Win 7 is the Home
Premium version.

It's got nothing to do with that.

Command prompt is a "shell", and a shell has things called environment
variables. Environment variables contain "preferences" for the shell
while it's running.

When you type a command, such as

C:> handle

the shell consults a variable called the "path". This is my "path"
variable right now. (I've shortened this a bit for educational purposes.
I've also added space characters, to delimit the chunks. When you
run program installers, such as Xilinx in this example, the installer
can add things to the path, as well as the user adding things.)

%XILINX%\bin\nt; %SystemRoot%\system32; %SystemRoot%;
%SystemRoot%\System32\Wbem

Now, each of those chunks is a directory specification. And what I'm
telling the OS with that, is "there are four directories you can
search for that HANDLE program of mine".

Well, guess what, handle isn't stored in there. It's in none
of those directories, so it cannot be found.

What the OS will do though, is search the current working directory.
If I "change directories" with the cd command, I get to control
the current working directory. Say, for example, I unzip the HANDLE
program, into its own directory called handle. Then, what I'd do is:

C:> cd \ # This returns you to top level of C:
C:> cd downloads # Going one level deeper
C:\Downloads> cd handle # Going one level deeper
C:\Downloads\Handle> handle.exe # Now it works, because handle.exe is
# within the current working directory.

So the path search, includes the four chunks in my example,
but also includes the current working directory as a place to
search.

Alternately, I can type an "absolute path" to it.

C:> C:\Downloads\Handle\handle.exe

and by specifying an absolute path, the shell doesn't need to guess
at the location by searching all the chunks in the path variable.
I've told the shell, exactly where it's stored.

If you edit the path variable, it's possible to add elements to the
path. But if you're downloading executables all over the place, that
idea rapidly loses its charm.

If the program happens to be in a directory with a "space" in the
name, then quote characters can be used to protect the parsing
of the directory path. For example, the "Program Files" directory
has a space in the name, so any executable below that, will
need some double quotes for insulation. You can use the
double quotes, whether the path has a space character in it or not.
Now my command is well insulated.

C:> "C:\Downloads\Handle\handle.exe" -a > C:\Downloads\handle_out.txt

will put a list of handles into C:\Downloads\handle_out.txt as the
output file. That particular command syntax, of providing absolute
paths for both the executable and for the output from the command,
means the command is pretty well isolated from all "shell-isms".
If you specify everything in gory details, then the command
can't fail.

HTH,
Paul

Thanks again Paul.

In the following, I suspect your will think our two computers will be
talking like a Chinese and an Arab.

Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.

C:\Users\jvalh>C:> cd \ # This returns you to top level of C:
First Try:
C:\Users\jvalh>C:> cd downloads # Going one level deeper
-Worked

C:\Users\jvalh>C:\Downloads> cd handle # Going one level deeper
'C:\Downloads' is not recognized as an internal or external command,
operable program or batch file.
-Did not work

Alternately, I can type an "absolute path" to it.

Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.

C:\Users\jvalh>C:> cd \ # This returns you to top level of C:

C:\Users\jvalh>
C:\Users\jvalh>C:> cd downloads # Going one level deeper

C:\Users\jvalh>C:\Downloads> cd handle # Going one level deeper
'C:\Downloads' is not recognized as an internal or external command,
operable program or batch file.

C:\Users\jvalh>C:\Downloads\Handle\handle.exe
The system cannot find the path specified.

This is beyond me Paul.

And if I take your entire post, and paste that into a command
prompt window, I'm baffled by the results as well

It's good to see my effort to explain it, wasn't wasted.

Perhaps the "#" character, was indicating the start of a comment.

Paul

What happened was that Loonie was typing the prompt (which was showing
in the sample code) as a command

Loonie: the commands are what is *after* the prompt, that is after the
"C:>" or the ">C:\Downloads>" and other things that look like that. The
prompt is displayed by the command processor to show the user which
directory is current.

 

[Stan Brown]

I always keep the Command prompt on my desktop. I did read Paul's
article but I found using the word Handle did nothing at the Cmd prompt.

Did you use any of the options? You should have got output; I did.

Even if you didn't have the right path, you would have got an error
message from the operating system.

 

[Loonie]

On 11/21/2011 4:02 AM, Loonie wrote:
On 20/11/2011 23:28, Stan Brown wrote:
On Sun, 20 Nov 2011 21:49:41 +0000, Loonie wrote:

On 20/11/2011 03:58, Paul wrote:

You can use the program "Handle" for debugging serial ports.

http://technet.microsoft.com/en-us/sysinternals/bb896655

I had never heard of Handle until now. I installed it but it
seemed to
flash up and then disappear. Will try some more soon.

Did you read the documentation at the link Paul gave? You have to
run it on the command line.

The same page also says "You can also get a GUI-based version of this
program, Process Explorer[1], here at Sysinternals." I've used
Process Explorer before, but I don't know whether it reveals COM
ports. (If it does, then the help file doesn't explain how to view
that information.)

[1] http://technet.microsoft.com/en-us/sysinternals/bb896653


Thank you Stan.

Yesterday I downloaded Sysinternals but I have not tried it yet

I always keep the Command prompt on my desktop. I did read Paul's
article but I found using the word Handle did nothing at the Cmd
prompt.

Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.

C:\Users\jvalh>handle
'handle' is not recognized as an internal or external command,
operable program or batch file.

Today I tried:

C:\Users\jvalh>handle windows\system

Result:
'handle' is not recognized as an internal or external command,
operable program or batch file.

Next I tried: handle -p exp

Result:
'handle' is not recognized as an internal or external command,
operable program or batch file.

The above came from >
http://technet.microsoft.com/en-us/sysinternals/bb896655

The problems might come from the fact that my Win 7 is the Home Premium
version.


Any reason you don't go into Device Manager and set the Com Port to be
#3?

Hello again Bob.

I played around with Phone and Modem in the Control Panel and ended up
with:

Com 1 - Communications cable between two computers
Com 2 - Communications cable between two computers
Com 1 - Standard 56000 bps modem
Com 2 - Standard 56000 bps modem #2
Com 3 - USB Modem

But I am not sure that gets me anywhere useful.

While doing some playing with ColorFax it suddenly came up with a modem
on Com 2. I even snapped an image of that claim. I hopped over to check
the control panel but it had not changed the com port - was still at
Com 3.

And when you look in Device Manager?

I have looked in it several times recently and this morning I finally
found the setting. The modem is now on Com 4.
Thank you for your interest.

 

[Loonie]

Loonie wrote:
On 20/11/2011 23:28, Stan Brown wrote:
On Sun, 20 Nov 2011 21:49:41 +0000, Loonie wrote:

On 20/11/2011 03:58, Paul wrote:

You can use the program "Handle" for debugging serial ports.

http://technet.microsoft.com/en-us/sysinternals/bb896655

I had never heard of Handle until now. I installed it but it
seemed to
flash up and then disappear. Will try some more soon.

Did you read the documentation at the link Paul gave? You have to
run it on the command line.

The same page also says "You can also get a GUI-based version of this
program, Process Explorer[1], here at Sysinternals." I've used
Process Explorer before, but I don't know whether it reveals COM
ports. (If it does, then the help file doesn't explain how to view
that information.)

[1] http://technet.microsoft.com/en-us/sysinternals/bb896653


Thank you Stan.

Yesterday I downloaded Sysinternals but I have not tried it yet

I always keep the Command prompt on my desktop. I did read Paul's
article but I found using the word Handle did nothing at the Cmd
prompt.

Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.

C:\Users\jvalh>handle
'handle' is not recognized as an internal or external command,
operable program or batch file.

Today I tried:

C:\Users\jvalh>handle windows\system

Result:
'handle' is not recognized as an internal or external command,
operable program or batch file.

Next I tried: handle -p exp

Result:
'handle' is not recognized as an internal or external command,
operable program or batch file.

The above came from >
http://technet.microsoft.com/en-us/sysinternals/bb896655

The problems might come from the fact that my Win 7 is the Home
Premium version.

It's got nothing to do with that.

Command prompt is a "shell", and a shell has things called environment
variables. Environment variables contain "preferences" for the shell
while it's running.

When you type a command, such as

C:> handle

the shell consults a variable called the "path". This is my "path"
variable right now. (I've shortened this a bit for educational purposes.
I've also added space characters, to delimit the chunks. When you
run program installers, such as Xilinx in this example, the installer
can add things to the path, as well as the user adding things.)

%XILINX%\bin\nt; %SystemRoot%\system32; %SystemRoot%;
%SystemRoot%\System32\Wbem

Now, each of those chunks is a directory specification. And what I'm
telling the OS with that, is "there are four directories you can
search for that HANDLE program of mine".

Well, guess what, handle isn't stored in there. It's in none
of those directories, so it cannot be found.

What the OS will do though, is search the current working directory.
If I "change directories" with the cd command, I get to control
the current working directory. Say, for example, I unzip the HANDLE
program, into its own directory called handle. Then, what I'd do is:

C:> cd \ # This returns you to top level of C:
C:> cd downloads # Going one level deeper
C:\Downloads> cd handle # Going one level deeper
C:\Downloads\Handle> handle.exe # Now it works, because handle.exe is
# within the current working directory.

So the path search, includes the four chunks in my example,
but also includes the current working directory as a place to
search.

Alternately, I can type an "absolute path" to it.

C:> C:\Downloads\Handle\handle.exe

and by specifying an absolute path, the shell doesn't need to guess
at the location by searching all the chunks in the path variable.
I've told the shell, exactly where it's stored.

If you edit the path variable, it's possible to add elements to the
path. But if you're downloading executables all over the place, that
idea rapidly loses its charm.

If the program happens to be in a directory with a "space" in the
name, then quote characters can be used to protect the parsing
of the directory path. For example, the "Program Files" directory
has a space in the name, so any executable below that, will
need some double quotes for insulation. You can use the
double quotes, whether the path has a space character in it or not.
Now my command is well insulated.

C:> "C:\Downloads\Handle\handle.exe" -a > C:\Downloads\handle_out.txt

will put a list of handles into C:\Downloads\handle_out.txt as the
output file. That particular command syntax, of providing absolute
paths for both the executable and for the output from the command,
means the command is pretty well isolated from all "shell-isms".
If you specify everything in gory details, then the command
can't fail.

HTH,
Paul

Thanks again Paul.

In the following, I suspect your will think our two computers will be
talking like a Chinese and an Arab.

Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.

C:\Users\jvalh>C:> cd \ # This returns you to top level of C:
First Try:
C:\Users\jvalh>C:> cd downloads # Going one level deeper
-Worked

C:\Users\jvalh>C:\Downloads> cd handle # Going one level deeper
'C:\Downloads' is not recognized as an internal or external command,
operable program or batch file.
-Did not work

Alternately, I can type an "absolute path" to it.

Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.

C:\Users\jvalh>C:> cd \ # This returns you to top level of C:

C:\Users\jvalh>
C:\Users\jvalh>C:> cd downloads # Going one level deeper

C:\Users\jvalh>C:\Downloads> cd handle # Going one level deeper
'C:\Downloads' is not recognized as an internal or external command,
operable program or batch file.

C:\Users\jvalh>C:\Downloads\Handle\handle.exe
The system cannot find the path specified.

This is beyond me Paul.

And if I take your entire post, and paste that into a command
prompt window, I'm baffled by the results as well

It's good to see my effort to explain it, wasn't wasted.

Perhaps the "#" character, was indicating the start of a comment.

Paul

Hello again Paul,

I didn't pass all that info in at the same time. It was the short tests
that I tried to work on and, as you see, most of them are a mess.

I also downloaded and had a look at the Process Explorer. To be honest I
came across nothing new to me. I guess <sob> I'll have to go back to
kindergarten again