public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
From: Corinna Vinschen <corinna-cygwin@cygwin.com>
To: cygwin@cygwin.com
Subject: Re: Cygwin-64 on W10-64 : the only game in town?
Date: Mon, 2 Nov 2020 10:13:07 +0100	[thread overview]
Message-ID: <20201102091307.GA33165@calimero.vinschen.de> (raw)
In-Reply-To: <DB6PR03MB3013DBA0036A6A7F77F90A0BA4130@DB6PR03MB3013.eurprd03.prod.outlook.com>

On Nov  1 08:49, Fergus Daly via Cygwin wrote:
> With W7 no longer supported, W10-32 supported but no longer provided
> on new machines (Microsoft states that, "Beginning with Windows 10,
> version 2004, all new Windows 10 systems will be required to use
> 64-bit builds and Microsoft will no longer release 32-bit builds for
> OEM distribution .. the weaker version of Windows 10 has several
> limitations, like capping out at 3.2GB of RAM and less stringent
> security measures") and the functionality of Cygwin-32 significantly
> downplayed on Cygwin's own Home page, that really does leave Cygwin-64
> on W10-64 on 64-bit hardware as the sole recommended platform. Yes?

Cygwin still runs on 32 bit and Windows versions down to Vista.

However, since you're asking for a recommendation, some points:

- The limited virtual address space of 32 bit processes is getting
  a big problem for a long time now.  The more packages and the more
  DLLs the distro delivers, the less manageable the situation gets
  on 32 bit machines.  This includes WOW64 on 64 bit.

- time_t on 32 bit is 32 bit.  The effort to change that is not
  managable, and it's not worth it, given that usage of 32 bit
  systems (including WOW64) is at less than 5%, and dropping.

- Newer Cygwin features are partially unavailable (usually faked) on
  older Window versions due to missing API calls.

- Cygwin running on Vista is not going away any time soon.  The extra
  code required to support Vista (and W7, fwiw) is just a drop in the
  bucket, and ripping it out doesn't simplify the code noticably, as for
  XP.

- The same can't be said for 32 bit.  There's a lot of code involved,
  partially assembler code.  Getting rid of that code is really
  an option at one point, what with Windows dropping 32 bit support...

- Older Windows versions are increasingly getting insecure with
  Microsoft stopping updates.

- Windows 10 is not exactly privacy-minded...


Corinna

      parent reply	other threads:[~2020-11-02  9:13 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-01  8:49 Fergus Daly
2020-11-01  9:00 ` Duncan Roe
2020-11-01 11:23   ` Hamish McIntyre-Bhatty
2020-11-01 15:20   ` Stephen John Smoogen
2020-11-01 16:51     ` Brian Inglis
2020-11-02  9:13 ` Corinna Vinschen [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20201102091307.GA33165@calimero.vinschen.de \
    --to=corinna-cygwin@cygwin.com \
    --cc=cygwin@cygwin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).