Global 32/64 bit collision issues

Global 32/64 bit collision issues

[Corinna Vinschen]

Hi guys,


Yaakov brought this up in a private IRC conversation a couple of
weeks ago, but I dismissed it at the time.  But I guess we have to
discuss this.

Consider somebody has 32 and 64 bit Cygwin installed in parallel.  At
least for developers and package maintainers this won't be that
uncommon.  Now, they will run in parallel just fine, and most of our
packages don't do anything outside of the cygwin installation dir.

However, there are a couple of packages which change the system on a
global basis.  I see three groups here:

1. Packages installing shortcuts in the start menu and/or desktop
   (this includes setup itself).

   #1 types could be solved rather easily if we attach a "64" to all the
   created shortcuts.  But do we really want that, considering a setup
   for a "normal" user with only a single installation?  What are the
   trade-offs?

2. Packages installing services.

   #2 packages have a service name collision.  Obviously you can't
   install two services called "cron".  Should the package install its
   service under another name, again by just attaching a "64" to the
   service name?

   This would require to change the service installer scripts to check
   on what platform they are running and then attaching the "64" suffix
   if `uname -m' returns "x86_64".

   An alternative would be to change cygrunsrv so that the 64 bit
   version always attaches the "64" automatically.  While this is easy
   to accomplish, I see a problem here because the name change is not
   transparent to the user, nor to scripts.

   Having said that, the name change from "cron" to "cron64" is also
   kind of cumbersome.  Usually you only need one service, either the 32
   or the 64 bit version, but not both.  So, do we want the name change
   at all?

   But what about cygserver?  Without cygserver there's no XSI IPC.
   Even if we don't change the service names on a general basis,
   shouldn't cygserver at least be available in parallel, using
   different service names?

3. Packages installing network services.

   As for the #3 packages, they collide in another way as well since a
   service is usually connected with a default port.  Sshd is expected
   on port 22.  Telnet on port 23, smtp on port 25, etc.  I don't think
   it would be the right thing to move all 64 bit server to other ports
   by default.  I don't see any satisfactory way to install those
   services in parallel with a simple installer script, so I would keep
   this to the knowledgable user.  And here it might be even helpful
   that the service names already collide since it disallows to install
   two network services 


Right?  Wrong?  Neither right nor wrong?


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

Re: Global 32/64 bit collision issues

[marco atzeri]

Il 5/23/2013 10:44 AM, Corinna Vinschen ha scritto:
> Hi guys,
>
>
>
>     But what about cygserver?  Without cygserver there's no XSI IPC.
>     Even if we don't change the service names on a general basis,
>     shouldn't cygserver at least be available in parallel, using
>     different service names?

my experience with postgreSQL says that the two services are not 
interchangeable.
32 bit program fails with 64 cygserver


> Corinna

Marco

Re: Global 32/64 bit collision issues

[Corinna Vinschen]

On May 23 11:24, marco atzeri wrote:
> Il 5/23/2013 10:44 AM, Corinna Vinschen ha scritto:
> >Hi guys,
> >
> >
> >
> >    But what about cygserver?  Without cygserver there's no XSI IPC.
> >    Even if we don't change the service names on a general basis,
> >    shouldn't cygserver at least be available in parallel, using
> >    different service names?
> 
> my experience with postgreSQL says that the two services are not
> interchangeable.
> 32 bit program fails with 64 cygserver

Yes, of course, because cygserver is bound to the installation path
*and* there are no provisions in cygserver to handle processes of
different architecture.  Therefore my question...


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

Re: Global 32/64 bit collision issues

[Christopher Faylor]

On Thu, May 23, 2013 at 10:44:35AM +0200, Corinna Vinschen wrote:
>Hi guys,
>
>
>Yaakov brought this up in a private IRC conversation a couple of
>weeks ago, but I dismissed it at the time.  But I guess we have to
>discuss this.
>
>Consider somebody has 32 and 64 bit Cygwin installed in parallel.  At
>least for developers and package maintainers this won't be that
>uncommon.  Now, they will run in parallel just fine, and most of our
>packages don't do anything outside of the cygwin installation dir.
>
>However, there are a couple of packages which change the system on a
>global basis.  I see three groups here:
>
>1. Packages installing shortcuts in the start menu and/or desktop
>   (this includes setup itself).
>
>   #1 types could be solved rather easily if we attach a "64" to all the
>   created shortcuts.  But do we really want that, considering a setup
>   for a "normal" user with only a single installation?  What are the
>   trade-offs?
>
>2. Packages installing services.
>
>   #2 packages have a service name collision.  Obviously you can't
>   install two services called "cron".  Should the package install its
>   service under another name, again by just attaching a "64" to the
>   service name?
>
>   This would require to change the service installer scripts to check
>   on what platform they are running and then attaching the "64" suffix
>   if `uname -m' returns "x86_64".
>
>   An alternative would be to change cygrunsrv so that the 64 bit
>   version always attaches the "64" automatically.  While this is easy
>   to accomplish, I see a problem here because the name change is not
>   transparent to the user, nor to scripts.
>
>   Having said that, the name change from "cron" to "cron64" is also
>   kind of cumbersome.  Usually you only need one service, either the 32
>   or the 64 bit version, but not both.  So, do we want the name change
>   at all?
>
>   But what about cygserver?  Without cygserver there's no XSI IPC.
>   Even if we don't change the service names on a general basis,
>   shouldn't cygserver at least be available in parallel, using
>   different service names?
>
>3. Packages installing network services.
>
>   As for the #3 packages, they collide in another way as well since a
>   service is usually connected with a default port.  Sshd is expected
>   on port 22.  Telnet on port 23, smtp on port 25, etc.  I don't think
>   it would be the right thing to move all 64 bit server to other ports
>   by default.  I don't see any satisfactory way to install those
>   services in parallel with a simple installer script, so I would keep
>   this to the knowledgable user.  And here it might be even helpful
>   that the service names already collide since it disallows to install
>   two network services 
>
>
>Right?  Wrong?  Neither right nor wrong?

