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
