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

[Christopher Faylor <cgf-use-the-mailinglist-please at cygwin dot com>]

On Mon, Mar 04, 2013 at 11:32:36AM +0100, Corinna Vinschen wrote:
>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..."

There is no reason for a dialog box to be limited in what it says.  If
you want to put lots of words in front of the user then you can do it in
a dialog box or on the web page.

But, if you want people to see caveats you could still put words on the
web page around the "download setup.exe".

I made the point in the legacy discussion that I often just download
setup.exe to my system without reading any web page.  If I'm not the
only person in the thousands of downloaders who just runs
http://cygwin.com/setup.exe then anyone who does that will possibly not
even be aware that there is a 64-bit alternative.

>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.
>   [blah]
>   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.

I don't see why there would be major rewording needed, but if there is,
then I'm comfortable rerolling setup.exe and uploading it.  While it
isn't as simple as modifying a web page and typing "cvs commit", most of
my setup.exe building and uploading is fairly automated.

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

So you're advocating that the Cygwin web site should start using
javascript?  That sounds like an added complication/headache.  And, it
sounds like more work for me to figure out how to get this working.

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

WOW64 was optional in Windows 2008 R2.

http://msdn.microsoft.com/en-us/library/windows/desktop/dd371790%28v=vs.85%29.aspx

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

I think it is "professional" to provide information to the user at
install time.  But the word "professional" is really not something that
can be argued.

"*that* much work" is a straw man.  I never said it was "work" to upload
two different setup.exe's.  My building and uploading is all automated
so I could easily do this.

>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 is another straw man.  We're talking about a program here.  It can
make decisions based on the name of its argv[0] or with my previously
proposed command line arguments.  So, if you name setup.exe ->
setup64.exe (which you apparently want to do anyway) it could default to
the 64-bit distro.  Or, it could display a dialog box listing the paths
to the installation and ask which you want.  Or both.

I'd be ok with a compromise of having two versions of setup.exe
available where something named setup64.exe defaulted to installing the
64-bit version and something named setup.exe defaulted to installing the
32-bit version.  But I'd like the Cygwin installer to be capable of
installing (or download only when pulling down 64-bit to a 32-bit
system) either and for it to have as much information available as
possible to inform the user as to their choice.

I think that putting the decisions at the point of installation will
make it more likely that people will try out the 64-bit version,
especially if we allow (and we should allow) dual installation.

cgf