Phil Nelson wrote:
 > Hello,
 >
 >
 >> When I tried this, I saw that I did not have a cygwin.dll, but a
 >> cygwin1.dll. A simple renaming of the file was sufficient to get
 >> the system running.

Renaming the cygwin dll is garantied to break cygwin so don't bother
reporting problems on the cygwin list. If your installation is linked
against a cygwin.dll (I'll rather suppose the cygwin.dll and not
cygwin1.dll is a typo in your reference) then it should be recompiled
with a "modern" cygwin installation.
 >
 >
 > This must explain why the distribution no longer works.  The
 > installation tried to copy cygwin.dll to the proper place.  For some
 > reason, a

Having two copies of the cygwin dll is garantied to break cygwin when
the cygwin dll is updated (setup.exe will only update /bin/cygwin1.dll
as it doesn't know about the other copy).

 > symbolic link didn't work.  I'm sure there should be a better way to

As the dll loading is done by Windows so it has to be a real file (a 
hard link would have worked). For symbolic links to work cygwin would 
have to implement its own dll loader stub with enough cygwin path 
handling functionality and link that staticly to every exe and dll. It's 
not considered worth the trouble.

 > get that done, but I haven't found it yet.  I'm sure there is some
 > registry entry ......

Yes, those thinks exists and are documented somewhere in the cygwin
archives. But why not let init (it has just been added to the cygwin
distribution this month) do it for the desired run level?
 >
 > I'll check this out and change the installation to deal with the
 > current name of the cygwin dll.

The cygwin dll name (cygwin1.dll) has not changed in years now. This 
should not be necessary for a program expected to work with a 2002 
version of cygwin1.dll.

I just had a quick look at venus-setup and coda-setup-ports. The
/cygdrive prefix can be changed now (too many people hated it) it's
get the system32 path.
 >
 > Thanks.
 >
 > --Phil
 >
 >


-- 
Med venlig hilsen / Kind regards