On 21/11/2011 18:01, Paul wrote:
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.
It can now detect fax tones.