You might also look on our AMPM Links Page for other software, some of which is free and some of which ain't.
To the best of my knowledge, these programs and packages are freely distributable. If you can assert otherwise, please contact me at email@example.com.
What fingerproxy allows you to do is things like this:
SET REDIR FINGER "www.google.com|80|GET / HTTP/1.0\\r\\n\\r\\n"@fingerhost > OUT.HTMNow you've got www.google.com dumped to a file. Hmm, I wonder what you could do with an HTML file?
The reason you can't use the regular TELNET.LIT to do this is because it does not allow you to redirect its input or output. While you could FORCE the job it's attached to to pass input, the output is going to the terminal whether you like it or not, and you can't capture it (well, I guess you could write a terminal driver that dumped to disk, but that's getting even more insane). And you can forget FTP.LIT and TFTP.LIT because those programs crash when fed arbitrary data they don't see as transactions.
FINGER.LIT, however, doesn't care or parse what it gets back and does allow you to redirect its output, but it's hardcoded to port 79, hence this method to let it talk to other ports. (I'm really trying hard to avoid saying the word "p**xy" to stop the script kiddies from coming here.) Essentially this is a kludgier, lower level form of URL, but works on 1.3.
The way to talk to fingerproxy is very simple: a hostname, followed by a pipe character, followed by the port, followed by a pipe, followed by arbitrary data. This should not be considered binary safe, so to pass arbitrary characters, binary-encode unsafe characters with \0xXX (such as \0x7f). \n \r \t \b are also accepted, and \\ is turned back into a single backslash. You can pass a string as long as FINGER.LIT will let you on the command line. The reason why I have double-backslashes in the example is to stop the AMOS command shell from eating them. The response starts with a single status character (usually 0 for request accepted), and the data (if any) follows. 1 indicates a bad request, 2 indicates an unacceptable hostname, and 3 indicates a system error.
Because this is a p**xy, you should only install it to listen on an inside-facing interface. Don't blame me if you point this out on the WAN and you become the new rear-end Regina for your neighbourhood Russian hacking ring. Its security precautions are trivial and a thoughtful black hat might possibly pwn you if you are incautious. You need to configure it first to tell it where your netcat and (optional) regular fingerd are located -- if you specify where your fingerd is, requests not seen as fingerproxy commands are passed to it, so it still acts like a regular finger. Then wire it into your inetd; it requires no command line options. I strongly advise running it as an unprivileged user. I offer it under the Floodgap Free Software License.
Most of you will want ANSI.TDV, which is the one I also use primarily, or possibly VT100.TDV. KAISER.TDV is my customized terminal driver, born of necessity when I originally discovered in horror that there was no support for VT100 compatible terminals in AlphaTCP 1.3. Although the others work better in most cases, it might be useful if you need to hardcode a terminal size. I use all of these with Mac OS X Terminal and they work great, but they also work with PuTTY and should work fine with most xterms.
To install, copy the .TDV driver(s) you want to use into DVR:. If the TDVDEF line in AMOS32.INI does not load all drivers (i.e., if it's not TDVDEF *), add the new one(s) to the TDVDEF line and check it with MONTST. Either way, you will need to reboot after the TDV is installed. You can then Telnet to your machine and select ansi, vt100 or kaiser as the terminal type, depending on which one(s) you've installed.
KAISER.TDV expects an 80x40 window since this is the normal size I work in. If you want to change this, edit byte offset $000e-f and change the bytes $28 $50 to your desired rows and columns respectively. I have not tried this driver with a real VT100-compatible serial terminal connected to one of the serial ports, but if you do, please let me know how it works.
At some point some wag is going to ask how you get Kermit itself onto the Alpha Micro, to which I can only suggest careful prayer. Jokes aside, you might be able to get the source code on there with a simple text transfer ...
Like most versions of Kermit, Alpha-KERMIT is freely distributable. I have provided the source for M68 but you do not need the source code to run the program. It will run on just about any Alpha Micro system, even an AM-1000 running AMOS/L 1.2. (1.3D or up is needed for assembly from scratch.)
To install, simply copy KERMIT.LIT into SYS:. The documentation may be copied to HLP:KERMIT.HLP and accessed with HELP KERMIT.
The source code (written by our old friend Josh Hewitt when he was at Alpha Micro) is very instructive.
To install, simply copy ISOCD.LIT into SYS:.
To install, simply copy EGREP.LIT into SYS:. The documentation may be copied to HLP:EGREP.HLP and accessed with HELP EGREP.
This utility is somewhat buggy, but does decompile .RUN (compiled AlphaBASIC programs) back into .BAS equivalents. It doesn't always work, and doesn't work at all with AlphaBASIC Plus (let alone Lightning BASIC), but it's worth a shot if you've hosed your backup and haven't tried to be too obfuscatory. UNCMPL Q.RUN produces Q.SRC, or you could use something like UNCMPL Q.BAS=Q.RUN to specify a filename directly.
To install, simply copy UNCMPL.LIT into SYS:.