Some of this is has got to be "the user has to know what they're doing".

They obviously just *can't* install two different telnet or smtp servers,
any more than they could have both a windows telnet server and a cygwin
one.  They would have to choose.

For services, isn't there some other field besides just the name which
can be used as a delineator?

For shortcuts, I don't see anything wrong with adding a "Cygwin 64" to
the name.

Re: Global 32/64 bit collision issues

[Christopher Faylor]

I have to wonder: How do other packages with 32/64-bit binaries handle this?
Maybe Cygwin is unique but there might be other packages out there which also
have to deal with this.

Re: Global 32/64 bit collision issues

[Corinna Vinschen]

On May 23 11:01, Christopher Faylor wrote:
> On Thu, May 23, 2013 at 10:44:35AM +0200, Corinna Vinschen wrote:
> >Right?  Wrong?  Neither right nor wrong?
> 
> Some of this is has got to be "the user has to know what they're doing".
> 
> They obviously just *can't* install two different telnet or smtp servers,
> any more than they could have both a windows telnet server and a cygwin
> one.  They would have to choose.

Right.

> For services, isn't there some other field besides just the name which
> can be used as a delineator?

No.  Every service needs a unique service name, otherwise you couldn't
manipulate services unambiguously.

> For shortcuts, I don't see anything wrong with adding a "Cygwin 64" to
> the name.

Right now we have "Cygwin" and "Cygwin-X" folders in the start menu.
Maybe we should just change the subdir names to "Cygwin 64" and
"Cygwin-X 64", and otherwise stick to the shortcut names.

I think only setup creates a desktop shortcut.  Setup64 creates the
"Cygwin64 Terminal", so if we keep it this way we're off the hook, I guess.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

Re: Global 32/64 bit collision issues

[Yaakov (Cygwin/X)]

