Eero Ahonen wrote:
> 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.

Well, obviously you give the user something other than regedit to edit the 
settings.

> 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.

Yep.

>> 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). 

Yep. That's why I said "it doesn't solve the problem symlinks solve."

> 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.

Yep.

> 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.

I've found relatively few good uses for symlinks other than "I have 
hardcoded paths that shouldn't have been".  That and "I want links from 
development trees to shared spaces".

Of course, when symlinks are ubiquitous and easy, people tend not to solve 
the problems that you can solve by symlinks. :-)

-- 
   Darren New, San Diego CA, USA (PST)
   My fortune cookie said, "You will soon be
   unable to read this, even at arm's length."

Post a reply to this message