• Please review our updated Terms and Rules here

Another DOS IRC Client

Status
Not open for further replies.
M

mbbrutman

Associate Cat Herder
Staff member
Joined
May 3, 2003
Messages
6,419
Well, that long rambler of a post didn't get me anywhere. :)

Anyway, I'm pretty happy. I started an IRC client tonight and had it running and talking in less than an hour. It's not pretty but it works ..

I was thinking of doing a very simple user interface for it:

  • 3 lines at the bottom of the screen for entering your message
  • The rest of the screen for incoming messages
  • Only one window .. if you join multiple channels all of the conversations will be interleaved. (I could color code them.)
  • No file transfers or anything like that .. just plain old chat.

Thoughts?
 
mbbrutman said:
  • 3 lines at the bottom of the screen for entering your message
  • The rest of the screen for incoming messages
  • Only one window .. if you join multiple channels all of the conversations will be interleaved. (I could color code them.)
  • No file transfers or anything like that .. just plain old chat.
Click to expand...

I would have only one line at the bottom for entering a message, and have that line scroll horizontally if the user tries to go off the line. This is how the "good old clients" of yesteryear worked in text mode. Maybe a separator line above that to denote which is you and which is the channel, but that's it. The more lines for channel text, the better :)

I would not have all channels in a single window because, while reading could be color-coded, how would you specify which channel you were replying to? I would instead keep track of multiple channels simply by letting the user hit a key combo to switch to a completely different screen; or, maybe implement split-screen. I would consult console IRC clients to see how they do it.

I am available for testing :)
 
I'm trying to keep it really simple because I don't have a lot of time for this. The horizontal scrolling for long input is neat, but that will require something more sophisticated than what I had in mind. (I hate tracking cursors and going screen work.)

Good catch on the problem with replying when multiple channels. Switching to a different screen works for CGA, but not mono. I could prefix everything with a tag, but that is a PITA. Or I could just limit to one channel per client and then it becomes the users's responsbility to pay attention to that channel. :) Do people actually try to monitor and interact with multiple channels?

I really don't want a full blown MIRC clone. Just something to use the XT at work for which will keep people amused.
 
Working on mono would be great, then I could use it on my 5150 ;)

Other than that, it sounds like you have things thought out well already!

(Colour coding on a CGA/EGA would be a huge benefit)
 
mbbrutman said:
I'm trying to keep it really simple because I don't have a lot of time for this. The horizontal scrolling for long input is neat, but that will require something more sophisticated than what I had in mind. (I hate tracking cursors and going screen work.)
Click to expand...

Well, you're going to be doing screen handling anyway; see below:

Good catch on the problem with replying when multiple channels. Switching to a different screen works for CGA, but not mono.
Click to expand...

You don't actually maintain separate windows in video ram for all channels; when you "switch" you just repaint the screen for the current channel and start updating. You'll be maintaining a buffer history anyway so this shouldn't be difficult.

I could prefix everything with a tag, but that is a PITA. Or I could just limit to one channel per client and then it becomes the users's responsbility to pay attention to that channel. :) Do people actually try to monitor and interact with multiple channels?
Click to expand...

All the time. I would display the name of the channel and other info in the "separator bar" above the bottom input line.

I really don't want a full blown MIRC clone. Just something to use the XT at work for which will keep people amused.
Click to expand...

Actually, IRC clients are one way to ensure that XTs stick around forever. Most people join a channel and then wait for people to say something interesting; if your client has an option to beep on every new message, it would be mega-frigging-cool, just like the old BBS days -- people could be working on whatever they want and then swivel over to the XT to talk a bit, then go back to what they were doing.

Not that I'm drooling at the mouth waiting for it or anything. ;)
 
I'm conflicted. I want to throw the current version out there right now just to get the TCP stack exercised, but the user interface is, shall we say, substandard .. I probably need to exercise some patience and do a proper UI.