On 2013-05-23 10:19, Corinna Vinschen wrote:
> On May 23 11:01, Christopher Faylor wrote:
>> For services, isn't there some other field besides just the name which
>> can be used as a delineator?
>
> No.  Every service needs a unique service name, otherwise you couldn't
> manipulate services unambiguously.

Actually, both the service name and description need to be unique.


Yaakov

Re: Global 32/64 bit collision issues

[Yaakov (Cygwin/X)]

On 2013-05-23 03:44, Corinna Vinschen wrote:
> However, there are a couple of packages which change the system on a
> global basis.  I see three groups here:
[snip]
> 2. Packages installing services.
>
>     #2 packages have a service name collision.  Obviously you can't
>     install two services called "cron".  Should the package install its
>     service under another name, again by just attaching a "64" to the
>     service name?

cron may be a bad example; see below.

>     This would require to change the service installer scripts to check
>     on what platform they are running and then attaching the "64" suffix
>     if `uname -m' returns "x86_64".
>
>     An alternative would be to change cygrunsrv so that the 64 bit
>     version always attaches the "64" automatically.  While this is easy
>     to accomplish, I see a problem here because the name change is not
>     transparent to the user, nor to scripts.

I suggest changing the installer scripts, as duplicates do not make 
sense for all services.

>     Having said that, the name change from "cron" to "cron64" is also
>     kind of cumbersome.  Usually you only need one service, either the 32
>     or the 64 bit version, but not both.  So, do we want the name change
>     at all?

Some of these aren't so clear cut:

* cron
While due to the purpose it serves, one may suffice, only that crontabs 
must be configured within the same Cygwin root.  OTOH, that itself may 
depend on what people are putting in their crontabs in the first place.

* clamd
Provides either or both of local socket and TCP connections; the former 
is the default.  One will suffice for both if the network mode is (also) 
enabled.

Other "OS services" however, which are accessed only via local socket or 
the like, would need to be installed and running for both:

* messagebus (D-Bus system bus)
* avahi-daemon (uses messagebus)
* syslogd/syslog-ng
* and...

>     But what about cygserver?  Without cygserver there's no XSI IPC.
>     Even if we don't change the service names on a general basis,
>     shouldn't cygserver at least be available in parallel, using
>     different service names?

IMO yes.

> 3. Packages installing network services.
>
>     As for the #3 packages, they collide in another way as well since a
>     service is usually connected with a default port.  Sshd is expected
>     on port 22.  Telnet on port 23, smtp on port 25, etc.  I don't think
>     it would be the right thing to move all 64 bit server to other ports
>     by default.  I don't see any satisfactory way to install those
>     services in parallel with a simple installer script, so I would keep
>     this to the knowledgable user.  And here it might be even helpful
>     that the service names already collide since it disallows to install
>     two network services

Leaving these to collide makes sense IMO.


Yaakov

Re: Global 32/64 bit collision issues

[Corinna Vinschen]

On May 26 20:53, Yaakov (Cygwin/X) wrote:
> On 2013-05-23 10:19, Corinna Vinschen wrote:
> >On May 23 11:01, Christopher Faylor wrote:
> >>For services, isn't there some other field besides just the name which
> >>can be used as a delineator?
> >
> >No.  Every service needs a unique service name, otherwise you couldn't
> >manipulate services unambiguously.
> 
> Actually, both the service name and description need to be unique.

Well, that makes a sense in a morbid way...


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

Re: Global 32/64 bit collision issues

[Corinna Vinschen]

On May 26 21:29, Yaakov (Cygwin/X) wrote:
> On 2013-05-23 03:44, Corinna Vinschen wrote:
> >However, there are a couple of packages which change the system on a
> >global basis.  I see three groups here:
> [...]
> >    This would require to change the service installer scripts to check
> >    on what platform they are running and then attaching the "64" suffix
> >    if `uname -m' returns "x86_64".
> >
> >    An alternative would be to change cygrunsrv so that the 64 bit
> >    version always attaches the "64" automatically.  While this is easy
> >    to accomplish, I see a problem here because the name change is not
> >    transparent to the user, nor to scripts.
> 
> I suggest changing the installer scripts, as duplicates do not make
> sense for all services.
> 
> >    Having said that, the name change from "cron" to "cron64" is also
> >    kind of cumbersome.  Usually you only need one service, either the 32
> >    or the 64 bit version, but not both.  So, do we want the name change
> >    at all?
> 
> Some of these aren't so clear cut:
> 
> * cron
> While due to the purpose it serves, one may suffice, only that
> crontabs must be configured within the same Cygwin root.  OTOH, that
> itself may depend on what people are putting in their crontabs in
> the first place.
> 
> * clamd
> Provides either or both of local socket and TCP connections; the
> former is the default.  One will suffice for both if the network
> mode is (also) enabled.

