Darren New wrote:
> Eero Ahonen wrote:
>> And if two humans instead of two programs should read the data? :)
> 
> There's no reason that putting the file name in the registry 

Actually there is. For a humanbeing, especially Bart the Basic-user,
registry is a nasty place to crawl for that kind of information.

>(or an env var 

Yes, that could do it.

>or other config file) makes it less readable?

Even nastier than registry being somewhat cryptic for a humanbeing
(granted, it makes some sense while you're browsing it) is mixing that
registry and random config files around the filesystem.

> It's not automated, but you can code your program to follow the link if
> you want. 

Actually, that pretty much never is a problem. Usually (at least for me)
missing for symlinks is a problem with software that already exists (and
usually is somewhat stupidly done). I can't use shortcuts with such
software, because the shortcut is never named 'file', but 'file.lnk'
instead. I guess that in Windows-world the best way would be that I
could give those programs the name of the datafile eg. somewhere in
registry (as I asked and you preferred, IIUC), but even getting that to
work the software would need to be changed, which usually is not an option.

> (Granted, that's not usually the problem symlinks are used to
> solve, but it's not an awful solution for something like a playlist or a
> run queue (in the POV sense of the word). :-)  Think of the startup
> menu, for example, or the send-to menu.

There's surprisingly many things that are done with symlinks and
problems that are solved with them on *n?x, which leads to that there's
multiple other ways for not needing them in Windows -world, which leads
to the whine how useful they would be (and from time to time, they
would), if they were around as easily as on *n?x.

-Aero

Post a reply to this message