I was born and raised on Long Island, and at that time the high schools had a computer facility available to them called the Long Island Regional Instructional Computing System. Anyone who was from Long Island in that day used LRICS, if they used computers. It was a time sharing service, a PDP-10, that was running Tenex, as I recall. Everyone was connected to it via dialup teletypes at the whopping speed of 110 baud.
That was what I cut my teeth on in 1975, when I was 17 years old. After High School, I spent 4 years at Clarkson College, getting a BSEE, and another two years getting a Master's of Science in EE, and two years out at Hewlett Packard Corvallis Division, making calculator stuff, and then three years of abortive effort at getting a Ph.D. at Clarkson. After that I spent five years at Clarkson as a staff member, from 1986-1991.
We had been on BITNET two to three years when in the summer of 1988, Clarkson also got an Internet connection. It was good, because all of a sudden I had access to all these things I had heard of on BITNET mailing lists. This was Internet access to the desktop, not just to the mainframes.
At the time, I was hacking on Phil Karn's TCP/IP package, known as KA9Q. The first set of Ethernet cards we bought were 3Com 3C501s, because they were widely supported. Phil's package had support for the 3C501s built in. That was great, because you could be Telnetting somewhere and FTP'ing to multiple sites at the same time.
Then, we got another set of Ethernet Cards, the Racal-Interlan NI5210. The 3Com 3C501 is a first generation card, while the NI5210 is a second generation card. The difference between the first and second generation cards was that the second generation cards could receive and buffer multiple packets at the same time, which greatly increased throughput. So of course, I wanted one. The problem was that KA9Q did not support the 5210, so what I had to do was to write a 5210 driver, and put it into KA9Q, which I did. It worked.
The problem was that everytime a new Ethernet card came out, you had to write a new driver for it. Everybody wrote their own driver, and none of them were compatible. This was a problem faced by all the TCP/IP neworking software vendors, which was solved when FTP Software came along with their packet driver specification, written by John Romkey.
After the release of the specification, a fellow by the name of Karl Auerbach wrote a packet driver for the TRW PC2000, because he was friends with the FTP Software people. Phil Karn got his hands on two of these TRW PC2000 cards, with packet drivers, and he added support for the packet driver specification to KA9Q. At that point the obvious thing for me to do was to write a packet driver for the 5210, and I did. Then I wrote one for the 3C501, and one for SLIP.
At this point I noticed that there was a lot of common code between drivers, so I made a packet driver skeleton. I took the common code that was resident, and made that into a head, and I took the common code that was transient, and made that into a tail. The remaining driver-dependent code was specific to each board, and was put into a resident and transient part. I then published the skeleton on the Internet. A couple of other people wanted drivers for second generation Ethernet cards, so they picked up the packet driver skeleton, and wrote their own packet drivers, and it mushroomed.
It solved a problem for lots and lots of people, and so vendors added support for it in their packages. NCSA Telnet put it into theirs; Erick Engelke at the University of Waterloo added packet driver support to TinyTCP and created a TCP/IP package, which directly supports packet drivers, and only packet drivers. The original PC-IP, MIT's venerable free TCP/IP package, was adapted to packet drivers.
We're now on the 11th revision of the packet driver set, which has 60 some odd drivers. For the past two and a half years, I have been selling packet driver support services for a living and improving the packet drivers. This way, people who need the support can get it, and people who can take the software and run with it can do that also. The hardware vendors have paid me to write drivers, some of the protocol stack vendors have paid me to supply support, and even some end users have paid me to write packet drivers. So the support comes from all over the industry, which is good.
As I sit here in my office looking around, I am literally surrounded by computers. I've got 10 of them of various sizes and shapes, all with Ethernet cards, as you might expect. Two of them are UNIX boxes, but other than that they all run packet drivers. Over in the corner I have a stack of Ethernet cards that almost goes up to the ceiling. In fact, it would if I let it, but it tends to fall down if it gets that high.
When I was at Clarkson, my advisor and I, Professor Dave W. Bray were publishing some software under the name Virtual System Software, which was fine except that the name actually belonged to a corporation down on Long Island. Not good! So when I went to start my company, I tried registering Virtual Systems Software, and it was taken. Then I tried some equally lame name, and that too was unavailable. When you're trying to go into business, you really don't want to spend a lot of time iterating with the New York State Division of Corporations, waiting for a name that has not been taken. So I chose a name that was guaranteed not to have been taken.
A professor friend of mine at Clarkson was from Wales, and he named the computers in his lab according to days of the week, months of the year, seasons, etc. In English this is kind of dopey, but in Welsh it sounds really cool, and he had a Welsh dictionary. I'm a fan of Celtic music, so I scarfed his Welsh dictionary and went grubbing through it. Just for grins, since I'm a Quaker, I looked up Quaker, and it turns out the Welsh for this is Crynwr. To pronounce this, you roll your r's, you pronounce the w like it was two u's, like the two o's in moon, and you pronouce the y as if it were a u. Crrrrunooor. It was well, moderately pronouncable in English, but I decided to go with it anyway. Of course, it was unique in the domain name system, and it was unique in the New York State Division of Corporations, so it's my name.
Of course, some people have trouble pronouncing it. They call me up and they say, "Is this Crinwe... Crynwuur... Crinweer.... ...." Yes, I say, this is Crynwr Software, and I'm Russ. One out of ten calls, the person on the other end will ask, "Are you THE Russ Nelson? You mean I'm talking to THE Russ Nelson?" And I'll say "Get on with it!"
It is sometimes disturbing when you walk into a booth in Interop, and the people in the booth know you already, and it's noone that you've ever heard of. They're using my software, or they've looked at it, or someone has asked them about packet drivers, or told them about packet drivers. That's one of the bad parts about freely copyable software. I have no clue about who is using my software. In fact, I got a fax four or five weeks ago from a company in Taiwan, who was doing an X-Terminal implementation running over packet drivers, and they wanted to license the code. So I said, "you can go ahead and use it. But the only thing is that the source must be freely available, and you must respect the license, which says that the binaries must be freely copyable."
The way my business works, I give away my software, to create a demand for my services, which I turn around and sell to people. Packet drivers must remain freely copyable, since that's how I get my business. When you have a company that wants to distribute packet drivers without source, I have to be compensated for the presumed lost of business. For the vendors, it's a deal, because the royalties I'm charging them are less than the cost of the disk they put the software on. I take that profit and turn it around into packet driver development. So they win, I win, and packet driver users everywhere win.
In between writing, rewriting, and debugging packet drivers I do some contract development work. Lately I've written Red.FS, a virtual drive for UNIX, for my friends at J. River, Inc. They also use support packet drivers in their TCP/IP implementation, ICE.TCP.
The packet driver spec is now in release 1.09. Version 1.10 was written up, but never distributed widely. It's not clear how it will evolve, since real mode DOS appears to have come to the end of its life with the impending release of Windows 4, known as Chicago. I'm not sure it makes sense to add incremental improvements to a real-mode specification when the industry is going toward protected mode software. Packet drivers don't make sense in a protected mode environment; it may sound like I'm being negative, but I don't see a huge future to my business. This is ok, because I've been doing it for six years, and I always have more ideas than I have time to do.
The big question is What will come next after DOS? What happens, for example, when you start running KA9Q over a real operating system? KA9Q really is an operating system in and of itself. It's a multitasking kernel, and a TCP/IP stack, and it's a user interface. It has clients and servers built into it. Phil Karn has resisted attempts to make KA9Q into a real operating system, because his feeling is if you want UNIX, get UNIX, and put the radio interface into it.
In fact, that's what's happening; the latest version of Linux now has AX.25 radio encapsulation built into it. The future of KA9Q is for the good stuff to be ported to Linux, I think. Then you will have a real operating system, and real protection between processes, and real Ethernet drivers. This is not to say that packet drivers are fake, but in UNIX they're built into the operating system, and everything is running in 32 bits, so you have a huge address space, no kluges.
In a period of a transition period between operating systems, like what we have today, the Crynwr Drivers are a great resource for driver writers. One of the things that I've found in this industry is that the hardware manufacturers are very loathe to disclose programming information for their hardware. They all think their stuff is so good that everyone is going to want to clone it, but it just hasn't happened. Yes, some Ethernet boards have been cloned, such as the NE2000. The NE2000 is nothing more than National Semiconductor's demo board put into production. It's not high tech, not rocket science, and yet to this day, programming information for the NE2000 is hard to get. So on the net, whenever anyone asks, "How do I program for this board, or that board," I just say "go look at the Crynwr drivers, that's what they're there for."
A large number of Ethernet drivers in Linux were written by consulting the Crynwr packet drivers, and I believe that some embedded operating systems that are not DOS compatible have used them as well. Microsoft has told me that there is a market for NT drivers, and has encouraged me to write those. There are two reasons why I don't: I'm burned out on doing drivers; six years doing one thing is a long time, and the other reason is that I don't see a market for it yet. The market for Linux drivers is not there yet, and in any case Don Becker has that sown up. While there might be a market for Windows NT drivers developing, I've got a billion ideas for all sorts of things I'd like to work on and things I'd like to support. If I'm spending all my time writing drivers, while they are necessary and useful, I can't work on any of my other ideas, or interests. So when DOS packet drivers die, I'm probably going to move on. People will be using them long after I've ceased making new ones; just because I've ceased writing new ones doesn't break the old ones. Since source is available, if there are any bugs I'm unwilling to fix, or I've gone out of business, someone else can fix them.