Subj : 1/2 - LSPPPDlr 2003 To : Michel Samson From : mark lewis Date : Mon Dec 13 2004 09:55 pm MS> About "LSPPPDlr 2003" of December 13: MS>> ...an image is worth a thousand words... ML>> What versions of {COMMO}, Telix and RLFossil are those, please? ML>> My thoughts have been to gather everything together for others... MS> Everything? Would that be the information relative to MS> the programs or the archives themselves?... 8^) mainly just the archives... MS> It turns out that i was thinking my `LSPPPDlr 2003' UpDate is MS> over-due for a switch to the 2004 edition so i began working MS> on new dedicated pages as you were posting this morning... cool... MS> I've gathered the addresses on which i intend to base my MS> pages; in its present state, its the old 2003 page plus a few MS> more links somewhere in a crude listing AT THE END. It might MS> help, you can visit this ~URL~: MS> http://public.sogetel.net/bicephale/eng/2k4updat.htm i'll try to remember that... MS> The external dialer now handles two types of MS> Packet-Drivers: ~PPP~ DialUp (`EPPPD.EXE'/`LSPPP.EXE') and MS> ~NIC~ (`RTSPkt.COM' in my case). I also wrote a Batch-File MS> to simplify the installation so i decided to put it to good MS> use, the next step probably would be to .ZIP it all together. excellent! ML>> I have {COMMO} v7.7 but i note that it has a 30 day trial period and ML>> that there is a COMMO.ID file for registered users... How bad does ML>> it get if it is not registered? Have mr. Brucker's people released ML>> a free key and/or are they continuing on with {COMMO}'s development? MS> There's no such lock in v7.7! all i had/have to go by is the info within the commo77 archive... that and some basic guesswork ;) MS> As i must have wrote, in `DOS-INet', my understanding was that MS> the author got a thought for the blind when he removed the "Nag MS> Screen" in his release of December 1998 - right in time for MS> ChristMass... The people he left behind after he died didn't MS> appear to "care" about his work when i learned about his death MS> via the official {COMMO} mail-list (on YahooGroups), we were MS> lucky to be informed at all. i, for one, thank you for that notification... MS>> As for `Telix', i'm refering to version 3.51... ML>> I have a floppy here of Telix 3.22 from deltacomm... a quick search ML>> for "14" thru the v3.22 docs i have turns this up... #1>> Problem: We have our modems on a network and we need a network #1>> version of Telix in order to access them. Does Telix have network #1>> support built in? #2>> Solution: ...we have developed a version of Telix which uses the #2>> Int-14 calls, and it is now available as a separate product. ML>> It would appear that they incorporated this functionality in a later ML>> version... Now i've gotta hunt that one down... MS> I wonder what might have been possible if only the `Windows' MS> frenzy had occured a few years later. What if innovation could MS> have followed a more inclusive path?! Sniff! 8,-( An affordable MS> solution, these days, could be Dial BackUp routers if one is no MS> AOL customer or he never sends FAX documents (AOL's SoftWare must MS> access the MoDem, similarily to a FAX application); but imagine MS> if MoDem Servers had been developped when DOS was still strong and MS> kicking! Hummm... Sorry, i dream out loud... ;-) n.p. on the dreaming... however, i'm not sure what you mean about the AOL stuff must access the modem like a fax app... i've set up many AOL systems to use the internet to get to AOL after a dialup connection is made... no changes are needed to that setup when one upgrades to some DSL or cable connection, either... i'll also note that i'm aware of at least one person who figured out how to use his AOL connection to access the internet without using the AOL software at all... it was a matter of determining the proper logon sequence and now he uses that connection "clean"... MS> Well, to me it was like most ~BIOS INT-14~ drivers crawl MS> at 9K6 bps when i tried one. Your reference to a MoDem pool that came about when users didn't want to have to put a modem in each machine... corporate users were one of the first to desire this... MS> reminds me of emerging alternatives which the average BBSers MS> hardly ever heard of, euh... like ~NCSI~ (NetWork MS> Communications Services Interface) which was copyrighted MS> by the NPC company but it was used with Novell's `LAN WorkPlace MS> for DOS' SoftWare: its interrupt was 0x6B, standard signals MS> (~Xon~/~Xoff~, ~DTR~ and ~RTS~) were supported and the speed MS> limit reached 115K2 bps instead. yes, i believe that that is where i first encountered a workable solution to the multiple modems problem... MS> But maybe HardWare performance has more inlfuence than i MS> suspected! it may very well... on my internal 10mb LAN, i'm getting 9kcps with the windows version of qmodem pro to my bbs sitting on another machine on my LAN... that other machine is running OS/2 with vmodem, RemoteAccess and the OLMS offline mail door that i'm testing for compatibility... the protocol driver in use is CEXYZ in that OLMS installation but i also have FDSZ available as well as other protocol drivers that i may be able to use to provide X, Y, and Zmodem protocols... i went with CEXYZ so as to be able to provide zedzap (8k-zmodem) capability... not that it is important or that anyone will actually use it ;) MS>> I must confess that the matter of local connection speed (~DTE~, MS>> isn't it?) sure sounds somewhat "elusive"... ...the "unknown" MS>> result returned by `MS-Kermit' was said to make perfect sense... ML>> ...it is all too easy to tell the FOSSIL using software what speed ML>> the FOSSIL is running at so that transfer calculations may be ML>> performed... my RemoteAccess BBS knows the FOSSIL driver is locked ML>> at a set speed (115200) but it still uses a/the connection speed... MS> Hummm... Wouldn't it be possible that `Kermit' doesn't MS> depend on a number defined by the ~FOSSIL~ driver to compute MS> the cps transfer speed? it is possible but i was thinking of the "pre" calculation that tells one how long the transfer will take... on a BBS where time may be limited, that can come in handy so that one doesn't run out of time when trying to download maill packets... ML>> ...from what i've read from you and others, i can easily see why it ML>> doesn't from the butt-type attitudes of kermit's developer(s)... MS> Well, "The Team", as i called them, sure reacted poorly MS> when i went to their NewsGroup with a macro-file which i MS> actually used for this very same reading/posting activity, to MS> be honest... I'd need to dig up if it were crutial for me to MS> know what their position was exactly but only Joe Doupnik would MS> be worth it, anyway (he was slightly less agressive). %-) i hear ya there... MS> I confirm `MS-Kermit' replies "unknown" but i'm unable to MS> tell why. me either from here... ML>> When a user logs off, my system fires up telix... ...and runs a ML>> script to fetch the session's stats from the modem... MS>> BBSes depend on a fully compliant level 5 ~FOSSIL~ driver which can MS>> support application swapping... ...i wish `RLFossil' were compliant MS>> enough to support the use of a `ZMoDem' protocol driver run from MS>> `MS-Kermit's terminal interface, or vice-versa! ML>> ...DSZ (and FDSZ, i believe) can be used to dial out... MS> Remember that `RLFossil' is no ~UART~ emulator and hence MS> this means only the ~FOSSIL~ flavour of `DSZ' can resume the MS> ~TelNet~ session after `MS-Kermit' has left it in a "Hot" state, MS> as i like to refer to it. :-) that is probably pretty accurate, too... )\/(ark * Origin: (1:3634/12) .