MS>> ...an image is worth a thousand words...  ...command-line samples:
MS>> RLFossil.EXE 2 1 "Commo.EXE /:INT-14 /{*1,,3,V,}"
ML>> What versions of {COMMO}, Telix and RLFossil are those, please?

 MS>      As i mentioned above, `{Commo}' is version v7.7 (the last
 MS> one there was before its source-code and author both disapeared).

ahh, i had missed that... my thoughts have been to gather everything
together for others... i have {COMMO} v7.7 but i note that it has a 30 day
trial period and that there is a COMMO.ID file for registered users... how
bad does it get if it is not registered? have mr. bruckner's people
released a free key and/or are they continuing on with {COMMO}'s
development?

 MS> As for `Telix', i'm refering to version 3.51 but you tell me if
 MS> it's the last release...

hummm... i have a floppy here of Telix 3.22 from deltacomm... i know i've
seen 3.51... i just wonder where? i wasn't aware of any version of telix
supporting INT14/FOSSIL stuffs until you mentioned it... a quick search for
"14" thru the v3.22 docs i have turns this up...

=====
Problem:

We have our modems on a network and we need a network version of Telix in
order to access them.  Does Telix have network support built in?


Solution:

Networking a comm program, or using a modem across the network as a
resource requires two things.

1) The network must be NETBIOS compliant.

2) The comm program must use the BIOS (Int-14) for comm routines. Telix
normally bypasses the slower BIOS and writes directly to the comm port for
speed considerations, making it incompatible with networks.

However, we have developed a version of Telix which uses the Int-14 calls,
and it is now available as a separate product. please call our sales staff
for more information about Telix for Networks.
=====

it would appear that they incorporated this functionality in a later
version that came after 3.22... now i've gotta hunt that one down and try
to get the serial registration number into it...

MS>> I must confess that the matter of local connection speed (~DTE~,
MS>> isn't it?) sure sounds somewhat "elusive" since i get rate peaks
MS>> around 4K cps (both on `{Commo}' and `Telix') but there's no
MS>> significant drop when i set `Telix' for a 9K6 bps connection...  if
MS>> i use `MS-kermit' with `RLFossil' instead then my connect speed
MS>> shows as "unknown"...  In any case, the Serial-Port `{Commo}' or
MS>> `Telix' would use is defined right on `RLFossil's Command-Line!...
ML>> ...the equipment is not hampered by hardware (aka uart) speed...
ML>> ...ms-kermit either doesn't have a matching connect speed or doesn't
ML>> recognise what it may be being told is the connection speed...

 MS>      I have found that the behavior of ~BIOS INT-14~/~FOSSIL~
 MS> compatible terminal emulators varied significantly when i
 MS> investigated them but the "unknown" result returned by
 MS> `MS-Kermit' was said to make perfect sense, according to its
 MS> maintainers at the Columbia university.  From memory, i
 MS> believe their reasoning was it's the ~FOSSIL~ driver's
 MS> responsability to manage it, usually (it sounds about true of
 MS> `X00', `ADF' and the suite).

yes and it is all too easy to tell the FOSSIL using software what speed the
FOSSIL is running at so that transfer calculations may be performed... my
RemoteAccess BBS knows the FOSSIL driver is locked at a set speed (115200)
but it still uses a/the connection speed for calculations... when a dialup
connection is made, it takes the info from the CONNECT line... in telnet
mode, my shim says all connections are at 56k... it just seems to me that
kermit would also be able to do this... but then again, from what i've read
from you and others, i can easily see why it doesn't from the butt-type
attitudes of kermit's developer(s)...

ML>> My bbs does that with telix all the time...  When a user logs off,
ML>> my system fires up telix...  ...and runs a script to fetch the
ML>> session's stats from the modem...

 MS>      BBSes depend on a fully compliant level 5 ~FOSSIL~ driver
 MS> which can support application swapping even when the
 MS> Serial-Ports are still "Hot", i wish `RLFossil' were compliant
 MS> enough to support the use of a `ZMoDem' protocol driver run
 MS> from `MS-Kermit's terminal interface, or vice-versa!

unless i've something crossed up, DSZ (and FDSZ, i believe) can be used to
dial out and have a rudimentary terminal... FDSZ, BTW, is FOSSIL DSZ ;)

 MS>      Right now, i can "share" connections (alternately) using
 MS> `LSPPPDlr' with `MS-Kermit' run as a protocol-driver - when
 MS> used via `COM/IP' - but not with `RLFossil' (the later reboots
 MS> my PC instead)!...

if you have and are using COM/IP, that indicates WIN9x (at least) is
installed so why even mess with the legacy ways? even moreso since WIN9x
alters a lot of rules for its own purposes... i'm assuming that your
statement above is saying that you have the reboot problem with RLFOSSIL
when using it in WIN9x?

 MS> I wonder what feedback i'd get from a person like Sylvain Lauzon
 MS> (he was knowledgeable enough about `RLFossil' to get me a 8088
 MS> built which didn't exist on the Net), euh...  i have to wonder if
 MS> he wouldn't happen to know where to go for the source-code or,
 MS> maybe, even a quick fix.

i dunno but i do know that there are some out there who can reverse
engineer things back to source code... maybe not the original, as the
author wrote it, source code but source enough that it can be fixed and
recompiled...

 MS> `TelNet Port' suffered from the same problem when i checked, i
 MS> may be stuck with this for ever!

what problem? the reboot problem when trying to share it between LSPPPDlr
and MS-Kermit? also, when yo usay "share" you don't mean at the
same time from different windows/tasks, do you?

ML>> ...if one is handy with debug or other capable software, one can
ML>> redefine the BIOS table of serial and parallel port addresses...

 MS> Back in days when i played with `Z-80' code, a concept like
 MS> double-Byte numbers with their most significant Byte last made
 MS> sense but that's all history now, i depend on the talent of
 MS> others for my modest hobby...

i hear that... but the table did make some sense in how the BIOS stuff
plays its part in the definition and location of the standard serial ports
and helps to explain where comm programs get the info for the basic ports
when they don't have any real port setup capability, right?

MS>> ...drop me a note when you're ready to try `MS-Kermit' as an `OS/2'
MS>> external file-transfer protocol-driver on a `Maximus' BBS!
ML>> ...on a RemoteAccess BBS since i don't run Maximus "out
front"...

 MS>      Good!  8-)  Anyway, i must meditate on the meaning of the
 MS> riddle...

"out front" meaning that i have max here but on another
machine... sadly, though, its not compiling properly for me and i'm kinda
like you in that i have to rely on others to fix the problem... what i have
here is the linux port on one of my linux boxes and i'm not a C coder at
all ;)

)\/(ark