This is the mail archive of the
cygwin-apps
mailing list for the Cygwin project.
Re: [PATCH] setup: port to 64-bit, part 1
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.
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.
Microsoft has a KB article:
http://support.microsoft.com/kb/827218
to help users who don't know what they are running.
I googled for "windows 32 and 64 which one" to see if this was a
common subject. It does seem to get asked a lot.
>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.
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,
corner case.
>>Fifth objection: "This is a lot of work!!! It's easier to just port
>>setup.exe to 64-bit!!!"
>>
>>Response: That's debatable.
>
>Yaakov already ported setup to 64 bit. Only the autoload stuff is
>missing and that can simply be deleted anyway.
Ok, I thought there were more patches coming. If the #ifdef x86_64's in
Yaakov's code are actually not going to be there because of legacy going
away then those points are invalid.
Btw, Yaakov, IsWindowsNT in the code should be completely eliminated.
cgf