• Please review our updated Terms and Rules here

Another DOS IRC Client

Status
Not open for further replies.
mbbrutman said:
Trixter - what were those funny packets?

In other news ... I've added support for a backscroll buffer. It looks like I did a pretty good job with the TCP stack because you can continue receiving data from the other side even while looking at the backscroll buffer. The incoming data just gets buffered, and if buffer space runs out the TCP stack reports a 'zero window' condition correctly to the server side. And it also responds correctly to 'zero window probes.

(Translation for normal people - you can sit all day looking at the backscroll buffer and even though data might stop flowing after the buffer space runs out, the connection won't error out.)

I'll have another version out for download in a few days. After that, what else are people interested in?


Mike
Click to expand...

very slick! i'll download it when you post it. there's not much more you really need in a basic client. what i have leetIRC do when you scroll up in the buffer is still keep processing incoming packets and append new lines to the buffer even if you're scrolled up. if you have pc speaker beeps enabled in the options menu, it will let you know there's new data to look at but doesn't interrupt your reading by automatically going to the end.

you could add a "repeater" feature, designed to annoy the hell out of people in a channel. just have it toss back out every incoming line from a channel right back out to it. i made a little bot that did that once, and enabled it in a few channels on dalnet for a while. some people got furious, and others got a kick out of it.:p

i even had an option that would translate each line into pig latin before sending it back.
 
I didn't put lines into a buffer as they come it. That's just more memory being consumed. Having the TCP stack do it seems to be correct to me.

Has anybody else besides Mike C and Trixter tried it? It's really very fast on old hardware (XT class), and I'd be happy to help people set it up.


Mike
 
mbbrutman said:
I didn't put lines into a buffer as they come it. That's just more memory being consumed. Having the TCP stack do it seems to be correct to me.

Has anybody else besides Mike C and Trixter tried it? It's really very fast on old hardware (XT class), and I'd be happy to help people set it up.
Click to expand...

Sorry, haven't had time to do any oldskooling for the past two weekends; I'll try to remember when I finish up some stuff. My plate is somewhat full these days.
 
The new version is posted .. look for irc-2008-0616.zip at http://brutman.com/Dos_Networking/software.html .

Major changes:

  • Backscroll buffer now available
  • Beeper toggle is done by Alt-B instead of the '/beeper' command
  • Statistics command added (Alt-S)

With a 200 line backscroll buffer it requires about 160KB of memory. Without the backscroll buffer it is around 135KB. That includes the entire TCP/IP stack with the ability to resolve DNS names - you don't have to add the overhead of a TSR based TCP/IP. It also includes some pretty generous buffering.
 
very nice! i'm liking it. it's all most people would need in a small DOS client. the buffer seems to work very well.
 
Grr ... a few bug fixes are available. (The backscroll buffer support was dodgy with large buffers. I got bit by 16 bit vs 32 bit arithmetic.)

While I'm here ..

Memory usage without a backscroll buffer is around 130K:
  • 76KB for the executable
  • 30KB for incoming buffer space for Ethernet packets (probably overkill)
  • 10KB for the TCP/IP socket buffer (probably overkill)
  • 8KB for outgoing buffer space for Ethernet packets (probably overkill)
  • 2KB for an internal buffer used to parse messages
  • Stack space, global variables, etc.

With a 200 line backscroll buffer it is around 165KB. And with a 1000 line backscroll buffer it is around 293KB.

Add some room for DOS and the packet driver, and you should be able to run on a 256K machine even with the default 200 line backscroll buffer.
 
Last edited:
the leetIRC backscroll buffer is 1000 lines. 160 bytes per line 160*1000=160000 bytes, due to storing the attribute byte interleaved with the text just like in the video card's memory.

my exec is over 100 KB, lol. i'm not sure exactly how much TCPDRV eats up, but in addition to that TSR my data in and data out buffers each use up 2048 bytes.
 
Well, our goals are different. I want my IRC client to be:

  • Small enough to fit in a 256K machine
  • Fast enough to be tolerable on an XT or PCjr class machine
  • Enough features to be usable, but not much more. I'm not trying to clone mIRC or XChat.

I think that I have a very high performance TCP/IP stack - my netcat program proves that already. An IRC app is probably more useful to a wider variety of people, and will help me test the code more. (Jim already found a big oopps for me - it was just a matter of being in a different environment.)

I probably can make due with a lot less buffer space - the TCP stack is doing the receive window correctly, so it can actually throttle the flow of data by itself. I'm being paranoid by giving the packet driver 20 buffers (each 1500 bytes) to work with and the TCP stack 10KB to work with.

The user interface has been interesting to work on, but somewhat of a pain in the rear. You never realize how inefficient a user interface is until you code one. There is lots of memory movement and lots of calls occurring to set things like color and cursor position. Server side code is generally better to work with because the user interface can be minimal.

Ultimately, I still want a telnet BBS running natively on a PCjr. :)
 
mbbrutman said:
Well, our goals are different. I want my IRC client to be:

  • Small enough to fit in a 256K machine
  • Fast enough to be tolerable on an XT or PCjr class machine
  • Enough features to be usable, but not much more. I'm not trying to clone mIRC or XChat.

I think that I have a very high performance TCP/IP stack - my netcat program proves that already. An IRC app is probably more useful to a wider variety of people, and will help me test the code more. (Jim already found a big oopps for me - it was just a matter of being in a different environment.)

I probably can make due with a lot less buffer space - the TCP stack is doing the receive window correctly, so it can actually throttle the flow of data by itself. I'm being paranoid by giving the packet driver 20 buffers (each 1500 bytes) to work with and the TCP stack 10KB to work with.

