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
