See below ...
Joe.
> -----Original Message-----
> From: Bernie [SMTP:[EMAIL PROTECTED]]
> Sent: Friday, 25 August 2000 16:08
> To: [EMAIL PROTECTED]
> Subject: RE: EPPPD 0.7 (rather urgent, so please read)
>
> Joe wrote:
> > The only FIFO trigger levels that exist are those given above. The
> > hex values shown above are ORed with $01 first, to produce $01,
> > $41, $81 or $C1 - assuming a FIFO exists and is to be enabled.
> > Of course, this ORing must already exist in the 'epppd' code, so
> > you shouldn't need further changes to do that ...
>
> Yes I knew that it was ORed together - but that didn't make it obvious to
> me if these were the only ones that are allowed. Thanks for verifying.
>
[da Silva, Joe]
These were *two* separate (but related) pieces of information.
Neither could have been inferred from the other ... :-)
> > As for "we still need a way to configure it in Arachne ...", that's
> > the reason both files 'pppd.cfg' *and* 'pppdrc.cfg' should be
> > supported ... (IMHO).
> >
> > What do you mean, "without the trigger choice of course" ?! ;-)
>
> Because you can't try it there's no point in adding it (I will add it but
> you can't use it since pppdrc.cfg isn't changed - that's up to core.exe).
>
[da Silva, Joe]
That's the purpose of the 'pppd.cfg' file ... (well, at least until
you eliminate support for it ... )-:
> > I know you are trying to squeeze every last byte out of this
> > thing, but is it wise to make this so "rigid" that you even make
> > 'pppdrc.cfg' order-specific ???
>
> Why not? Core.Exe writes it anyway without you being able to change it.
> Keep in mind that I'm talking about the Arachne specific version here. If
> I
> hadn't mentioned this you wouldn't have noticed it anyway since you can
> NOT
> change things in pppdrc.cfg. As it currently is it's extremly specific
> without any changes.
>
[da Silva, Joe]
True, but :
1. This will make 'epppd' fragile (IMHO).
2. This also eliminates the possibility to retain support
for the 'pppd.cfg' file ...
> > I mentioned before the possibility to support DPMS, thereby
> > making most of the packet driver live in XMS - would this be
> > a better approach than making 'epppd' too restrictive? To quote
> > from 'http://developer.novell.com/support/bullets/jun93.htm',
> > "Developers may distribute the server component royalty-free
> > with their DPMS client programs" - which seems to say that
> > the DPMS.EXE driver can be freely distributed (for those
> > that don't already have it) ...
>
> IMHO CWSDPMI should be used instead (especially since it's already in
> Arachne).
> But I don't know how to program a TSR (yes really), but I guess I would
> have to rewrite several parts if I want it to use DPMS. And since this
> would require a 386 (or a 286 in some cases but then I would also need
> another compiler) this isn't a good way to go. If so I would suggest using
> cloaking.exe to get it down in size.
>
[da Silva, Joe]
You may be right, I'm no expert on protected mode stuff.
However, the DPMS documentation says that this stuff
is much more suitable for TSR's than DPMI (and simpler).
I don't know if you need a different compiler, but any 286
with XMS can use DPMS. In fact, this "cloaking.exe"
stuff *sounds* very similar, anyway. However, it's up to
you - whatever you think is easiest or best suited, I just
mentioned this stuff in case it is useful for you. :-)
> > AFAIK, this stuff is "open source", so you should be able to make
> > changes, as long as you identify the changes and make the new
> > source readily available (?).
>
> It never says that in the package that it came with.
>
[da Silva, Joe]
Hmmm. In the Licensing section of 'dospppd.txt', it says
(amongst other things), that "DOS PPPD can be freely
distributed for NON COMMERCIAL use, provided you
include this copyright notice in all the copies or derivative
works". This means that you *are* allowed to create and
distribute *derivative* works, doesn't it? :-)
