blog.erik.rainey.name

As I'm playing around with layout and links on my active desktop page, I'm finding that support for launching apps or content out of HTML files is...limited to put it kindly. Currently there are two ways to solve this problem.

Your choices are:
• File Type Associations via file: URL Protocol Handler
• New URL Protocol Handlers, like ssh:hostname

Both of these have problems.

File Associations: These are standard extensions to the file type model of Windows. In this method you simply put your link in your HTML file as a file: link. The system figures out which app to launch for that type and does so.

<a target="_top" href="file:C:\myfile.txt">My File</a>

With this method, you have to have a pre-existing type association for .txt files, which is very common, so you're probably good. In fact this is great for any type of content editing. If you have a file you commonly edit and a known editor, this is great. This model breaks however whenever you want a application to behave in a certain way though. Let's say that you want to open a command window in a certain directory. Well, you can't do it directly in the HTML file. You'll have to have a secondary .bat or .cmd file which does the path change and any other default actions. This is where URL Protocol Handlers come in. If you install a special URL protocol for command windows like "cmdshell:". Then you can stipulate the path that you'd like to open directly in your HTML file.

<a target="_top" href="cmdshell:C:\TEMP">CMD in C:\TEMP</a>

Cool, huh? Turns out there are a few default URL protocol handlers for windows which make life easier. They are:

• http(s): Web pages.
• ftp: FTP sites.
• gopher: Gopher Sites (if you know what that means)
• file: The standard file "open" method.
• telnet: Opens your default telnet app and connects you to the client which was the parameter.

I've since added:

• ssh:hostname - The Secure Shell connection
• cmdshell:dir - Open a command window in the provided directory.
• vnc:hostname - Open a VNC connection to the host.
• ue:file - Force an open with UltraEdit.
• google:search - Query Google with the provided term.

The problem with the URL Protocol method is that none of the programs I use to run these functions understand the URL protocol stream invocation. See, when you invoke a URL protocol stream it's passed to the program like this (in the ssh: example): putty.exe ssh:hostname This won't do, of course. (Putty incidently understands telnet: but not ssh: in the version I have.) In order to solve this problem I've create a utility which is able to remove the URL Protocol type and pass the parameter on to the destination app. The next problem is that if you are using this method and create your own URL Protocol handlers, explorer.exe still wants to open them as files (probably due to some old security work around) and will complain that it can't open "ssh:hostname", even though the utility I wrote worked fine.

Now you could try to solve this problem by using file types and the file: URL and create a custom type which when launched acheives the same end goal as the URL protocol handler. This is tricky and will probably require another custom cmd file or app.

Once I have the utility running (without that dang popup) I'll post a link to the source and the registry edits you'll have to make in order for it to work.

If you're an SSH tunneler like myself, you know that you can't use RDP with a tunnel reflected off yourself (localhost). I just figured out how to do this. Though, it's rather simple and I'm somewhat ashamed that I didn't think of it before. Just add a line to your C:\Windows\system32\drivers\etc\hosts file. 127.0.0.1 me I then used an SSH tunnel to redirect the port number as well. ssh ... -L 3390:192.168.0.85:3389 ... This will redirect port 3390 to the RDP port, 3389. Now connect to me:3390 for RDP.