June 1999

10.48: After quite a lot of struggle and finally giving up on GNU C support, I've made a test release of FISH. Version is 0.6 beta 1.

Time to take a break from that piece of software...

13.54: Hacked in host key verification into FISH today. It looks like it works.

Now, there's still that memory problem that Jérôme found to try to track down...

06.17: FISH is advancing at a fast rate right now. Preparations for a new I/O model have been made, and some functions have been moved and generalised in their own modules.

The I/O model that I intend to develop will allow an unlimited amount of asynchronous I/O channels to be active simultaneously. To each channel and for each direction (if there are two), a chain of functions to be performed will be tied, dealing with things like compression, uncompression, encryption, decryption, sending to a general I/O queue or to a small size packet (basically the keyboard :-)) I/O queue, or out through some I/O port.

What I see is a number of channels that will handle I/O from the keyboard, to the terminal, to and from whatever local part of a SSH tunnel there may be and the SSH end (that will be the one and only "remote" channel, the others are "local" channels). All channels will put whatever input they get into a general I/O queue, possibly after decompressing and decrypting. The main program will loop, getting data from that I/O queue, will process it in whatever fashion nedded, and will put it on the output queue of a chosen channel. All channels will handle that output by simply sending it out, possibly after compression and encryption...

We'll see what that will give. At the very least, I foresee a more elegant system than what has been implemented so far.

09.18: I wonder why I've gone into the business of supporting GNU C on VMS. At least on VAX, it stinks as soon as you want to do serious work. It wants to be like VAX C (just like George Bush wanted "to be like you, Ron!"), but does that half-heartedly and incompletely. Granted, it makes variables into program sections instead of global symbols, just like VAX C, with the resulting problems as soon as you build libraries that contain modules with global variables (you didn't know? They become invisible!). Why the GNU C developers couldn't do the right thing and make global variables into global symbols i beyond me. Had they done so, the world would be a lot simpler place to live in. Hmm, what was that? Oh, the constructs "globaldef" and "globalref", you say... Nope, they are not implemented in GNU C... or rather, they are implemented through some obscure trickery with inline assembler declarations. The result is that you get really ugly macros to get around the whole brouhaha, especially if you want to support at least DEC C and GNU C.

Bleah!

I guess one way would be to hack GNU C to behave correctly... Perhaps another time, I've already enough to do, thank you very much...

00.44: Sometimes I get so totally frustrated with some people. I asked people to test FISH for me, and if they run into problems, to send me logs. So what do I get today? Oh, a vague reference to a "pointer type mismatch" error, no file name, no line number, no log. And this is from, as I understand it, a programmer.

Where the hell is the world going?

11.23: Haven't said too much here lately, have I?

Summary of what's happened the last 2 months:

• My OpenSSL work has found its' way back into the main distribution in time for the release of version 0.9.3, May 24th.
• FISH is being developped further. I got RSA key generation to work just a few minutes ago.
• I finally got the necessary stuff into the OSU HTTP server to get it to compile and link nicely with OpenSSL, and Dave took it and put it into his source.
• I'm reconsidering the memory allocation mess in GNU emacs. I think it's time I start using the LIB$ VM managing routines, and use a special zone for the part that is going to get dumped into the dump file. I wonder, though, how well calls to malloc() will survive. Ah well, we'll see...
• Other things that I forget...