• Please review our updated Terms and Rules here

What would you want in a DOS IRC client?

M

Mike Chambers

Veteran Member
Joined
Sep 2, 2006
Messages
2,621
I am writing a new DOS IRC client from scratch here. The old one I wrote back in 2006 in QuickBASIC was okay I think, but lacking DNS resolution and was super slow on 8088s and even low-end 286s. Now that I can actually write code in real languages ;) ... the new one will be in C, mixed with a bit of assembly where speed is important, and I was going to use the TCP/IP stack I wrote myself which does have DNS support, so that's already one improvement. What I'd like to know is, what would be the most important features that you would want to see in this new client?

There are already a number of DOS IRC clients out there obviously, and I really want this one to be the best available. Mike Brutman's IRCjr is pretty good. It's fast, reliable, and supports multiple "windows" that can be switched to for each channel or private message session. I think his was originally designed to be pretty much just a program to help exercise his TCP stack, with a few nice things added since then but I don't believe he ever plans to add things like mIRC color code support, DCC chat/file transfer, etc. -- or at least that's what I gathered when I talked to him about it.

So, I'd like to take a whack at filling in the gap and develop a light, but fully-featured client for those of us who still screw around on vintage DOS systems.

I was going to still include all of the features I had in my old QB client, so things like:

- Built-in server "favorites" list for quick connecting to the networks you frequent.
- mIRC color code and bold support
- DCC file transfer
- Support for logging chats to text files
- Optional timestamping
- Drop-down menus

Of course, there will be improvements like DNS hostname resolution support, separate windows and backscroll buffers for each channel or private message session, and it will be as fast as I can make it. I was going to put a lot of emphasis on making sure it's responsive even in crowded channels and when you've got multiple channels open.

What else would you guys like to see in a new client? Please throw any suggestions you have at me. One thing I've already got planned is the ability to optionally use 50-line text mode if available on the machine. Another possibility would be the ability to actually have true window support, where each chat buffer could actually be popped out instead of being full-screen, could be resized, moved with the mouse, etc. While it sounds nice, I'm not sure how useful it would really be, or if that's really worth devoting any time to.

Opinions? Suggestions? Death threats? If a new IRC client would interest you, let me know what you'd like please!
 
When I wrote IRCjr the requirements were very simple - get on an IRC network and enable basic chatting. A TCP/IP stack without applications doesn't have much value to anybody, and IRC was a good first candidate for an application because the protocol was simple and it could be made to work well even on a slow machine.

Back then I said no CTCP (/me, /version, etc/) or multiple channels. I lied. I reserve the right to keep lying and adding things as the need arises. MIRC color codes are cute, but I think the ability to connect to multiple servers at the same time would be higher on the todo list.

IRCjr has pretty much always had DNS hostname resolution available, courtesy of the TCP/IP stack. It has separate windows for each channel or private chat session. Its responsive on busy channels due to the unique buffering scheme I put in. It supports CGA, MDA, EGA and VGA with screen sizes 80x25, 80x43, 80x50. The TCP/IP stack is proven to be robust and fast. Basically, it has a lot of what you are planning on rewriting already.

It doesn't have your "true" window support but I would see that as wasting screen real estate with pretty borders. On an 80x25 display there is not a lot of room to waste. Adding a list of favorites would be trivial, but in 4 years now nobody has asked for it. MIRC color codes and DCC file transfer come up once in a while, but I haven't had time to get to them. (Maybe on the color codes, but I never understood DCC ...)

Instead of re-inventing the wheel, have you considered working with the one that is out there that is pretty close to what you are describing already? That's why I open sourced all of mTCP ...
 
Just to be clear Mike, I wasn't trying to attack you or call your client bad or anything. I hope you didn't take it that way. It's a great little program that does exactly what it was intended to, and does it well. In fact, whenever I get on IRC from a vintage machine lately I've been using IRCjr rather than LeetIRC. It even is currently running on my 5150 as I type this. I just thought it would be nice to write one with some extras, even if they aren't necessarily important. Also, I tend to agree that having moveable text windows is generally not a good idea in the already cramped text modes. That was just a thought that I was throwing out there.

I may have re-invented the wheel by making my own TCP stack, but I like to write my programs from the ground up for (what I assume is) the same reason you started writing your own even though WatTCP existed and worked quite well -- the challenge, and to learn how TCP works at the low level. I also think my IRC client would be just different enough that it would be less hassle for me to just write the framework myself. Please do not take this as an attack on your excellent work, because it really is not my intention in any way Mike!

