• Please review our updated Terms and Rules here

IRCjr (Was: Another DOS IRC Client)

Mike Chambers said:
the enemy of better is good enough.
Click to expand...

No, 'good enough' is knowing when the investment has been appropriate and it's time to move on.

What I've got is very usable, stays up for days, and runs with very little memory. It could do more, but I like the set of features it has now. The CGA snow annoys some people, and what I did mitigates it without completely bogging things down. It's easy to fix it all the way, and I probably will when I do another bug fix.

Things that mean more to me now:

  • Logging
  • Timestamps
  • Parsing some of the server messages

And further out, I want to rewrite the screen handling and backscroll buffering code so that I can handle incoming messages better while the backscroll is active.

But I've done enough for now to meet my objectives. Hence, 'good enough'. Given that all of 6 people have probably used it by now, I seem to have a very picky user set. ;-0
 
lol. truth.

and at least one has been developing his own, so he doesn't use it very often.:eek:

i use it on the 8088 fairly frequently tbh. 286 or faster, and i'm on my client.
 
Trixter said:
It is unfortunate that all of your beta-testers are also programmers! :)
Click to expand...

I've been thinking about how to slim it down some more, and today I coded it.

The target was the screen handling, as that was messy. I wasn't going to mess with the TCP code - that works, and I've been squeezing it for a long time already. But the screen handling code looked like a crawling horror.

In the original code I:

  • Let the C runtime put new strings up on the console. (This means I couldn't put new strings up if the backscroll feature was active.)
  • Saved and restored the current screen whenever backscroll was invoked
  • Had two different buffer areas - one for the backscroll area, and one for the current screen that wasn't in the backscroll area yet

You can see where this is heading ... two different save areas is more complex than it needs to be.

In the current test code I unified the buffers. All screen updates go to one buffer first, which contains all of the data. Then after all screen updates are applied (usually at the end of a line, or in some cases multiple lines) I draw the screen from the buffer back to the video memory.

This has some advantages:

  • The code is much simpler now.
  • I can speed things up by doing two or three lines of updates at a time before drawing, instead of one line at a time. This helps when you get those floods of lines from the IRC server.
  • I can change the program flow so that I can add to the buffer in the background. (With the old code I couldn't add anything without having the screen available because it was using the c runtime to draw chars on the screen.)

That last feature will let me process incoming data in the background while the backscroll buffer is being viewed, which is a big plus - no more missed 'pings' and no more TCP/IP buffers in danger of being filled. As a result, I should be able to cut my TCP/IP buffers down quite a bit with no fear of lost data.

The new code so far (with equivalent function) is just over 1400 bytes smaller, which is about 2% of the code size. Expect a new version sometime this week. With the snow completely eliminated. I won't be lazy this time. :)
 
cool. that's exactly how i did it also. no need for two buffers. and i know what you mean about those floods of lines. before i had it scroll multiple lines at once for new text, it was so slow you would pull your hair out waiting for it.
 
It's taking a little longer, but I'm making some other changes ..

I really wanted to plug my 386 straight into the back of the cable modem. Right now it goes to the Internet through a Linux firewall, and the IP address, gateway, nameserver, etc. are statically assigned by environment variables.

Tonight I implemented a DHCP client for the TCP/IP stack. So now the 386 can get everything it needs from the Linux box or directly from the cable modem. Woot!

The IRC program wont' change much - it will still pick up everything it needs from the environment variables. But now those environment variables will be set by another program which does the DHCP negotiation first. You'll have one program that you run when the machine boots to get the addresses, and then the rest of the programs that use my IP stack will get those addresses via the environment variables.


Mike
 
nice news about the DHCP ability. still no config file though? you should do it like leetIRC. again, i know you're not trying to make a client like that but it's pretty easy to have the configuration wizard create a file and then your client loads it when you start it.

if you run it for the first time, you'll see it - or just start it like LEETIRC.EXE /CONFIG
 
A screen based config utility takes precious code space. I'm trying to keep everything simple and under 192K of *total* memory, including buffers, TCP/IP stack, and DOS.

The plan at the moment is:

  • Change the IP configuration to be done by an ASCII file instead of environment variables. An environment variable will point to the file. I keep adding options and running out of environment space, so this will cure it.
  • Release the DHCP client. The DHCP client will set set the configuration file up automatically. The DHCP client has worked on every server I've tried it on, so I'm pretty sure it will work for everybody.
  • Add support for a HOSTS file so that people can hard code names to IP addresses.
  • Investigate a small change to enable running the entire stack over SLIP connections. I assumed a class 1 packet driver (Ethernet only), which doesn't work for SLIP connections. Programs like SLIPPR can emulate Ethernet, but I'm getting hung up because there are no ARP responses coming back from the other side. (ARP doesn't make sense on a serial link.) Thrashbarg did some testing and collected a log file to show me what was going wrong with his SLIP setup. (Thanks!)
  • Change the IRC configuration to be done by a new configuration file. Not much needs to be stored here, so this should be easy.
  • Add logging to a file and timestamps on messages.

This is all going to happen in the next few days. Longer term I need to add ICMP support, a 'ping' command, and a few more useful apps. And I'm still looking for testing and people who are interested in programming to it. (That might be premature given the changes that I'm making ...)


Mike
 
well for sure, post it when you compile the newest revision. i'd like to try it again. it's fun to load it up in dosbox or qemu as an alternative to mirc.. just for kicks.

btw, does your client use WHO or NAMES to see who is in channels? guys using xchat on my IRCd have been having problems sometimes becuase i haven't implemented WHO yet. just curious how you do it.

i think that's about the last command i need to write response code for, then it should be RFC 1459 (minus server linking, which i still plan to do now)
 
Delayed response:

My client doesn't bother to send a WHO or NAMES command to see who is in the channels. It does the registration process and the JOIN command if you specified a channel on the command line. Usually the server will tell you who is in the channel as a response to the JOIN command.

I've also got a little bug where if the NICK is in use already then the registration process will fail. I need to parse that exchange and detect errors, and then pop up windows that allow the user to specify a different NICK if the NICK is already in use. Longer term there is more parsing I can do, but it does add a bit of code for not much usability gained.
 
You must log in or register to reply here.
Back
Top