TIP: Click on subject to list as thread! ANSI
echo: muffin
to: Maurice Kinal
from: Bo Simonsen
date: 2003-11-13 23:14:50
subject: Backspace

Hello Maurice!

13 Nov 03 09:38, you wrote to me:

 BS>> BUT no one that me has look at it, and I do not have the fully
 BS>> understand for telnet.. But noone seems to take their time just
 BS>> looking at it! It really makes me crazy.

 MK> Sure.  I'll look as long as you're not in too big a rush.  I am still
 MK> trying to work out a viable way of encorportating some of this into
 MK> where I'd like to see it go, or at least play with it to see if I even
 MK> can go there, wherever there is.

I'm more happy today, I did get filetransfer working yesterday! There is
still a few problems with QWK, I'll properly fix them tonight..

 MK> Like I said, I don't have a
 MK> phoneline or any serial communications going other then a mouse that
 MK> I hardly use.  :-/

It's _not_ required, I do neither have.. I do have the equitment to test it
with, but only for test (I did write some code which _might_ get the pots
working).

Maximus is _natively_ telnet supported (In the unix port).

Scott was so cluefull, so he did make communications module.

 BS>> Yes but I want filetransfer in maximus to work, cost what it has
 BS>> to cost. I don't care if it's kermit, xmodem, etc.

 MK> I did get kermit to work but as a standalone as I still don't have a
 MK> Linux based Maximus going yet.  Once I can get the menuing working
 MK> right then I think the rest, including file transfers, should be quite
 MK> doable, maybe even zmodem.

Zmodem works... At the moment I can't see how to make maximus running
external programs..

system("command") is easy enought, but! It do only get
input/write output at STDIO, and I need to write it to a socket (A normal
filedescribtor, like open()).

 MK> I am still not sure how that could be
 MK> tested to a remote though but if I can get something suitable working
 MK> as far as menuing going then perhaps it will be easier to convince at
 MK> least one "local" to try it.  How much zmodeming do you
do and is it
 MK> comparable to other methods?

Zmodem works :-) The problem was in the communication module.. It did came
because Wesley didn't do _anything_ if the mode was set to binary transfer,
but if it was ASCII he did do carrige return and iac parsing..

I did just put in a 'goto' so I did parse IAC on binary connections too.

(It's not applied to the CVS yet.. It might not be working properly yet).

I did only speed up the telnet module, but then the "Please
respond" thing doesn't work.. Gotta look at it.

 MK>>> As for Maximus I'd love to put a text based BBS up but have no
 MK>>> need for serial communications or waiting for caller screens.

 BS>> Maximus/UNIX doesn't require that.

 MK> Then why are we worried about it?  Can I safely remove or ignore the
 MK> source dealing with it?

I'm a bit worried about how to do it with the WFC screen.. More too come.

 BS>> I wrote a
 BS>> Modem-communication module yesterday, which I might test tomorrow
 BS>> (I were setting BTXE up earlier today, so it might work with
 BS>> Max).

 MK> Now this sounds like a plan!  I don't use BTXE myself but if it can be
 MK> made to work with that then it seems like it could be modified or
 MK> outright written for a Maximus port.

I'm just doubting about it a bit.. As I wrote it I do just open /dev/ttySX
with open(), and read/write is done by writing to the device.

Maybe I should use select() too.

 BS>> What are you waiting for? Join the maximus developing. I know you
 BS>> are a C programmer, 4 eyes is better than 2..

 MK> I am *not* an anything programmer, but have written C code.  Both for
 MK> Unix and DOS but very little of it had anything to do with BBSing.  I
 MK> did once write an online database utility for a DOS based Maximus but
 MK> that was a long, long time ago.  I am game though and have said so.  I
 MK> don't think I can be of much help with any portablilty of code to
 MK> anything other then Linux though, gcc in particular as that is all I
 MK> use in the way of a compiler.

Okay. :-)

 BS>> If no-one is developing on the project, because I don't want it
 BS>> to be a one person project, so if SOMEBODY not commits anything I
 BS>> would not be developing on it 2 months more..

 MK> I hear you.  It won't be the first or the last time that sort of thing
 MK> happens.  The world will not come to an end but I agree that it would
 MK> be nice to see a future for BBSing.  I already said I will help in
 MK> whatever way I can but am content to leave portablility of code to
 MK> those who are better suited to that sort of thing.  I currently only
 MK> have Linux running and it looks like it is here to stay for the
 MK> forseeable future.

Don't think of the portablity, I can be done later, if someone want to
reverse port it. If you like memory handling, look at MEX, neither Wes or
Me can solve it.

 BS>> IF we could get the dirt working, afterwoods we could make it
 BS>> better..

 MK> Sounds good to me.  Where do you suggest I start?  I am thinking that
 MK> I need to get menuing working properly and then take it from there.

I gotta look in some rutines there is saving the user information, after I
did change the communication module I does'nt seem right.

 MK> Squish seems to be behaving itself.  :-)

Maximus needs a friendly hand at the moment

Happy hacking :-)

Regards,
Bo

--- GoldED+/LNX 1.1.4.7
* Origin: The Night Express - Roennede, Dk (2:236/100)
SEEN-BY: 633/267 270
@PATH: 236/100 237/9 20/11 106/1 2000 633/267

SOURCE: echomail via fidonet.ozzmosis.com

Email questions or comments to sysop@ipingthereforeiam.com
All parts of this website painstakingly hand-crafted in the U.S.A.!
IPTIA BBS/MUD/Terminal/Game Server List, © 2025 IPTIA Consulting™.