Text 407, 136 rader
Skriven 2004-12-13 22:12:18 av mark lewis (1:3634/12)
    Kommentar till text 405 av Michel Samson (1:106/2000.0)
Ärende: 2/2 - LSPPPDlr 2003
===========================
[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

 * Origin: (1:3634/12)