What I described before will work for a first version, and as a matter of practicality it will probably only support one active channel. Another version can add the multiple channel support.

The nice thing about IRC is that it is just *so* easy compared to the code I've been doing. The nasty thing about all of this is the screen handling.


Mike
 
hey mike, if you have time i'd love for you to send me a binary and source for your client. did you write it in the same flavor of C that you mailed me disks for?

i'd love to take a look at it.

i still think you should throw in some drop-down menus and DCC file transfer capability. it comes in really handy on my old machines, i can sit there on a server chatting with folks in leetIRC while at the same time copying some files to it from an XP box. of course, being a QB program handling both chatting and file transfer at the same time on like an XT is less than speedy, but hey that just leaves me more time to chat! lol. (it's pretty bad, if i'm actively chatting while downloading in it i get 3 KB/s if i'm lucky) if i disconnect from the server after initiating the transfer, that frees up some CPU by not doing any of the TCP calls to check for incoming data in the buffer and it bumps it up to around 6 or 7.)

DCC file code is simple, like i was telling you the other day. if you want the details let me know i'll give you the info. not much to it.

btw, if the version of leetirc you tried way back in 2006 was one of the dinky pre-release/testing version i HIGHLY reccommend you download and try out my version 1.1!! http://rubbermallet.org/download/lirc11.zip

it comes with both the source and binary. if you try it, make sure you play around with the menus and be sure to check out the server list dialog box.

it might give you some ideas for your client. if you can't tell by now, i'm proud of my little QB proggie hah. (with good reason if you compare it to most of the other DOS IRC clients out there)
 
Last edited:
I ran it today at work all day long. The channel I was on did not get a lot of traffic, but it survived being up for multiple hours with no problems.

I should be able to get a usable binary out in a week or two. Right now things like my name and nickname are hardcoded, which was cheap and easy for getting started but not very good for distributing to other people. ;-0

I don't intend on shipping the source code for the TCP library any time soon. It is currently at 5400 lines of code, and it's a significant investment for me. I will eventually ship it as a set of binary libraries and header files. The libraries will consist of the TCP code with different options enabled/disabled. For example, one version of the library will be pretty stripped with a small amount of buffer space, minimal tracing, etc. That version will be suitable for very small machines. A full blown version of the library will have every bell and whistle, but will be a much larger binary. (40 to 50KB vs. 25 to 35KB). Turbo C++ users can readily use the libraries, so it will not be an issue.

I'm not really too interested in the DCC feature. I've got a good version of netcat for transfering files/data already, and a good FTP client makes more sense. It can easily be done, but it's not high on my feature list. Keeping it fast enough to use on a PCjr or XT is the primary goal.

I've downloaded LeetIRC again and I'll revisit it tomorrow .. but before I do, is there any hope of it running well on an XT or do I need something faster?
 
mbbrutman said:
I ran it today at work all day long. The channel I was on did not get a lot of traffic, but it survived being up for multiple hours with no problems.

I should be able to get a usable binary out in a week or two. Right now things like my name and nickname are hardcoded, which was cheap and easy for getting started but not very good for distributing to other people. ;-0

I don't intend on shipping the source code for the TCP library any time soon. It is currently at 5400 lines of code, and it's a significant investment for me. I will eventually ship it as a set of binary libraries and header files. The libraries will consist of the TCP code with different options enabled/disabled. For example, one version of the library will be pretty stripped with a small amount of buffer space, minimal tracing, etc. That version will be suitable for very small machines. A full blown version of the library will have every bell and whistle, but will be a much larger binary. (40 to 50KB vs. 25 to 35KB). Turbo C++ users can readily use the libraries, so it will not be an issue.

I'm not really too interested in the DCC feature. I've got a good version of netcat for transfering files/data already, and a good FTP client makes more sense. It can easily be done, but it's not high on my feature list. Keeping it fast enough to use on a PCjr or XT is the primary goal.

I've downloaded LeetIRC again and I'll revisit it tomorrow .. but before I do, is there any hope of it running well on an XT or do I need something faster?
Click to expand...

ah, gotcha. not going the open-source route eh? i don't blame you, i know you've been writing this for over a year now.

and yeah, and XT should be fine for leetIRC. when i complained about it in the past, i didn't realize that somehow it was the VGA card i have that was causing it to run very slow. i don't know why it does it, but it runs great on an 8088 with the mono card installed. other people have reported it's fast with their VGA cards in their XT's.

(the speed issue with that card is not just with an XT. same thing if i put it in my other XT "turbo" clone or a 286. i also know it's not a problem with my software. same thing with games, and even just watching a directory listing scroll the screen from a DIR command)
 
I've ran LeetIRC on my XT with no problems. It's a bit slow in heavy channels, but otherwise great. It even runs on my 5150 with 5151 through a Hercules card (using HGCIBM) :)
 
Mike Chambers said:
ah, gotcha. not going the open-source route eh? i don't blame you, i know you've been writing this for over a year now.
Click to expand...

I haven't decided against open-source. But I have decided against open-source today.

  • It's not fully functional yet
  • It is somewhat tested, but not heavily tested
  • The pool of people who can actually get the development environment and collaborate with me is very small
  • The documentation is too thin for other people to go making changes
 
mbbrutman said:
The nice thing about IRC is that it is just *so* easy compared to the code I've been doing. The nasty thing about all of this is the screen handling.
Click to expand...

You've written a TCP/IP stack from scratch, figured out how to dump PCjr ROMs, hacked an ISA bus onto your PCjr, and you're complaining about the SCREEN HANDLING of all things? Seriously? Compared to those prior efforts, screen handling is easy! :mrgreen:

Seriously, if you need help with screen handling, I've written more screen routines than I'd like to imagine. Ask away.
 
dongfeng said:
I've ran LeetIRC on my XT with no problems. It's a bit slow in heavy channels, but otherwise great. It even runs on my 5150 with 5151 through a Hercules card (using HGCIBM) :)
Click to expand...

