[HEADSUP] Let's start a Cygwin 1.7 release area
Wed Apr 23 09:27:00 GMT 2008
P?teris K?avi? wrote:
> So why can't the registry entry be <path-to-dll> instead of the fixed
> 'setup\rootdir' in order that the setup application could populate a
> drop-down list of all currently installed Cygwins?
It could. But I think Chuck made a good point that the ability to have
multiple installed copies extends to what you might call "expert users",
i.e. they must know the ins and outs of not actually ever using these
two installs at once. And so we need to be careful not to give the
impression that this is supposed to work in the general case.
> Maybe all cyg*.exe native Windows applications could use this same
> algorithm to compute their root.
cygcheck and strace are the only things that use the code in question,
and strace only uses it for the purpose of resolving the win32 filename
of the output file specified with -o.
> Would this problem go away if cygrunsrv.exe used the same algorithm to
> compute its root?
No, the problem is that the operating system's service configuration in
the registry needs the path to cygrunsrv.exe -- it needs to know the
path to the image to execute, and we of course have no control over
that. The only workaround I can think of to providing an absolute path
would be to use the REG_EXPAND_SZ key type's capability to expand
variables from the environment, e.g. %CygwinRoot%\bin\cygrunsrv.exe.
However, this doesn't really solve anything, it just shifts the problem
to making sure this variable is set. And even if you figured out a way
to do that, the change in environment would not take effect in the
services.exe process until the next time it was started, i.e. a reboot.
It would still be easier just to edit the service config after moving
> I have (finally) started using an environment where I share all my
> personal files on a separate disk drive accessible from all my bootable
> operating systems, whether it's Vista, WS2008, or Debian. The drive
> names (and mount points) vary. It's the same as moving install trees,
> and it would be nice if Cygwin didn't really care that when I started
> the services this time they were started from a different location than
> last time.
In this case the problem has nothing to do with any code in Cygwin. But
no I don't see your situation as the same, since as long as the location
is consistent on any given system, you can install the service once and
it will continue to be correct from there on.
More information about the Cygwin-apps