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

Corinna Vinschen corinna-cygwin@cygwin.com
Mon Mar 4 16:53:00 GMT 2013


On Mar  4 11:10, Christopher Faylor wrote:
> On Mon, Mar 04, 2013 at 11:32:36AM +0100, Corinna Vinschen wrote:
> >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.

Except that the changes aren't there and S still HTDI.  Changing a web
page is easier.

> >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?

No.  I'm no web designer, I don't know what's required to let the web
site print a client version string.  I assume there are also perl or
python cgi scripts available on the net.

> >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

Ok, but only on Core.  Now it's also optional in the GUI version
and can be simply removed from the Server "Features" list.

> >> 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.

Hmm.  The HKLM/Software/Wow6432Node/Cygwin/setup key only contains
a single path.  You would have to add a new registry item or better,
you default to HKLM/Software/Cygwin/setup when running as setup64.

> Or, it could display a dialog box listing the paths
> to the installation and ask which you want.  Or both.

Oh please, not another dialog...

Dunno about "straw man" arguments or not, I'm just trying to bring up
the arguments which concern me.

Here's another one:  How do you make sure that nobody overwrites a 32
bit installation with 64 bit packages and vice versa from setup by
accident?

> 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.

So, C:\cygwin64?

Still, SHTDI, and it sounds like much more work than adding some text to
the web page.

Anyway, I said it in my previous mail already:  At least let us provide
a 64 bit setup on the web site.  The code is in place, it doesn't hurt.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat



More information about the Cygwin-apps mailing list