The user interface has been interesting to work on, but somewhat of a pain in the rear. You never realize how inefficient a user interface is until you code one. There is lots of memory movement and lots of calls occurring to set things like color and cursor position. Server side code is generally better to work with because the user interface can be minimal.

Ultimately, I still want a telnet BBS running natively on a PCjr. :)
Click to expand...

that's one advantage of your TCP stack, having so many buffers. with my prog, if i don't call the TCPDRV interrupts often enough to retrieve incoming data it's buffers will fill up and cause problems.

i absolutely agree with the telnet BBS too, that's something i've always wanted on my XT. I've tried synchronet on it, but rob swindell has not worked on the DOS version in many many years. it does not have native telnet support.

his source code is available, mike. since you're a C guy, you should look into modifying it to redirect the output through TCP rather than a com port. i suggest this, because other than not having TCP support synchronet is an AWESOME piece of BBS software. i think i might start working on my own BBS when i get this IRCd finished.

btw, after i modified leetIRC to use print and display no color on mono cards it is very tolerable on 8088-based systems. if you have a VGA card in it, you can still do LEETIRC.EXE /MONO to get the big speed increase.
 
TCPDRV is a TSR, so it is kind of limited as to what it can do with memory allocation. I think that everything has to be statically allocated, which limits how much memory it has access too. I don't have that problem - I can use the entire machine for incoming packets if I want to.

On the other hand, the TSR approach is more forgiving about bad user programs. I assume that it hooked the timer tick interrupt, so it is getting a chance to run about 20 times a second. The user program needs to pull data from the TCP stack periodically, but it does not have to do anything special to keep the data moving. In my approach (also used by NCSA Telnet and WATTCP) the user program has to keep making calls to the TCP stack to keep the lower levels of the stack moving - there is no periodic interrupt.

Sorry - I'm not picking up any more projects. I've got a few too many already. Redirecting COM port traffic to a TCP socket is not trivial .. COM port traffic is done a byte at a time, while TCP traffic is done in packets. If you do it naively you will wind up sending one byte per packet, which is a nightmare ..

You've got my Borland C++ 3.0 compiler - you give it a shot.

My code runs fast, color or not. :) All I need is a name for it ...
 
mbbrutman said:
TCPDRV is a TSR, so it is kind of limited as to what it can do with memory allocation. I think that everything has to be statically allocated, which limits how much memory it has access too. I don't have that problem - I can use the entire machine for incoming packets if I want to.

On the other hand, the TSR approach is more forgiving about bad user programs. I assume that it hooked the timer tick interrupt, so it is getting a chance to run about 20 times a second. The user program needs to pull data from the TCP stack periodically, but it does not have to do anything special to keep the data moving. In my approach (also used by NCSA Telnet and WATTCP) the user program has to keep making calls to the TCP stack to keep the lower levels of the stack moving - there is no periodic interrupt.

Sorry - I'm not picking up any more projects. I've got a few too many already. Redirecting COM port traffic to a TCP socket is not trivial .. COM port traffic is done a byte at a time, while TCP traffic is done in packets. If you do it naively you will wind up sending one byte per packet, which is a nightmare ..

You've got my Borland C++ 3.0 compiler - you give it a shot.

My code runs fast, color or not. :) All I need is a name for it ...
Click to expand...

TCPDRV is kind of weird, it doesn't attach itself to the timer interrupt. here is a copy/paste from the official spec:

driver_doio

Perform driver processing

Will call event handlers as required Must be called regularly to process packets.

call
ah = 02H
return
ax = no. of free pkts on IP input queue
cx = no. of free pkts on IP output queue
dl = error code
Click to expand...

that's the interrupt function i have to call to make it process. i read elsewhere on the page that it can be attached to the timer interrupt if i want it to be automated.

i just put a call to it in my status monitoring DO LOOPs so it keeps getting called once every time the loop is run.
 
DOS - has to be 8 chars. ;-0

And 'Bruteforce' is taken:

Code: 
login as: brutman
brutman@bruteforce.rchland.ibm.com's password:
Last login: Tue Jun  3 08:45:26 2008 from ibm-435f5d72d9b.rchland.ibm.com
[brutman@bruteforce ~]$ uptime
 22:53:19 up 50 days, 13:51,  5 users,  load average: 0.00, 0.00, 0.00
[brutman@bruteforce ~]$

That's been the name of my workstation since 1992. The first Bruteforce was an RS/6000 model 340. There were some upgrades. Eventually Bruteforce turned into a Linux x86 machine.

Good call though ...
 
mbbrutman said:
DOS - has to be 8 chars. ;-0

And 'Bruteforce' is taken:

Code: 
login as: brutman
brutman@bruteforce.rchland.ibm.com's password:
Last login: Tue Jun  3 08:45:26 2008 from ibm-435f5d72d9b.rchland.ibm.com
[brutman@bruteforce ~]$ uptime
 22:53:19 up 50 days, 13:51,  5 users,  load average: 0.00, 0.00, 0.00
[brutman@bruteforce ~]$

That's been the name of my workstation since 1992. The first Bruteforce was an RS/6000 model 340. There were some upgrades. Eventually Bruteforce turned into a Linux x86 machine.

Good call though ...
Click to expand...

no check this out

BRUTFORC.Exe

you gotta be creative with these 8 char limits, it's like coming up with a vanity plate for your car.
 
carlsson said:
Pardon me, but shouldn't it be BRUTFIRC.EXE as Mike is developing an IRC client? Or simply BRUTIRC, give or take silly capsing.
Click to expand...

mike b's is more or less just to exercise his TCP stack code... mine is a bad attempt at putting all or most of mIRC's functionality into a DOS proggie. :p

yeah, "most of" works better... i am NOT about to try and re-create mIRC's scripting functionality!!
 
Status
Not open for further replies.
Back
Top