Re: "Port already open" problem

[Franc Zabkar]

On 11 Dec 2007 03:53:45 GMT, Donald G. Davis
<dgdavis@blackhole.nyx.net> put finger to keyboard and composed:

> I also have the similar DOS terminal program Telix, which I tried
>this morning on the problem computer with the external Diamond Supra
>modem. It also caused the "port already open" error. Now that I have
>seen the same behavior with Qmodem, CTS, and Telix, I'd be very surprised
>if a change in the version of Qmodem would have any different result it
>seems highly probable that using *any* program that accesses the modem in
>a DOS window will leave the port open on that system. (Next I'll check
>what happens after I simply echo an AT command to COM1 on it.)

I tried reconfiguring Qmodem so that it used COM8 rather than COM2. I
achieved this by interchanging the IRQs and IO port addresses. I
closed QModem and exited the DOS window after making the changes.
However I still encountered a "port already open" error in Windows on
COM2 after relaunching Qmodem on COM8.

- Franc Zabkar
--
Please remove one 'i' from my address when replying by email.

 

[MEB]

I'll warn this is a long winded post, but to clarify issues in my own
mind,, feel free to blast the heck out of it ...

Okay, I've checked through the tools and apps I have locally, as expected
nothing seems to address the sharing being attempted.

From the beginnings of the discussion, the idea of using a DOS box for this
type of activity seemed to me to be futile. I appreciated though, that
perhaps there might be or have been a way to accomplish the task.

Having now run through many of my old DOS programs, the issue became a
"bug", something that just didn't seem right.
So I have re-thought how things like this were accomplished IN DOS.

To perform this function, sharing/multi tasking, one needed an application
which created its own environment, and therefore could, within its self,
assign and release the devices under its control.
When I again ran across the old BBS programs, I remembered how these things
were accomplished. To understand this, one must understand that these DOS
programs were some of the earliest DOS programs which COULD multi-task,
multi-assign, re-assign *on the fly*, provide multiple access points, and
multiple running applications, while controlling the devices they were
using.
The answer lay within the BBS application - it was the master application
which needed to do such releases, re-assignments, networking, sharing, etc.
External applications could be called while running the BBS, but only if
either BBS aware or not in conflict with the master program's control. One
could *shell* to pure DOS and use some of its limited functions, but those
functions, even then, were not *device sharing* aware. It was the BBS which
need to know what was occurring, and ALLOW it to occur.
The similarities to what Windows supplies generally, and this port sharing
issue seem obvious.

For this issue, the master application - Windows - must be the one which
allows the secondary program - QMODEM - to use its claimed ports.
My attempting to find a DOS program to FORCE Windows acceptance is doomed
to the same failure which occurred in the old BBS days. The best I could
hope for would be to attempt to find an application to HIDE the other
application [a Windows aware shell to run the *sharing ignorant* application
in] from Windows, but even there, unless Windows releases its control, or
knows of the attempted sharing, it will likely fail just as it would when
running these BBSs in those long passed days.

Now here's the kicker, back then we would create a script to create a
*shell* which the BBS used and controlled, but ALLOWED the application to
run WITHIN the master application. It interfaced {if you will} with the BBS
software, and allowed that software to use some already claimed function by
temporarily freeing what was necessary, yet could be reclaimed and was still
controlled by the BBS software. This is the same basic functionality and
need that is seen in Windows, be it 9X or one of the NTs, or even one of the
servers. That's what the DOS BBS software did.

So unless I'm completely lost here [which may be the case] to achieve this
*sharing* one needs to find some Windows aware *shell application* in which
to run DOS QMODEM, or address the issue via VBS, Windows Scripting, or some
other Windows tweak or modification, just as we had to do when running those
BBSs.
I seem to remember, that in the early NTs to achieve these things, this was
also done.

NOW, the somewhat strange issue, is that you state that this sharing worked
before with your prior internal modems.
The only things that I can think of for why this previously worked, is that
those were Winmodems [completely controlled by Windows, hence Windows was
always aware and in control] and because the external modem is smart but
using a Windows controlled comm port. Hence, both the modem through QModem
AND Windows think they control the port. Obviously, with these other tests
that were done, that has been finalized beyond doubt.

Of course, the other potentials are as I previously placed. Improperly
removed Software/drivers, and registry being first in line, with QModem
settings and usage being second.

Sorry about this, just bugs the heck out of me ....

--
MEB
http://peoplescounsel.orgfree.com
________

 

[Franc Zabkar]

On 13 Dec 2007 23:10:53 GMT, Donald G. Davis
<dgdavis@blackhole.nyx.net> put finger to keyboard and composed:

>(Actually, I think the ATI3 command queries the model that returns
>CL-MD56xx on this modem--perhaps Cirrus Logic?)

Yes, it started out as Cirrus Logic, then it became Ambient, and now
it is owned by Intel.

The first "x" will tell you if your modem is controllerless (HaM) or
controller based.

See http://www.modemsite.com/56k/intel.asp

- Franc Zabkar
--
Please remove one 'i' from my address when replying by email.