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

Right now, i can "share" connections (alternately) using `LSPPPDlr'
with `MS-Kermit' run as a Protocol-Driver - when used via `COM/IP' -
but not with `RLFossil' (the later reboots my PC instead)!...

If you have and are using COM/IP, that indicates WIN9x (at least) is installed... i'm assuming that your statement above is saying that
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

I wonder what feedback i'd get from a person like Sylvain Lauzon...
i have to wonder if he wouldn't happen to know where to go for the source-code or, maybe, even a quick fix.

...there are some out there who can reverse engineer things back to
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! ;-)

`TelNet Port' suffered from the same problem when i checked...

What problem? ...when you say "share" you don't mean at the same
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.

%-(

...one can redefine the BIOS table...

...i depend on the talent of others for my modest hobby...

But the table did make some sense... ...and helps to explain where
comm programs get the info for the basic ports when they don't have
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)

[trim]

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

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

Right now, i can "share" connections (alternately) using `LSPPPDlr'
with `MS-Kermit' run as a Protocol-Driver - when used via `COM/IP' -
but not with `RLFossil' (the later reboots my PC instead)!...

If you have and are using COM/IP, that indicates WIN9x (at least) is
installed... i'm assuming that your statement above is saying that
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

"DOS box" to me means opening a DOS command prompt window... is this the same meaning you are using it as?

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

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

I wonder what feedback i'd get from a person like Sylvain Lauzon...
i have to wonder if he wouldn't happen to know where to go for the
source-code or, maybe, even a quick fix.

...there are some out there who can reverse engineer things back to
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! ;-)

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

`TelNet Port' suffered from the same problem when i checked...

What problem? ...when you say "share" you don't mean at the
same 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...

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

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.

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

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.
%-(

and then there are those like me who are here and are willing to contemplate it
based on prior knowledge and experiance ;)

...one can redefine the BIOS table...

...i depend on the talent of others for my modest hobby...

But the table did make some sense... ...and helps to explain where
comm programs get the info for the basic ports when they don't have
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... %-)

that's about all one can hope for! ;)

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? ;^)

right!

)\/(ark
* Origin: (1:3634/12)

[The previous message concludes here.] 2/2

...running OS/2 with vmodem... ...i also have FDSZ available...

^^^^
Isn't it a shame one of the fastest drivers is also a prototype? I
tried `FDSZ' a long time ago so i'm relieved that this one can wait. :)

...not that it is important or that anyone will actually use it...

Well, i do care about file transfer matters but i've got priorities
so a part of my hobby has been put on the back-burner for some time now.

...the matter of local connection speed... ...sure sounds somewhat "elusive"... ..."unknown" result returned by `MS-Kermit'...

...easy to tell the FOSSIL using software what speed the FOSSIL is
running at so that transfer calculations may be performed...

Wouldn't it be possible that `Kermit' doesn't depend on a number
defined by the ~FOSSIL~ driver to compute the cps transfer speed?

...i was thinking of the "pre" calculation that tells one how long
the transfer will take... On a BBS where time may be limited...

I see your point, it's important to know how much time the transfer
may last before it begins but doesn't the BBS handle it? Luckily, there probably are sufficient arithmetic tools in `MS-Kermit's macro-language, especially if the right internal variable already happens to be defined.

...i wish `RLFossil' were compliant enough... ...i can "share"
connections (alternately) using `LSPPPDlr' with `MS-Kermit' run as a Protocol-Driver... ...via `COM/IP'... ...not with `RLFossil'...

I prefer to let the FOSSIL developers worry about the serial comms
stuff... ...not that i haven't done my share of comms coding...
"DOS box" to me means opening a DOS command prompt window... Is
this the same meaning you are using it as?

Yes, i'm afraid a crutial string ("W32") slipped away as i wrote...

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

That is exactly why... I have that info from direct and personal contact... ME and i go way way back as we were both beta testers...

It seems i don't have to regret that i hesistated too long before i finally decided to register, euh... It's quite a good thing i waited!!!

...`RLFossil v1.23' is improved... ...this is a good reason to
bring `LSPPPDlr' to its full completion... ...i'd like to get back
to the origins of this project... ...because of no other reason
than to prove the BBS 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...

Am i detecting some dark poetry in the way you see things?... 8,-D

`TelNet Port' suffered from the same problem when i checked...

...you say "share"... ...at the same time... ...do you?

...when a terminal emulator is trying to pass control of the
~FOSSIL~ Serial-Port... ...a very same macro-file succeeds when my terminal emulator launches a Protocol-Driver with `COM/IP's `INT-14'/~FOSSIL~ support and... ...it fails if `RLFossil' is
used... ...one is more Level-5 compliant than the other.

...why a coder has to go about readjusting the port settings... The
BBS has already been communicating successfully with those on the
other end... ...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...

I wish i could grasp the full meaning of this. I checked `Kermit's documentation and there's a ~FOSSIL~-related "Disable-On-Close" feature: ________________________________________________________________________
The presumption is an external agent has selected the speed [...] and
flow control. [...] Kermit is a polite user of one port via Interrupt
14h. A Fossil driver can also be used [...] lifting the normal upper
limit of 4 [...] also enabling block reads and writes [...] certain
fossil driver will stop working after its first connection has been
closed. The workaround is to fully reinitialize the driver [...] some
expect the external application to "deinitialize" [...] others expect it
not to do so. MS-DOS Kermit will behave either way, according to: SET
FOSSIL DISABLE-ON-CLOSE { ON, OFF } When OFF (the default), Kermit does
NOT deinitialize the fossil driver upon exit. When ON, Kermit issues
fossil function 05h to deinitialize the fossil driver. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I verified that "Disable-On-Close" is set to "Off"... Do you think
"On" is worth a try or is it a problem caused by `RLFossil' exclusively?

...tiny miracles may happen if i'm patient, right?

That's about all one can hope for!

If i hadn't have any hope i just would have quit pursueing the same
goal long ago! :) My quest for an external dialer will be a decade-old project in 2005 so i'm in no hurry but i'm certainly a bit persistent...

I don't care much about this goal not being popular but would it be challenging if we all worked on it?... ;-) I just wish the timing were
more favourable; i'm preoccupied with domestic matters all the time, my
hobby space is so limited i keep moving the mouse as i hand-write! %-b,

Salutations, :)

Michel Samson
a/s Bicephale
http://public.sogetel.net/bicephale/


... `MS-DOS v7.10a', Pkt-Driver, `RLFossil 8088' and `MS-Kermit v3.16'
-!- 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)

...`RLFossil v1.23' is improved... ...this is a good reason to
bring `LSPPPDlr' to its full completion... ...i'd like to get back
to the origins of this project... ...because of no other reason
than to prove the BBS 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...

Am i detecting some dark poetry in the way you see
things?... 8,-D

possibly ;) even i find myself on the "dark side" more often than not,
these days :(

)\/(ark
* Origin: (1:3634/12)