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