| TIP: Click on subject to list as thread! | ANSI |
| echo: | |
|---|---|
| to: | |
| from: | |
| date: | |
| 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™.