Re: i've tried that too

From: Jim Carlock (anonymous_at_127.0.0.1)
Date: 02/19/05 

Date: Fri, 18 Feb 2005 19:11:25 -0500

On my XP system, I'm seeing XP as creating two devices:
1) The modem device
2) The port

I'm thinking you should only be handling the modem device,
and not the port in this case.

I'm thinking along the lines that the modem is the device that
you should be searching for and using FIRST. If that fails to
turn up anything, then perhaps you can go into searching the
ports and sending commands out the ports to see if there is
a modem that responds.

Microsoft seems to want to separate the concept of the port
and the modem when dealing with XP (and NT). I'm speaking
from a hardware background rather than a programming
background.

Don't think of Opening and Closing the port. The port is
ALWAYS open. *** Grier was trying to tell you that.

Try to think of it as follows (?):
"releasing the mechanism of transport"

The way you'd release the mechanism of transport is to:

hang up the modem

ie, send "the modem" (ie, in the device manager), rather than the
port, the hangup command... ATH1 or ATH0. You might need to
send an escape sequence to it "+++ATH. Maybe there's a modem
with an obtuse command sequence?

I really don't have a clue though and I'm wondering if I'm thinking
in the proper manner myself. Most of my experience deals with
setting up modems and installing drivers and prior to the Internet
it was all setting up and configuring the Hayes modem sequences
for various modems, and being that we are on such a topic...

My first modem was a 300 baud, was purchased from Sam's
club in or about 1988 or 1989 put inside a NorthGate 286
which ran MS-DOS 4.01, later upgraded to MS-DOS 5, then
later upgraded to MS-DOS 6.2. After that I was hooked to an
online community forever...

I recently found an AOL for DOS beta version 720k floppy
disk. Funny thing... I must've copied it to that because the
80286 system I owned only held a 5 1/4" HD FDD when I
bought it. 

--
Jim Carlock
Post replies to newsgroup.
"steve" <steve@nospam.com> wrote:
i made an app that only opens and closes a port.  when i run it
with an exteral modem connected to a real port it works normally.
when i run it connected to the internal modem (virtual?) port, it
opens the port normally and hangs the program when i attempt
to close the port. this occurs on multiple computers of various
brands around the office, all with cheapie internal modems of
some kind connected to their own ports, and all runniing win xp.
the internal modem ports do not show up under ports in the
device manager, but under modems, the internal modem is
shown as connected to some com port.
i use the program (modem) to connect with modems in the field.  the program
runs normally with an external modem connected to a real port.  i can open
and close the port, process AT commands, send and receive data, etc.  and
yes, i do hangup at the end of a connection.  but the problem can be reduced
to simpler terms:  if i just load the program and then click exit the
program hangs without any connection being established.  loading the program
involves opening the com port and initializing the modem, and occurs without
any problem.  the only difference between the external modem on a real com
port version and the internal modem on its own software or virtual com port,
is that i do not try and close the port with the internal modem because that
seems to hang the program.  but if i just leave the port as is(open), the
program hangs anyway when i click exit.
any ideas?
"YYZ" <none@none.com> wrote:
> "steve" <steve@nospam.com> wrote:
> > yes, i am opening the port and the application runs as it is supposed to
> > using the internal modem.  if i try and close the port in the program,
the
> > program hangs.  so i do not close it anywhere.  and that is, i think the
>
> I don't have a solid answer for you, but have you tried making a very
small
> app that all it does is open then close the port?  I would imagine that
> little app would work fine.  If it does, then there is something else that
> your code is doing that makes this difficult.
>
> Start small -- addin all your code little bits at a time until it crashes.
> It probably won't take as long as you think, because I bet you can
identify
> LIKELY culprits and add those back in one at a time.
>
> Matt