Local socket won't work, unless you store the local socket outside
the cygwin install tree, something a default installer script should
not do or rely upon, IMHO.

> Other "OS services" however, which are accessed only via local
> socket or the like, would need to be installed and running for both:
> 
> * messagebus (D-Bus system bus)
> * avahi-daemon (uses messagebus)
> * syslogd/syslog-ng

I question that in terms of syslog-ng.  You always have the Windows
log.  Installing Syslog-ng is more fun than necessity, isn't it?


> * and...
> 
> >    But what about cygserver?  Without cygserver there's no XSI IPC.
> >    Even if we don't change the service names on a general basis,
> >    shouldn't cygserver at least be available in parallel, using
> >    different service names?
> 
> IMO yes.

I guessed.

I'm kind of cringing when thinking of a naming convention for the 64 bit
packages.  Not only that it looks weird in the service list:

  cron64
  clamd64
  sshd
  cygserver64

it's also a nuisance when starting/stopping the service.  You now longer
start the service, you start the service64, even if you don't have a 32
bit installation on that machine.  ANybody having a *good* idea for a
naming convention?

In the end, we want users to have only one installation, either 32 bit
or 64 bit, and the latter should be preferred on 64 bit machines anyway.
So I'm still wondering if we really should bother at all.  The only
"users" running both installations in parallel are maintainers and
Cygwin devs, isn't it?  And those, I trust, know what they are doing.
Is that too simple?


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

RE: Global 32/64 bit collision issues

[Karl M]

>>> But what about cygserver? Without cygserver there's no XSI IPC.
>>> Even if we don't change the service names on a general basis,
>>> shouldn't cygserver at least be available in parallel, using
>>> different service names?
>>
>> IMO yes.
>
> I guessed.
>
> I'm kind of cringing when thinking of a naming convention for the 64 bit
> packages. Not only that it looks weird in the service list:
>
> cron64
> clamd64
> sshd
> cygserver64
>
> it's also a nuisance when starting/stopping the service. You now longer
> start the service, you start the service64, even if you don't have a 32
> bit installation on that machine. ANybody having a *good* idea for a
> naming convention?
>
> In the end, we want users to have only one installation, either 32 bit
> or 64 bit, and the latter should be preferred on 64 bit machines anyway.
> So I'm still wondering if we really should bother at all. The only
> "users" running both installations in parallel are maintainers and
> Cygwin devs, isn't it? And those, I trust, know what they are doing.
> Is that too simple?
>
How about using an environment variable like CYGWIN32 and CYGWIN64 or CYGWIN32SUFFIX and CYGWIN64SUFFIX... and if they are defined they are used to adjust the corresponding default names by the scripts.

They could be created by setup if the user selects a side by side option during installation, or just manually set by the user.

Most folks would not need either defined. And they only set default names for the services etc.

...Karl 		 	   		  

Re: Global 32/64 bit collision issues

[Corinna Vinschen]

