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? ;^) right! )\/(ark * Origin: (1:3634/12) .