LinLog

There are many days when I think that Windows really isn't all that bad. Then there are days like today.

I was trying to write a simple, graphical wrapper around some configuration scripts today. Nothing fancy - just copy a couple files, write and merge a few registry files, and make a shortcut. I'm doing it in Visual Basic 6, because we're "standardized" on Visual Basic and VB.NET is out of the question because I need this to run without any installation on Windows NT 4 SP6 up to Windows XP. Pretty much the only purpose of this program is to help configure a software package that we're distributing to people who think that the big blue "E" on their desktop is "the internet," so requiring an installation for the configuration program would kind of defeat the purpose. Anyway, I got almost the whole thing done in an afternoon. The only hard part was reminding myself how Visual Basic's built-in file access functions work, because I always use the Microsoft scripting runtime.

Then I remembered that I needed to create a shortcut programmatically, since the path will be different on different networks. I figured this would be pretty easy - just get out my trusty Win32 API reference and I'll be done in a couple of minutes. Windows shortcut files (also known as "shell links") are pretty common, so there must be an API call to make them, right?

Well, apparently not. It turns out that it's surprisingly complicated to make a shell link in Windows. The most common solution was to use the Windows Script Host, but that didn't work on my test NT4 system. I also found a few very confusing references to using the SHFileOperation API call to copy the file to the "Recent Files" directory and then to your destination directory, but that didn't seem to work on my development XP system. Eventually, I found some posts on working with shortcuts using the COM (or OLE, or whatever the hell they were calling it at the time) interface to the shell32.dll library. It was either that, or call the same functions directly through API declares, which would have been very ugly. Of course, by the time I figured this out, I had to go to a meeting, so I didn't actually get it working.

What I'd like to know is why couldn't Window shell link files be as nice as GNOME and KDE desktop files? Windows links are (relatively) big binary files that, in most cases, only store a two or three pieces of useful information. KDE desktop files, on the other hand, do basically the same thing, but are plain text and can fit in ten lines. You don't even need a library to write desktop files - you can do it by hand if you want to. Why can't it be that simple in Windows?