where everybody knows your name

Sheesh, you step out for a couple of days and people start hassling you to write (thanks Christoph ;)

Anyway, I’ve sort of backburnered filesystems for a little while. The work is still interesting, but its hard to hit a moving target, which is what this is until all this DOS packets stuff is resolved. I’m still waiting on an email from Michal with his assessment of the situation, so I want to wait for that before planning my next move.

In the meantime, I’ve started looking into a port of PuTTY. So far I’ve got the core building, to the point where the link fails because all of the platform-specific functions aren’t there. All thats left to do now is implement them.

I’m starting with plink, which is roughly equivalent to the UNIX ssh - does the protocol, but no real terminal smarts, leaving that to the calling console. Writing (or borrowing) a full-blown terminal emulation will be required, but for instant gratification I want to see a remote login first.

One thing that even the command-line tools need is a way to accept a password without displaying it. The normal AROS console.device doesn’t allow this, so I’ve implemented an extension to the FSA_CONSOLE_MODE IO command that allows echoing to be switched on and off. My original plan was to extend the DOS SetMode() function to make the echo toggle (easily) available to user programs. It currently only recognises 0 and 1 as valid inputs, so by using a higher-numbered bit, we could just use that call. I asked for feedback on this idea, and Fabio Alemagna responded positively, but pointed out that a PuTTY port could possibly form the basis for a new console.device that has a full terminal emulation in it (ala xterm).

I think this is a great idea, as the standard console seems quite limited. In interesting twist, if we had a really great console, then the need for PuTTY is removed somewhat, as something like OpenSSH can do the trick. On the other hand, the PuTTY code is much cleaner, so I’d be inclined to use it, but not port the putty tool itself (though a GUI session manager is still possible).

If we had a better console.device, then we’d also need an API to drive it - something like termios on UNIX, but with a more pleasant interface. So until I have an idea of what to do here, I’m not going to extend SetMode(), because I don’t want to make a new interface that will become legacy if a new console interface appears. So for the moment, plink will do a IOFileSys call for FSA_CONSOLE_MODE directly. Its a little more unwieldy, but I think its the right first step.

Oh, and by the way, a couple of people have already mentioned KingCON. Sounds great, but without source, I’m not interested (and if there is source, a quick Google doesn’t find it). Remember that AROS is also an educational experience for me - porting software is far less satisfying than writing it myself.