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

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

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.

Bottom line: I think it's a good idea to get real words in front of the
user like "You are running a 64-bit version of Windows.  Which version
of Cygwin would you like:".

First objection:  "Why should someone who is running a 32-bit version of
Windows be presented with this???  That's as confusing as clicking on
a web link!!!!!"

Response:  Don't present the option to people running on 32-bit systems.

Second objection:  "I don't want to see an extra dialog box every time I
run setup.exe (which is at least four times a day)!!!  I'm already driven
to near apoplexy by having the option to put a link on my desktop every
SINGLE time I run setup.exe"

Response: Have a "remember this choice for next time" check mark on the
dialog box so that you'd only be asked once.

Third objection:  "That would never work!  What if I change my mind????"

Response: Add a command-line option to setup.exe to force a download of an
arbitrary 64/32 bit version.  Update the FAQ with this information as well
as telling the user which registry entry (I think it would have to be a
registry entry) to use to change this behavior.

Fourth objection: "You're insane!!!  Now you're going to make it possible
for people to try to install 64-bit Cygwin on a 32-bit system!!!  I can
just imagine the mailing list screams!!!"

Response: Only allow downloading 64-bit to a 32-bit system.  Make sure
that the user knows that the 64-bit binaries will never work on their
system.  There is an added benefit here that a 32-bit user can download
stuff to their system for potential use by other

Fifth objection:  "This is a lot of work!!!  It's easier to just port setup.exe
to 64-bit!!!"

Response: That's debatable.  We know that converting to 64-bit is not
trivial.  Changes will require #ifdef's in the code.  It will require
that all mingw64 libraries be installed.  It will require installation
of the 64-bit cross compiler.  Every setup.exe release will require two
builds.

Six objection: "What?  You're already talking about complicating the code!!!
A few #ifdef's will be a minor annoyance.  And, anyone can install mingw
libraries.  It's easy!"

Response: Installing random mingw libraries is not really "easy" for me,
personally, on the linux setup that I have here.  It can be done.  I
know how to do it.  I'd rather not have to install and refresh multiple
libraries if I can avoid it.  And, the code complication should be
fairly modular rather than sprinkled throughout the source.

So, in summary, I think that a smart tool which tries to do the right
thing is, better than two similar tools requiring an end-user to make a
choice based on potentially limited knowledge about their system.

cgf