While I love the program and concept, it's too slow for me on real 4.77MHz 8088. The screen updating is fine but I can type faster than the program will take my keystrokes, which leads to keyboard buffer overflows.
 
Mike Chambers said:
(the speed issue with that card is not just with an XT. same thing if i put it in my other XT "turbo" clone or a 286. i also know it's not a problem with my software. same thing with games, and even just watching a directory listing scroll the screen from a DIR command)
Click to expand...

Hm... well, that would imply that you're using the BIOS for screen writes. Let me try using LeetIRC with both BIOS screen stuff and with NNANSI BIOS replacement (speeds up BIOS screen handling 5-15x)...

Just running it again on CGA proves it's not using the BIOS as I seen screen snow. And it is pretty damn slow.

I'm not knocking your programming skills... I'm knocking your compiler.

The only thing that is really killing it is the screen scrolling. It takes at least 2 seconds to scroll. Looking at your code, I see that DrawScr is the culprit:

Code: 
drawloc = 22
DEF SEG = &HB800
ScrChanged = 0
FOR y = bufstart + 20 TO bufstart STEP -1
	tmpline$ = LEFT$(Buffer(y), 158)
	curpos = (drawloc * 160)
	FOR tmpval = 1 TO 158
		POKE curpos + tmpval - 1, ASC(MID$(tmpline$, tmpval, 1))
	NEXT tmpval
	drawloc = drawloc - 1
NEXT y

If you or anyone else who is a guru with BASIC can figure out how to speed this up, the program would be usable on 5150/5160 w/CGA.
 
Trixter said:
You've written a TCP/IP stack from scratch, figured out how to dump PCjr ROMs, hacked an ISA bus onto your PCjr, and you're complaining about the SCREEN HANDLING of all things? Seriously? Compared to those prior efforts, screen handling is easy! :mrgreen:

Seriously, if you need help with screen handling, I've written more screen routines than I'd like to imagine. Ask away.
Click to expand...

Eh, I can do it. You've wisely called me out on my sandbagging. ;-)
 
dongfeng said:
I've ran LeetIRC on my XT with no problems. It's a bit slow in heavy channels, but otherwise great. It even runs on my 5150 with 5151 through a Hercules card (using HGCIBM) :)
Click to expand...