mTCP and the suite of sample apps you wrote is an absolutely awesome piece of work, and it's probably the most important development for us vintage PC fanatics in quite a few years.

Edit: I also freely admit that mTCP is more robust and can achieve higher transfer rates than my stack, and developers looking for a TCP stack to build apps with should definitely go with your library -- especially for applications where speed is very important like file transfers. It's also been been put through a lot more testing than mine, and it's proven to be rock-solid.
 
Last edited:
All I can think of but I haven't used the current stuff would be keyboard shortcuts for switching or minimizing windows, etc. Maybe a server/debug window option to watch the communications below.
 
I didn't see it as an attack or unfair criticism.

Back when I started writing mTCP I had evaluated Trumpet and found it too buggy. I wasn't aware of WATTCP at the time. But the decision would not have changed - WATTCP has not been maintained in a while, it has some problems, and I really didn't like that I'd have to buy the documentation. Lastly, there was going to be no help or support if I wanted to improve WATTCP to make it better. That is why most WATTCP applications are stale now.

If you want to do a client with more features and eye-candy, I'm all for that. I just thought it was striking that with the exception of MIRC color codes and DCC, most of what you described already exists.

On my todo list is adding some user input history so that you can use the arrow keys and repeat something that was previously entered. Maybe some scripting support to make signing in easier. And in the longer term, multi-session support.



Mike
 
Well, I love music, would be nice to have the option to play a midi file, or even just pc speaker music. That would be very nice!
 
Thanks for the suggestions so far. The music thing is interesting, lol. Considering that this is going to be developed mainly with 8088 and 286 machines in mind, I don't think I'll worry about that in the immediate future because those things aren't going to be able to play anything other than WAV and MIDI files with such weak processors. MIDI files sound terrible, and it's rare to find an 8088/286 with enough hard drive space to store a whole song in WAV format. :)

Maybe down the road as a plug-in that could do MP3? You'd be pretty much required to use a high-end 486 for that though.
 
Great Hierophant said:
How about a function to convert images from 24/16/8-bit to 4-bit so I can view all the pr0n I download from those racy IRC channels :p
Click to expand...

Well, that's kind of why I haven't done the MIRC color codes yet. I know certain people on a certain channel who misuse them in a horrible way, and I don't want to be a party to that ...
 
That (almost) brings up a popular convenience feature. Shortcut keys you can assign to macros and/or assigning ti an external file. While it could be juvenile txt images (which sometimes can be amusing) you could also just macro a quick (they set alt+l to "lol") or "<-- I'm with stupid" phrases that the user could set then use.

External script files could even be used for logical commands to respond to actions like if finger(user) = 10.0.0.1 then send.server "/kick $user" or if $user join then server.send "mod +i $user".

Wouldn't be too hard to make a pretty expandable and capable system.
 
Not sure what an 8088 or 286 could handle but this is what I like in an IRC client:

Being able to be in multiple rooms and networks (should be some easy way to switch between them)
Logging of room chat with timestamp
Private channels in a seperate panel, beep when somebody msgs you
simple file transfers
 
I think that keyboard macros are fairly easy to implement.

Allowing the user to set a response to a specific action (somebody joining, somebody using /version or /ping, etc.) would be a bit more work, but still not terribly hard.

Full blown scripting is more difficult, but still doable. There are a few sampe BASIC interpreters out there if somebody didn't want to use FLEX and YACC and write their own grammar directly. About a year ago I started toying with a BASIC interpreter as an extension to an HTTP server; that provides an easy way to do dynamic content in a DOS environment without stopping and reloading the HTTP server.

Multiple channel support on the same server is pretty easy - IRCjr supports that by opening a new window for each channel and (public or private). Multiple servers is on the long term todo list.

Simple file transfers? I don't understand the appeal, but then again I've never had the urge to transfer files through an IRC client. Usually somebody sends me a URL or I give them an email address to send it to me directly. Firewalls seems to be very unfriendly to IRC file transfers; they know to look for FTP active and passive connections but that's about it.
 
I'm going to mention one other requirement that you probably didn't think of Mike ... BIOS screen handling.

The first versions of IRCjr gave the user the option to use the BIOS for the screen handling if they were on a near compatible. It was slow but it worked. When I changed compilers I lost the ability to have the library handle it for me.

Recently I had a user who uses a screen reader contact me about adding it back in again. It is something I never thought about but the screen readers often key off of the BIOS calls to know where the screen was updated. If you are doing memory writes for speed then the screen readers can't detect the updates.

