This is the mail archive of the cygwin-apps mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] setup: port to 64-bit, part 1

On Mar  4 02:09, Christopher Faylor wrote:
> On Sun, Mar 03, 2013 at 08:39:45PM +0100, Corinna Vinschen wrote:
> >On Mar  3 12:52, Christopher Faylor wrote:
> >> On Sun, Mar 03, 2013 at 12:23:44PM -0500, Christopher Faylor wrote:
> >> >On Sun, Mar 03, 2013 at 10:46:38AM +0100, Corinna Vinschen wrote:
> >> >>On Mar  3 00:46, Yaakov (Cygwin/X) wrote:
> >> >>> This patch fixes the remaining issues, *except in autoload.c*, for a
> >> >>> 64bit setup.exe.  Some notes:
> >> >>> 
> >> >>> 1) This assumes that 64bit .ini will be named setup64.ini.
> >> >>> 
> >> >>> 2) This also assumes that 64bit setup will only install 64bit packages
> >> >>> (IOW only use setup64.ini, regardless of argv[0])
> >> >>> 
> >> >>> 3) The resulting binary is still named setup.exe, but we'll want to
> >> >>> provide this for download as e.g. setup64.exe.  It would be up to
> >> >>> whomever (cgf?) to rename this upon uploading.  Alternatively, the
> >> >>> buildsystem could be patched to change the executable name based on
> >> >>> $host_cpu.
> >> >>
> >> >>It would be helpful if the build system would already care for that.
> >> >
> >> >Why are we porting setup.exe to 64-bit?  It doesn't seem like there are
> >> >any benefits.  There is no reason to have two versions that I can see,
> >> >although we will likely want to modify the current setup to choose
> >> >between the two.
> >> >
> >> >I'd rather just have one setup.exe which gave you the choice to install
> >> >either (or both) distros at install time than to have to clutter the
> >> >web site with "If you're installing 64-bit click here, if you're installing
> >> >32-bit click here".
> >> >
> >> >We could, of course, add code to make sure that someone isn't installing
> >> >the 64-bit code on a 32-bit system.
> >> 
> >> Since I foresee a debate about this issue, similar to the initial legacy
> >> 1.5 decision, I am going to offer more rationale for why I think it's a
> >> good idea and offer counter arguments to the points that will probably
> >> still be raised regardless.
> >
> >First, since this is plain opinion-based,
> "rationale" != "fact" but I at least tried to offer explanations for why
> I have my "opinion".
> >I think it's easier to present the choice on the web page rather than
> >in setup.  The name of the tool, setup64, is a wonderful clue as to
> >what this version installs.

Granted, I didn't spend much time on my reply yesterday.

My reason to like a web-supported/devided installer solution is this.
The room you have available, a web page can be much more informativ than
a dialog in the installer.  You can explain a bit more detailed what's
going on, along the lines of

  "if you are running a 64 bit version of windows..."
  "You have the choice ..." 
  "When do you want ot use this or that version..."
  "If in doubt..."

and especially at the early stage of the 64 bit distro:

  "The 64 bit distro is not yet as feature-complete as the 32 bit distro
   because it's very new.
   If you need certain functionality, install the 32 bit version for now"

etc, etc.  The latter point is quite important, I think.  Yes, sure, you
can talk about that in the FAQ, but most people will only read it after
they already installed something, which we can spare (some of) them, if
we already present the information on the page they download their
installer from.  And I have kind of a neat picture in mind with two
setup links side by side.

A web based solution is also easier to change.  If it turns out that the
information we give to the users is bad, wrong, too short, too dumb, we
can easily change the web page.  Having to patch the installer and to
reinstall them just to change the information provided to the user
sounds rather awkward.

> It's likely easier for a programmer to pepper setup.exe with rote
> changes for x86_64 than to add logic to detect the OS and offer the user
> choices.  I don't think it can be argued that it's easier for the user
> since, if setup.exe is modified, they will still be presented with the a
> similar choice but they will know exactly what their options are.
> I think it is very possible that some users will not know if they are
> running a 64-bit OS or not.  I, myself, have been confused on both Linux
> and Windows when I had a 32-bit OS installed but thought I was running
> 64-bit.

The web page itself can check the version of the client OS and tell the

> >Second, you're missing an important point: WOW64 has become an optional
> >component since Windows 2012.  Requiring to have WOW64 installed just
> >because we neglected to port the installer as well, is lame.  At the
> >very least we should provide a 64 bit installer as well, even if it's
> >not used by default.
> I was vaguely aware of this but I don't believe that it is common.  I
> searched for "cygwin wow64 missing" and didn't see anything.

Windows 2012 is very new.  Just because there isn't much information
available on the net doesn't mean the machines don't already exist.  You
don't read that much about server installation on the net as you read
about client installations.  we should not neglect this scenario,
especially since it doesn't cost as anything.

It will also spread.  windows 2008 R2 was the first Windows only
available as a 64 bit OS.  It's successor, Windows 2012 is the first OS
with WOW64 being an optional, but by default instalkled component.  It's
successor, Windows 2012 R2 is probably the first OS with WOW64 being
optional, but not being installed by default anymore.  The next step is
easy to augur.

> If we start to see a number of people complaining then I would be
> certainly be convinced that a 64-bit setup.exe is needed.  I don't think
> we have to limit ourselves out of the gate for this, in my opinion,

Limit?  Being able to provide a 64 bit installer for a 64 bit distro is
not "limiting" ourselves, it free's us.  It allows to support even the
(yet) corner cases.  It's the professional thing to do and, again, it
doesn't cost us anything.  It's not *that* much work to build two new
setup versions and upload them.  We have to do for each new package in
the distro in future anyway.

And there's another point which speaks for using a 64 bit installer for
the 64 bit distro.  32 and 64 bit tools partially use different registry
keys.   For instamce, the installation key of the 64 bit installation
will be stored in HKLM/Software/Cygwin, the 32 bit installer installs
its setup key into HKLM/Software/Wow6432Node/Cygwin.

And what if a user would like to have 32 and 64 bit installations
installed in parallel?  I, for one, will have to do that.  With distinct
32 and 64 bit installers, updating the two distros is easy.  I simply
start both of them, click through to the chooser page and update.  With
a single 32 bit setup, I would only have one "current" installation in
HKLM/Software/Wow6432Node/Cygwin/setup, and updating that is easy.  But
then I have to restart setup and change the path in the root dir window.
Every time anew.  And that I will have to do for all my 64 bit test
machines.  This is not amusing.

This may or may not be also a good reason to change the default
installation path for the 64 bit distro.  Maybe it should use
C:\cygwin64 rather than C:\cygwin, so that installing both distros in
parallel is as simple as dirt.  But I think I don't have a strong
opinion on that.


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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]