yeah, i don't know what the deal with my card is. i'm going to take a video of it updating the screen as new messages come in, it's really bad. i'll do it with a monochrome card too so i can demonstrate how big of a difference there is.
 
Trixter said:
Hm... well, that would imply that you're using the BIOS for screen writes. Let me try using LeetIRC with both BIOS screen stuff and with NNANSI BIOS replacement (speeds up BIOS screen handling 5-15x)...

Just running it again on CGA proves it's not using the BIOS as I seen screen snow. And it is pretty damn slow.

I'm not knocking your programming skills... I'm knocking your compiler.

The only thing that is really killing it is the screen scrolling. It takes at least 2 seconds to scroll. Looking at your code, I see that DrawScr is the culprit:

Code: 
drawloc = 22
DEF SEG = &HB800
ScrChanged = 0
FOR y = bufstart + 20 TO bufstart STEP -1
	tmpline$ = LEFT$(Buffer(y), 158)
	curpos = (drawloc * 160)
	FOR tmpval = 1 TO 158
		POKE curpos + tmpval - 1, ASC(MID$(tmpline$, tmpval, 1))
	NEXT tmpval
	drawloc = drawloc - 1
NEXT y

If you or anyone else who is a guru with BASIC can figure out how to speed this up, the program would be usable on 5150/5160 w/CGA.
Click to expand...

i'm actually in the process of doing a little experiment with that. what i'm trying to do is have QB code actually "compile" some raw machine code. i'll dynamically create a string based on the return values of VARSEG and VARPTR and have it move "x" amount of bytes to the proper position in video memory from where QB stores it. i hope i can get this program to run fast like that. i know just enough x86 ASM to pull that off i think. :p

i'm planning to majorly update LeetIRC with the ASM method of screen writing, along with having a DNS resolution routine so you don't have to run across the house to another computer with a pen and paper to ping the hostname (that will be nice lol) and an option for DCC send in addition to the receive that's already there. (possibly DCC chat if i feel adventurous, but probably not. does anybody actually even use that??) there will also be a built-in identd server.

that about sums up my goals for v1.2, and i'll probably stop work on it after that i can't really think of anything else i would/could need in an IRC client.
 
Last edited:
Well, I took a stab at the screen I/O. It's a PITA. Here is what I have so far:

  • 21 lines of chat area
  • 1 separator line: Will eventually hold some status
  • 3 lines of input: The only editing supported in the input area is backspace.

Turbo C++ provides some high level routines for managing an active window and moving text around. The routines are tolerable for typing - I type 100wpm and I can't overrun the keyboard. The routines are not so great for scrolling the chat area, so I wrote my own based on memory moves. It runs great on a 4.77Mhz machine, so there will be no performance issues.

What I've got now looks slightly better than what I had, but the code is an unholy mess. I need to take a week or two and clean things up. Also, I'm not doing a great job of parsing the incoming messages from the server, so the screen fills up with the detail of the messages that most IRC clients know to filter out. When I get things cleaned up I'll post a copy for people to pound on.

Mike
 
Ok, I've got a test version ready!


There is a zip file with the application and a readme on that page. Give it a whirl and let me know what you think!

General DOS Networking help can be found here:


Support will be provided here and by email (mbbrutman@yahoo.com) if you need it. And of course on the #vc IRC channel on Gimp. (irc.us.gimp.net)

-Mike
 
Status
Not open for further replies.
Back
Top