[trim]

 MS> not ~RS-232~/~ANSI~ as in a local DialUp call.  Now, consider
 MS> that there is a similitude here compared to ~FOSSIL~-based
 MS> BBSes:  the BBS SoftWare owns the Serial-Port during interactive
 MS> sessions and when it's due for a transfer it hands down the
 MS> control over the ~FOSSIL~ Serial-Port to some external
 MS> File-Transfer Protocol-Driver (being `FDSZ' in this case).
 MS> ;-)

true in some cases and only for some bbs software... on my system, the
FOSSIL is required before /any/thing can happen... this is because most all
of my software doesn't do direct serial comms... as a developer, i can see
and fully understand why this is, too... as a developer, i can whip out
numerous comms apps without having to know anything about serial comms if i
simply talk to the FOSSIL driver and let it handle all that stuff... i
perfer to let the FOSSIL developers worry about the serial comms stuff
whilst i concentrate on my application and its functionality rather than
having to clutter my head and other stuff up with comms knowledge... not
that i don't have a good understanding and not that i haven't done my share
of comms coding without a FOSSIL...

MS>> Right now, i can "share" connections (alternately)
using `LSPPPDlr'
MS>> with `MS-Kermit' run as a Protocol-Driver - when used via `COM/IP' -
MS>> but not with `RLFossil' (the later reboots my PC instead)!...
ML>> If you have and are using COM/IP, that indicates WIN9x (at least) is
ML>> installed...  i'm assuming that your statement above is saying that
ML>> you have the reboot problem with RLFOSSIL when using it in WIN9x?

 MS>      `Win-32' isn't involved here, i once evaluated `LSPPPDlr'
 MS> in a DOS box

"DOS box" to me means opening a DOS command prompt window... is
this the same meaning you are using it as?

 MS> and i also conducted tests with `COM/IP' but i don't use `W98'
 MS> very often these days and i sort of abandoned the idea that
 MS> `COM/IP' will be the perfect alternative someday
 MS> (TacticalSoftware became so greedy with their costs i bet that's
 MS> why i've read that Mike Ehlert and his company "discontinued
 MS> selling COM/IP licensing" after October 14, 2004)...  8-o

that is exactly why ME left them... i have that info from direct and
personal contact... ME and i go way way back as we were both beta testers
for several fidonet packages... the RemoteAccess BBS package being the main
one between us...

MS>> I wonder what feedback i'd get from a person like Sylvain Lauzon...
MS>> i have to wonder if he wouldn't happen to know where to go for the
MS>> source-code or, maybe, even a quick fix.
ML>> ...there are some out there who can reverse engineer things back to
ML>> source code...  ...enough that it can be fixed and recompiled...

 MS>      I have no idea what string he may have pulled in order to
 MS> obtain it but `RLFossil v1.23' is improved compared to its
 MS> predecessor and this is a good reason to bring `LSPPPDlr' to its
 MS> full conpletion, in my opinion.

 MS>      In the end, i'd like to get back to the origins of this
 MS> project and have it stand on a single 3.5" - 720 Kb Stand-Alone
 MS> diskette, because of no other reason than to prove the BBS
 MS> community could have done it!  ;-)

excellent reason... i fear, sadly, that it may fall on deaf ears, though...
too many supposed sysops are really little more than advanced lemmings and
like all lemmings, they, too, follow the rest of the pack over the cliff
into the sea...

MS>> `TelNet Port' suffered from the same problem when i checked...
ML>> What problem?  ...when you say "share" you don't mean at the
ML>> same time from different windows/tasks, do you?

 MS>      The problem with `RLFossil', `TelNet Port' and perhaps a
 MS> few others is that something very wrong usually happens when a
 MS> terminal emulator is trying to pass control of the ~FOSSIL~
 MS> Serial-Port (or is it more like a ~BIOS INT-14~ one?), euh...

it may very well be the INT-14 hand off... something that's always bothered
me once i learned about the FOSSIL stuff is why a coder has to go about
readjusting the port settings and such once they are handed the port from
the BBS... seems to me they should be able to just use the port as is...
especially when using a FOSSIL... if they really need to adjust settings in
their code, then they should be able to _query_ the port to see what it is
set for and then go from there... especially in a BBS situation where the
BBS has already been communicating successfully with those on the other end
of the line...

 MS> Novell's `TelAPI' (`LAN WorkPlace for DOS') is the only adapter
 MS> with which i've ever been able to start the external
 MS> Protocol-Driver from `{COMMO}' or `MS-Kermit';  as i recall, a
 MS> 3rd-party ~TelNet~ "Shim" for `PC-NFS' also allowed it but it
 MS> was so unreliable it didn't get much of my interrest.  In any
 MS> case, the fact that a very same macro-file succeeds when my
 MS> terminal emulator launches a Protocol-Driver with `COM/IP's
 MS> `INT-14'/~FOSSIL~ support and that it fails if `RLFossil' is
 MS> used indicates that one is more Level-5 compliant than the
 MS> other.

or that something still has hold of the interrupt vector or is otherwise
"still standing in the doorway"... RLFOSSIL must be there since
it /is/ the FOSSIL and not a normal TSR FOSSIL driver like X00 or BNU...

 MS> Of course, a professional might have a better explanation but
 MS> that's only a hobby and those guys rarely hang around just to
 MS> help with some problems.
 MS>                                   %-(

and then there are those like me who are here and are willing to
contemplate it based on prior knowledge and experiance ;)

ML>> ...one can redefine the BIOS table...
MS>> ...i depend on the talent of others for my modest hobby...
ML>> But the table did make some sense...  ...and helps to explain where
ML>> comm programs get the info for the basic ports when they don't have
ML>> any real port setup capability...

 MS>      I patched a small utility embeded in the `LSPPPDlr' macro
 MS> to manage with ~UART~ types so, it was necessary to find the
 MS> bytes which addressed the Serial-Port attached to the MoDem (i
 MS> wanted to set the ~FIFO~-buffer trigger level).  I see some me
 MS> relevance if HardWare Serial-Ports are on topic but my idea of
 MS> how a ~BIOS INT-14~ port differs is pretty vague...

 MS>      If some terminal uses an option-setting saying ~BIOS INT-14~
 MS> and it works with `RLFossil' - note it's not called `RLINT-14' -
 MS> well, it's all i need to know and i do my best with that...  %-)

that's about all one can hope for! ;)

 MS> Others can take over, nothing else would please me more!  I try
 MS> to use my findings to ignite a form of interrest:  tiny miracles
 MS> may happen if i'm patient, right?  ;^)

right!

)\/(ark