On May 27 06:39, Karl M wrote:
> >>> But what about cygserver? Without cygserver there's no XSI IPC.
> >>> Even if we don't change the service names on a general basis,
> >>> shouldn't cygserver at least be available in parallel, using
> >>> different service names?
> >>
> >> IMO yes.
> >
> > I guessed.
> >
> > I'm kind of cringing when thinking of a naming convention for the 64 bit
> > packages. Not only that it looks weird in the service list:
> >
> > cron64
> > clamd64
> > sshd
> > cygserver64
> >
> > it's also a nuisance when starting/stopping the service. You now longer
> > start the service, you start the service64, even if you don't have a 32
> > bit installation on that machine. ANybody having a *good* idea for a
> > naming convention?
> >
> > In the end, we want users to have only one installation, either 32 bit
> > or 64 bit, and the latter should be preferred on 64 bit machines anyway.
> > So I'm still wondering if we really should bother at all. The only
> > "users" running both installations in parallel are maintainers and
> > Cygwin devs, isn't it? And those, I trust, know what they are doing.
> > Is that too simple?
> >
> How about using an environment variable like CYGWIN32 and CYGWIN64 or CYGWIN32SUFFIX and CYGWIN64SUFFIX... and if they are defined they are used to adjust the corresponding default names by the scripts.

I'm not too keen on adding such environment vars.  An installer script
who's concerned about parallel installs could check the registry along
these lines:

- /proc/registry64/Wow6432Node exists?

  If not, just go ahead, we're on a 32 bit machine.

- uname -r is x86_64 AND /proc/registry64/Wow6432Node/Cygwin/setup/rootdir
  exists AND the directory given in that key exists?

  - We're in a 64 bit installation and there's a parallel 32 bit
    installation, so attach the string "64" to service name and description.

- uname -r is not x86_64 AND /proc/registry64/Cygwin/setup/rootdir
  exists AND the directory given in that key exists?

  - We-re in a 32 bit installation and there's a parallel 64 bit
    installation, so attach the string "32" to service name and description.

- Otherwise, just go ahead, we only have a single install.

In fact, csih could handle that transparently, I think.

The service names are still potentially nuisances, though.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

Re: Global 32/64 bit collision issues

[Herbert Stocker]

Hi all,

64 bit systems and software will soon become the normal thing and 32 bit
systems and software will be "old stuff". Therefore i would prefer not
to append '64' to 64 bit Cygwin, but to append '32' to 32 bit Cygwin.

Corinnas algorithm and Karls environment vars handle this very well. But
see below.

On 27.05.2013 16:33, Corinna Vinschen wrote:
>> How about using an environment variable like CYGWIN32 and CYGWIN64 or CYGWIN32SUFFIX and CYGWIN64SUFFIX... and if they are defined they are used to adjust the corresponding default names by the scripts.
> I'm not too keen on adding such environment vars.  An installer script
> who's concerned about parallel installs could check the registry along
> these lines:
>
> - /proc/registry64/Wow6432Node exists?
>
>    If not, just go ahead, we're on a 32 bit machine.
>
> - uname -r is x86_64 AND /proc/registry64/Wow6432Node/Cygwin/setup/rootdir
>    exists AND the directory given in that key exists?
>
>    - We're in a 64 bit installation and there's a parallel 32 bit
>      installation, so attach the string "64" to service name and description.
>
> - uname -r is not x86_64 AND /proc/registry64/Cygwin/setup/rootdir
>    exists AND the directory given in that key exists?
>
>    - We-re in a 32 bit installation and there's a parallel 64 bit
>      installation, so attach the string "32" to service name and description.
>
> - Otherwise, just go ahead, we only have a single install.
>
> In fact, csih could handle that transparently, I think.
>
> The service names are still potentially nuisances, though.

i like the algorithm, because:

a) i like symetry: If both Cygwins are installed, both have a suffix.

b) It has no suffix for users who install only one Cygwin.

But there is also a flaw:

Imagine a user who has only a 32 bit installation.
This algorithm would install the services without a '32' suffix.
-> correct
Then the user installs the 64 bit Cygwin, and now the scripts in the
32 bit Cygwin would try to access their services with the '32' suffix
appended.

