Subj : 2/2 - LSPPPDlr 2003
To : Michel Samson
From : mark lewis
Date : Mon Dec 13 2004 10:12 pm
[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? ;^)
