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