Therefore some config setting that tells what to append seams
necessary, be it an environment variable or a registry setting.

If the user should not be bothered with such a setting at installation
time, the 64 bit setup could rename all 32 bit services and short cuts
to have the '32' suffixes. But users may need to adopt their self-made
scripts. Therefore leaving this setting to the user, seams best for me.

Herbert

Re: Global 32/64 bit collision issues

[Herbert Stocker]

On 28.05.2013 04:36, Herbert Stocker wrote:
> Therefore some config setting that tells what to append seams
> necessary, be it an environment variable or a registry setting.
>
> If the user should not be bothered with such a setting at installation
> time, the 64 bit setup could rename all 32 bit services and short cuts
> to have the '32' suffixes. But users may need to adopt their self-made
> scripts. Therefore leaving this setting to the user, seams best for me.

Sorry for posting twice, but this idea came too late:

How about using Corinnas algorithm at installation time and
storing the result (whether to append '32', '64' or nothing)
in the registry?
Then we have the automatism as well as consistency during the
life time of an installation.

Herbert

Re: Global 32/64 bit collision issues

[Corinna Vinschen]

On May 28 04:36, Herbert Stocker wrote:
> But there is also a flaw:
> 
> Imagine a user who has only a 32 bit installation.
> This algorithm would install the services without a '32' suffix.
> -> correct
> Then the user installs the 64 bit Cygwin, and now the scripts in the
> 32 bit Cygwin would try to access their services with the '32' suffix
> appended.
> 
> Therefore some config setting that tells what to append seams
> necessary, be it an environment variable or a registry setting.
> 
> If the user should not be bothered with such a setting at installation
> time, the 64 bit setup could rename all 32 bit services and short cuts
> to have the '32' suffixes.

You can't just rename services, that's kind of heavy-handed.  This is
also a functionality which doesn't belong in setup, really.  Also, how
does setup is supposed to know which Windows service is a Cygwin
service, a 32 bit service, and then, if it's a service being part of the
distro or created manually by the user?

> But users may need to adopt their self-made
> scripts. Therefore leaving this setting to the user, seams best for me.

Only distro services are supposed to do anything, *if* we decide to
do anything.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

32/64bit-improving cygrunsrv (was Re: Global 32/64 bit collision issues)

[Corinna Vinschen]

For a start, I just created a change to cygrunsrv.

Right now, when using the -L or -Q option, cygrunsrv prints
undiscriminately all services of all installations the same way:

  $ cygrunsrv -L
  cygserver
  sshd
  $ cygrunsrv -Q sshd -V
  Service             : sshd
  Display name        : CYGWIN sshd
  Current State       : Stopped
  Command             : /usr/sbin/sshd -D
  [...]

With my change, it also checks if the service is running *this*
cygrunsrv, or a cygrunsrv from another installation:

  $ cygrunsrv -L
  cygserver
  (sshd)

The service name is put into parens, if it's started by another cygrunsrv.
In case of the -V output, it's a bit more verbose:

  $ cygrunsrv -Q sshd -V
  Service             : sshd                (Installation path: C:\cygwin64)
  Display name        : CYGWIN sshd
  Current State       : Stopped
  Command             : /usr/sbin/sshd -D
  [...]

I'm not quite happy about the "Installation path" text, though.  It's
pretty clear to me what I mean, but is it clear enough for other users?

Maybe the -V output should always contain two more lines, installation
path and platform of the cygrunsrv starting the service, kind of like this:

  $ cygrunsrv -Q sshd -V
  Service             : sshd
  Installation path:  : C:\cygwin64
  Platform            : x86_64
  Display name        : CYGWIN sshd
  [...]

or even with an extra "not me", if it's another cygrunsrv and/or another
platform:

  $ cygrunsrv -Q sshd -V
  Service             : sshd
  Installation path:  : C:\cygwin64	(not me!)
  Platform            : x86_64		(not me!)
  Display name        : CYGWIN sshd
  [...]

What do you think?


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat