Subj : 2/2 - LSPPPDlr 2003
To   : Mark Lewis
From : Michel Samson
Date : Mon Dec 13 2004 07:46 pm

[The previous message concludes here.]                               2/2

    Teaching isn't a talent i got.  The fact that `{COMMO}', as used in
my `LSPPPDlr' external dialer, calls ~ISP~s and ~TelNets~ to some remote
system may be confusing...  Keep in mind that `LSPPPDlr' proceeds in two
steps:  it 1st loads the ~PPP~ Packet-Driver after it took control of my
real MoDem, to dial the ~ISP~'s phone number - once connected, `{COMMO}'
creates a set of Batch-Files, unloads and then it returns control to one
other Batch-File (the one which loaded `{COMMO}' and my `LSPPPDlr' macro
in the 1st place).  Since a Packet-Driver must have exclusive control of
the HardWare Serial-Port which is attached to the real MoDem it explains
why i have to go thru this dial/load/configure/unload sequence before it
is possible for the Packet-Driver to take over, via ~RS-232~ protocol on
one side while `Waterloo TCP'-compatible applications don't have to know
anything about ~RS-232~ and ~PPP~ protocols.  In a local DialUp session,
`DSZ' would work fine but this is no longer true if the remote system is
an ~ISP~ and it talks ~PPP~ instead of ~ANSI~...  This is why `RLFossil'
comes to the rescue during the second step, the difference being that it
is `RLFossil' which loads `{COMMO}' and the later connects via ~FOSSIL~,
not ~RS-232~/~ANSI~ as in a local DialUp call.  Now, consider that there
is a similitude here compared to ~FOSSIL~-based BBSes:  the BBS SoftWare
owns the Serial-Port during interactive sessions and when it's due for a
transfer it hands down the control over the ~FOSSIL~ Serial-Port to some
external File-Transfer Protocol-Driver (being `FDSZ' in this case).  ;-)

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?

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

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...

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

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

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

    The problem with `RLFossil', `TelNet Port' and perhaps a few others
is that something very wrong usually happens when a terminal emulator is
trying to pass control of the ~FOSSIL~ Serial-Port (or is it more like a
~BIOS INT-14~ one?), euh...  Novell's `TelAPI' (`LAN WorkPlace for DOS')
is the only adapter with which i've ever been able to start the external
Protocol-Driver from `{COMMO}' or `MS-Kermit';  as i recall, a 3rd-party
~TelNet~ "Shim" for `PC-NFS' also allowed it but it was so unreliable it
didn't get much of my interrest.  In any case, the fact that a very same
macro-file succeeds when my terminal emulator launches a Protocol-Driver
with `COM/IP's `INT-14'/~FOSSIL~ support and that it fails if `RLFossil'
is used indicates that one is more Level-5 compliant than the other.  Of
course, a professional might have a better explanation but that's only a
hobby and those guys rarely hang around just to help with some problems.

                                 %-(

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...

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

    If some terminal uses an option-setting saying ~BIOS INT-14~ and it
works with `RLFossil' - note it's not called `RLINT-14' - well, it's all
i need to know and i do my best with that...  %-)  Others can take over,
nothing else would please me more!  I try to use my findings to ignite a
form of interrest:  tiny miracles may happen if i'm patient, right?  ;^)

                                   Salutations,

                                   Michel Samson
                                   a/s Bicephale
                                   http://public.sogetel.net/bicephale/


... Sometimes, the cost of new features is too high, really!  Is it not?
___ MultiMail/MS-DOS v0.45 - Trying to make TelNet OLMR BBSing UNIVERSAL
--- Maximus/2 3.01
* Origin: COMM Port OS/2 juge.com 204.89.247.1 (281) 980-9671 (1:106/2000)