This is the mail archive of the cygwin-apps mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

Microsoft has a KB article:

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]