(The next IRCjr is going to add this support back in. And I'll probably fix all of the other programs except Telnet, which due to its nature won't benefit as much from a screen reader.)
 
mbbrutman said:
Recently I had a user who uses a screen reader contact me about adding it back in again. It is something I never thought about but the screen readers often key off of the BIOS calls to know where the screen was updated. If you are doing memory writes for speed then the screen readers can't detect the updates.
Click to expand...

This is actually an incredibly common use for DOS, and a good point for anyone writing new DOS applications.
 
Regarding IRCjr, the other week I almost got an ISO8859-1 compatible codepage running on my 8088 with DOS 4. Supposedly it works better with newer DOS versions. While that approach has very little to do with IRC, one feature I'd like is if the client optionally had overlay codepage conversion for at least whatever subset of ISO8859-1 and CP 437, 850 etc, instead of configuring the computer to alltogether use a custom codepage for input and output.

So Mike C, I wouldn't care much for mIRC colours or fie transfers, but a client that can send and receive non-ASCII characters as some ISO standard and/or UTF-8 (which I've seen is becoming more and more common on IRC) is something I'd like.
 
Great Hierophant said:
How about a function to convert images from 24/16/8-bit to 4-bit so I can view all the pr0n I download from those racy IRC channels :p
Click to expand...

Lol, well that would actually not be too difficult to do. There actually have been a few times where I was using IRC in DOS and people have pasted links to (non-pr0n) images. I think I might just look into that after everything else is written.



mbbrutman said:
Well, that's kind of why I haven't done the MIRC color codes yet. I know certain people on a certain channel who misuse them in a horrible way, and I don't want to be a party to that ...
Click to expand...

I can't help but think you are talking about the guys on my server. :)




barythrin said:
That (almost) brings up a popular convenience feature. Shortcut keys you can assign to macros and/or assigning ti an external file. While it could be juvenile txt images (which sometimes can be amusing) you could also just macro a quick (they set alt+l to "lol") or "<-- I'm with stupid" phrases that the user could set then use.

External script files could even be used for logical commands to respond to actions like if finger(user) = 10.0.0.1 then send.server "/kick $user" or if $user join then server.send "mod +i $user".

Wouldn't be too hard to make a pretty expandable and capable system.
Click to expand...

Now this is actually a really good idea! It wouldn't be difficult to implement at all, I'll add this.



Unknown_K said:
Not sure what an 8088 or 286 could handle but this is what I like in an IRC client:

Being able to be in multiple rooms and networks (should be some easy way to switch between them)
Logging of room chat with timestamp
Private channels in a seperate panel, beep when somebody msgs you
simple file transfers
Click to expand...

An 8088 is definitely powerful enough for this, and I was already planning on having those features for sure.



mbbrutman said:
I'm going to mention one other requirement that you probably didn't think of Mike ... BIOS screen handling.

The first versions of IRCjr gave the user the option to use the BIOS for the screen handling if they were on a near compatible. It was slow but it worked. When I changed compilers I lost the ability to have the library handle it for me.

Recently I had a user who uses a screen reader contact me about adding it back in again. It is something I never thought about but the screen readers often key off of the BIOS calls to know where the screen was updated. If you are doing memory writes for speed then the screen readers can't detect the updates.

(The next IRCjr is going to add this support back in. And I'll probably fix all of the other programs except Telnet, which due to its nature won't benefit as much from a screen reader.)
Click to expand...

I'd have never thought about that. I'll see how much it slows things down, I wonder if it might be better to make this optional and enabled by using a special command line argument.



carlsson said:
Regarding IRCjr, the other week I almost got an ISO8859-1 compatible codepage running on my 8088 with DOS 4. Supposedly it works better with newer DOS versions. While that approach has very little to do with IRC, one feature I'd like is if the client optionally had overlay codepage conversion for at least whatever subset of ISO8859-1 and CP 437, 850 etc, instead of configuring the computer to alltogether use a custom codepage for input and output.

So Mike C, I wouldn't care much for mIRC colours or fie transfers, but a client that can send and receive non-ASCII characters as some ISO standard and/or UTF-8 (which I've seen is becoming more and more common on IRC) is something I'd like.
Click to expand...

This would be a really great feature. One of the users on my IRC server wrote a small DOS IRC client about a year ago, and he had actually implemented some codepage translations like that.
 
Last edited:
You must log in or register to reply here.
Back
Top