date:20211027

On Wed, Oct 27, 2021 at 11:37:26AM +0200, Thomas Wolff wrote:

Greetings, Thomas,

> Am 27.10.2021 um 10:49 schrieb Corinna Vinschen via Cygwin:
> > On Oct 27 09:24, Takashi Yano via Cygwin wrote:
> > > On Tue, 26 Oct 2021 22:55:01 +0200
> > > Corinna Vinschen wrote:
> > > > We're also planning to drop Support for the 32 bit release of Cygwin in
> > > > 2022, thus Cygwin 3.4.0 won't come in 32 bit anymore, and the package
> > > > maintainers won't have to update 32 bit packages anymore.  If you're
> > > > still running Cygwin under WOW64, consider to move to 64 bit in the next
> > > > couple of months.
> > > I agree with you that 32 bit cygwin under WOW64 is not worth to
> > > support any more. However, 32 bit version of Windows 10 will be
> > > still supported at least until Oct. 2025. Personally, I think it
> > > would not be nice to exclude the supported windows version from
> > > cygwin support.
> > Well, it's not much effort to support WOW64 if we support 32 bit anyway.
> > The problem is that Cygwin is somehow outgrowing 32 bit systems in terms
> > of the available memory.  Also, 32 bit Cygwin is still using a 32 bit
> > time_t, https://en.wikipedia.org/wiki/Year_2038_problem
> > 
> > Per the download statistics, as far as those statistics are trustable,
> > 32 bit systems are less than 5% of the installed base, with the majority
> > of them being WOW64 installations.  Those can move over to 64 bit Cygwin
> > easily.
> > 
> > Less than 1% are real 32 bit systems.
> I think roughly 1% is still a community to consider. Working old machines
> shouldn't be trashed just because they are missing a few bits :)
> 
> > Dropping 32 bit support will reduce code complexity in Cygwin and it will
> > reduce the workload of the package maintainers.
> Code complexity was also an argument when dropping XP support, but there was
> quite some discussion at its time.
> For `egrep "# *if.*(32|64)"` I'm counting roughly 160 matches in winsup, but
> only in a few files. Is it really necessary?
> 
> > Those few still running
> > Cygwin on a real 32 bit system will still have a chance to run Cygwin
> > by utilizing Peter's time machine.
> 
> Peter's time machine is a very appreciable effort. It's a bit fiddly though 
> to figure out how to use it, particularly to identify the "latest XP 
> version". Maybe some explicit howto could be published on the cygwin pages?

Could you please give an example of the "fiddly" bit?  I list the URLs
to use with the install and it's clearly labeled "The last version of
Cygwin that supports XP is 2.5.2-1".  Or were you, perhaps, refering to
the actual usage of the URL in the Setup program?

Another user, Michel, responded that perhaps a more explicit message
with exact steps for install this might be helpful (as the "Dead Simple
Instructions" are generic), but I'm not sure it's really necessary.  Is
that, perhaps, what you are refering to in that the instructions aren't
explicit enough?

> Thomas
> 
> 
> -- 
> Problem reports:  https://cygwin.com/problems.html
> FAQ:  https://cygwin.com/faq/
> Documentation:https://cygwin.com/docs.html
> Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

-- 
--=> Peter A. Castro
Email: doctor at fruitbat dot org / Peter dot Castro at oracle dot com
"Cats are just autistic Dogs" -- Dr. Tony Attwood

-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: EXTERNAL: Re: [HEADSUP] Phasing out old Windows versions and 32 bit support

2021-10-27 Thread Damon Register via Cygwin


On 10/27/2021 11:25 AM, Jim Reisert AD1C wrote:

On Tue, Oct 26, 2021 at 2:55 PM Corinna Vinschen wrote:


The upcoming version 3.3.0 is the last version officially supporting
Windows Vista and Windows Server 2008.

The next major release 3.4.0 will be released in 2022 and will be the
last one officially supporting Windows 7, Windows 8, Windows Server 2008
R2, and Windows Server 2012.

We're also planning to drop Support for the 32 bit release of Cygwin in
2022


This is all good.  I really appreciate all the developer's efforts
with Cygwin.  There are thousands of ham radio operators all over the
world who would not be getting data file updates without this
software!

I am not sure that I follow this.  Are you saying that amateur radio
users will be fine with the loss of old Windows support?  The
appreciation is a general thanks for all that Cygwin developers
do or is it a hint that you hope they don't drop old Windows?

If it is the hope that old Windows isn't dropped, then it makes
me smile a little.  Now that I am in amateur radio, I see that
it is an expensive hobby and a new computer is a small cost
compared to the radio equipment

Damon Register
KK4OFV

--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: gcc 11 weird bug



Am 27.10.2021 um 20:52 schrieb Thomas Wolff:


Am 27.10.2021 um 12:55 schrieb Hannes Domani:
  Am Mittwoch, 27. Oktober 2021, 11:19:19 MESZ hat Thomas Wolff 
 Folgendes geschrieben:



I noticed that mintty did not compile anymore after upgrade to gcc 11,
but only on cygwin 32-bit.
I tried to minimize the test case as much as possible without having 
the

bug vanish, to the attached standalone file.
Compile this with
cc -O2 -Wall -Werror m0.c
and it gives a false positive warning about possible uninitialized data
usage.
While data flow analysis is not perfect, it is weird that this used to
happen on 32 bit but not on 64 bit.
Meanwhile, after updating some other packages (not sure which), but
still the same gcc version, the report on the test case also happens on
64 bit, while the original, unstripped file, as part of mintty, still
works without error on 64 bit, which is even weirder.
I have not yet had the opportunity to test this on Linux, sorry, so I'm
reporting it here.
Thomas

If you mean this warning:

m0.c: In function 'do_bidi':
m0.c:256:12: error: '*types[0]' may be used uninitialized 
[-Werror=maybe-uninitialized]


This warning is correct, because as far as gcc is concerned, count could
be 0, and in this case types[0] will be uninitialized (and doesn't even
exist, since it's declared as 'uchar types[count];').
Thanks for the hint. I acknowledge that the analyser cannot know that 
count > 0 here. But if types[0] exists, it cannot be unitialized so 
the wording of the warning is not correct in this case. Anyway, this 
leads to a less obtrusive workaround than the current one.
And, forgot to mention, it's still mysterious how the distinction 
32bit/64bit makes a difference about the warning to occur.

Kind regards
Thomas

--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: [HEADSUP] Phasing out old Windows versions and 32 bit support

On Wed, Oct 27, 2021 at 10:53:58AM +0200, Cygwin List wrote:

Greetings, Corinna,

> On Oct 26 21:29, Peter A. Castro wrote:
> > On Tue, Oct 26, 2021 at 06:52:02PM -0400, Michel LaBarre wrote:
> > 
> > Greetings, Michel & Corinna,
> > 
> > > Corinna , thank you for the heads up regarding subsequent updates wrt 
> > > Window
> > > 7.
> > > 
> > > Would it be possible to create a short "how-to" for installing the most
> > > recently "known-to-work-with-Windows-7" version of Cygwin (presuming that
> > > old versions remain accessible indefinitely...).  Alternately, how one can
> > > download a repository now that is compatible with Windows 7 and useable 
> > > for
> > > installing Cygwin in anticipation of the upcoming loss of support.
> > 
> > As these milestones occur I will make notes in the Cygwin Time Machine
> > concerning the ending release snapshot and installers, like what I have
> > for the last XP release.
> > 
> > Corinna, I presume you will post when these milestones occur so that we
> > have a more exact message in the Cygwin mail archive?
> 
> In which way do you mean?  My planning was this:
> 
> When I release 3.3.0 (next couple of days), I will add a note to the
> announcement that this is the last major release supporting Vista and
> Server 2008.
> 
> When I release 3.4.0 (in some nebular future of 2022), I will add a
> note to the announcement that this version does not support Vista and
> 2008 anymore, and that 3.4.0 is the last version supporting
> W7, 8, 2008R2, 2012.
> 
> That ok?  Or do you think of somehting else?

That works.  I'll note the email message for those announcements, like
I've done for the XP finale, and provide direct circa links and a copy
of the installer.

> Oh, that reminds me... I should have sent the headsup to cygwin-announce,
> not to the cygwin ML.  I will fix this omission immediately...
> 
> 
> Thanks,
> Corinna
> 
> -- 
> Problem reports:  https://cygwin.com/problems.html
> FAQ:  https://cygwin.com/faq/
> Documentation:https://cygwin.com/docs.html
> Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

-- 
--=> Peter A. Castro
Email: doctor at fruitbat dot org / Peter dot Castro at oracle dot com
"Cats are just autistic Dogs" -- Dr. Tony Attwood

-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: [HEADSUP] Phasing out old Windows versions and 32 bit support

On Wed, Oct 27, 2021 at 10:57:00AM -0400, Michel LaBarre wrote:

Greetings, Michel,

> > > Would it be possible to create a short "how-to" for installing the most
> > > recently "known-to-work-with-Windows-7" version of Cygwin (presuming
> that
> > > old versions remain accessible indefinitely...).  Alternately, how one
> can
> > > download a repository now that is compatible with Windows 7 and useable
> for
> > > installing Cygwin in anticipation of the upcoming loss of support.
> > 
> > As these milestones occur I will make notes in the Cygwin Time Machine
> > concerning the ending release snapshot and installers, like what I have
> 
> > for the last XP release.
> [Michel LaBarre] 
> 
> Peter, thanks for reminding me of the Time Machine.  I had heard of it but
> never had occasion to use it.
>
> If I understand the "dead simple instructions" correctly, to install the
> latest XP-compatible 64-bit Cygwin for example, I would run (on an XP
> system):
> 
>   setup-x86_64-2.874.exe
> http://ctm.crouchingtigerhiddenfruitbat.org/pub/cygwin/circa/64bit/2016/08/3
> 0/104235 -X
> 
> and all the correct packages would be presented in the setup GUI and fetched
> from your archive.

That is correct.

> And I could re-run the same command to install additional packages.

That is also correct.
If you have any issues, please contact me (the Time Machine page lists
my contact at the bottom).  I'm usually pretty responsive.

I will note that doing an install of *everything* isn't exactly a good
idea, because there are packages that overlap and conflict somewhat.  I
usually advice people to install just what they need rather than the
entire enchilada.  You can always install more later.

> If that is the correct, perhaps in the case of iconic last-versions
> (XP,Win7,...), you might explicitly list "deader simpler instructions" with
> the actual setup invocations referring to the correct archives. 

The DSI are pretty generic, I agree, but armed with the update of the
URLs to use and the installer link, I'm not sure an additional
clarification is really necessary.  But, give it a try and if you feel
something more clear is really needed, I'll see about adding some
verbage.

> (Thanks in advance - the time machine is huge service.)

Hopefully it is of use to people.  :)

> > Problem reports:  https://cygwin.com/problems.html
> > FAQ:  https://cygwin.com/faq/
> > Documentation:https://cygwin.com/docs.html
> > Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

-- 
--=> Peter A. Castro
Email: doctor at fruitbat dot org / Peter dot Castro at oracle dot com
"Cats are just autistic Dogs" -- Dr. Tony Attwood

-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: [HEADSUP] Phasing out old Windows versions and 32 bit support

2021-10-27 Thread Jeremy Drake via Cygwin

Oops, forgot to send to list.

On Wed, 27 Oct 2021, Takashi Yano wrote:

> On Tue, 26 Oct 2021 22:55:01 +0200
> Corinna Vinschen wrote:
> > We're also planning to drop Support for the 32 bit release of Cygwin in
> > 2022, thus Cygwin 3.4.0 won't come in 32 bit anymore, and the package
> > maintainers won't have to update 32 bit packages anymore.  If you're
> > still running Cygwin under WOW64, consider to move to 64 bit in the next
> > couple of months.
>
> I agree with you that 32 bit cygwin under WOW64 is not worth to
> support any more. However, 32 bit version of Windows 10 will be
> still supported at least until Oct. 2025. Personally, I think it
> would not be nice to exclude the supported windows version from
> cygwin support.

Please also note that Windows on ARM64 only just got the ability to run
x86_64 binaries in Windows 11.  Previously the only option was 32-bit
x86, as there is no native ARM port of Cygwin.  I don't know about Cygwin
directly, but I know there are users of Git for Windows on ARM.

I think a more gradual sunsetting of 32-bit might be a resonable
compromise, based on the original wording:

> 11:26  starting with 3.4.0, maintainers are not obliged to
> release packages in 32 bit

so as of 3.4.0 some packages that are problematic on 32 bit may stop
providing 32-bit versions.  But not being obliged to release packages is a
whole different thing than having the core code that allows *any* package
to run being ripped out in that version.

-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: [HEADSUP] Phasing out old Windows versions and 32 bit support

Hi Peter,

Am 27.10.2021 um 18:46 schrieb Peter A. Castro:

On Wed, Oct 27, 2021 at 11:37:26AM +0200, Thomas Wolff wrote:

Greetings, Thomas,

Am 27.10.2021 um 10:49 schrieb Corinna Vinschen via Cygwin:

On Oct 27 09:24, Takashi Yano via Cygwin wrote:

On Tue, 26 Oct 2021 22:55:01 +0200
Corinna Vinschen wrote:

We're also planning to drop Support for the 32 bit release of Cygwin in
2022, thus Cygwin 3.4.0 won't come in 32 bit anymore, and the package
maintainers won't have to update 32 bit packages anymore. If you're
still running Cygwin under WOW64, consider to move to 64 bit in the next
couple of months.

I agree with you that 32 bit cygwin under WOW64 is not worth to
support any more. However, 32 bit version of Windows 10 will be
still supported at least until Oct. 2025. Personally, I think it
would not be nice to exclude the supported windows version from
cygwin support.

Well, it's not much effort to support WOW64 if we support 32 bit anyway.
The problem is that Cygwin is somehow outgrowing 32 bit systems in terms
of the available memory. Also, 32 bit Cygwin is still using a 32 bit
time_t, https://en.wikipedia.org/wiki/Year_2038_problem

Per the download statistics, as far as those statistics are trustable,
32 bit systems are less than 5% of the installed base, with the majority
of them being WOW64 installations. Those can move over to 64 bit Cygwin
easily.

Less than 1% are real 32 bit systems.

I think roughly 1% is still a community to consider. Working old machines
shouldn't be trashed just because they are missing a few bits :)

Dropping 32 bit support will reduce code complexity in Cygwin and it will
reduce the workload of the package maintainers.

Code complexity was also an argument when dropping XP support, but there was
quite some discussion at its time.
For `egrep "# *if.*(32|64)"` I'm counting roughly 160 matches in winsup, but
only in a few files. Is it really necessary?

Those few still running
Cygwin on a real 32 bit system will still have a chance to run Cygwin
by utilizing Peter's time machine.

Peter's time machine is a very appreciable effort. It's a bit fiddly though to figure out
how to use it, particularly to identify the "latest XP version". Maybe some
explicit howto could be published on the cygwin pages?

Could you please give an example of the "fiddly" bit? I list the URLs
to use with the install and it's clearly labeled "The last version of
Cygwin that supports XP is 2.5.2-1". Or were you, perhaps, refering to
the actual usage of the URL in the Setup program?
On http://www.crouchingtigerhiddenfruitbat.org/Cygwin/timemachine.html,
I see a setup link and a repository URL.
If I run that setup and enter the URL on the mirror selection page, I
get an error popup

---
Cygwin Setup
---
Can't open /software/windows/cygwin32/x86_64/setup.xz.sig for reading:
No such file or directory

---
OK
---
So I should have deselected the preselected repository explicitly. If I
fix that or click the popup off a few times, there's another popup

---
Cygwin Setup
---
Unable to get
http://ctm.crouchingtigerhiddenfruitbat.org/pub/cygwin/circa/64bit/2016/08/30/104235/x86_64/setup.xz.sig
from

---
OK
---
repeatedly.
The command line you mentioned in the other mail does not seem to work
either. The 32-bit version works (from the command line only). Also
setup suggests my existing cygwin installation as its installation
target which needs to be fixed carefully to avoid destruction...

Another user, Michel, responded that perhaps a more explicit message
with exact steps for install this might be helpful (as the "Dead Simple
Instructions" are generic), but I'm not sure it's really necessary. Is
that, perhaps, what you are refering to in that the instructions aren't
explicit enough?
An explicit quote of a safely working command line invocation would
certainly help.

Best greetings
Thomas

--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: gcc 11 weird bug

2021-10-27 Thread Brian Inglis


On 2021-10-27 03:19, Thomas Wolff wrote:
I noticed that mintty did not compile anymore after upgrade to gcc 11, 
but only on cygwin 32-bit.
I tried to minimize the test case as much as possible without having the 
bug vanish, to the attached standalone file.

Compile this with
cc -O2 -Wall -Werror m0.c
and it gives a false positive warning about possible uninitialized data 
usage.
While data flow analysis is not perfect, it is weird that this used to 
happen on 32 bit but not on 64 bit.
Meanwhile, after updating some other packages (not sure which), but 
still the same gcc version, the report on the test case also happens on 
64 bit, while the original, unstripped file, as part of mintty, still 
works without error on 64 bit, which is even weirder.
I have not yet had the opportunity to test this on Linux, sorry, so I'm 
reporting it here.


Your initialization loops all have i = 0; i < count; which may leave 
types[0] uninitialized.


You should also add -Wextra to your compiles to get these warnings:

$ gcc -g -O2 -Wall -Wextra -c m0.c
m0.c: In function ‘do_bidi’:
m0.c:40:14: warning: unused parameter ‘autodir’ [-Wunused-parameter]
40 | do_bidi(bool autodir, int paragraphLevel, bool explicitRTL, 
bool box_mirror,

   |  ^
m0.c:40:66: warning: unused parameter ‘box_mirror’ [-Wunused-parameter]
40 | do_bidi(bool autodir, int paragraphLevel, bool explicitRTL, 
bool box_mirror,

   |  ^
m0.c:41:21: warning: unused parameter ‘line’ [-Wunused-parameter]
41 | bidi_char * line, int count)
   | ^~~~
m0.c:256:12: warning: ‘*types[0]’ may be used uninitialized 
[-Wmaybe-uninitialized]

   256 |   if (types[0] == NSM /*&& !skip[0]*/)
   |   ~^~~

with source:

   if (types[0] == NSM /*&& !skip[0]*/)
 types[0] = (paragraphLevel & 1) ? R : L;  // sor

you need to add below:

   int isolateLevel = 0;
   int resLevel = -1;

the following:

   if (!count) {
 return resLevel;
   }

as that seems to be missing, then perhaps after:

  (void)levels;

  types[0] = NSM;

or something appropriate to quiet the warning.

You may also want to look at the control flow through your switch to see 
whether some additional else branches and assignments would ensure the 
values are always set.


You may also want to consider whether adding the following options to 
your gcc command lines would work with your builds:


-fanalyzer -fsanitize-recover=all -fstack-check -fstack-protector-all

as they could give you more warnings about possible issues.

--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]

--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: gcc 11 weird bug

2021-10-27 Thread Corinna Vinschen via Cygwin-announce via Cygwin




Am 27.10.2021 um 12:55 schrieb Hannes Domani:

  Am Mittwoch, 27. Oktober 2021, 11:19:19 MESZ hat Thomas Wolff  
Folgendes geschrieben:


I noticed that mintty did not compile anymore after upgrade to gcc 11,
but only on cygwin 32-bit.
I tried to minimize the test case as much as possible without having the
bug vanish, to the attached standalone file.
Compile this with
cc -O2 -Wall -Werror m0.c
and it gives a false positive warning about possible uninitialized data
usage.
While data flow analysis is not perfect, it is weird that this used to
happen on 32 bit but not on 64 bit.
Meanwhile, after updating some other packages (not sure which), but
still the same gcc version, the report on the test case also happens on
64 bit, while the original, unstripped file, as part of mintty, still
works without error on 64 bit, which is even weirder.
I have not yet had the opportunity to test this on Linux, sorry, so I'm
reporting it here.
Thomas

If you mean this warning:

m0.c: In function 'do_bidi':
m0.c:256:12: error: '*types[0]' may be used uninitialized 
[-Werror=maybe-uninitialized]

This warning is correct, because as far as gcc is concerned, count could
be 0, and in this case types[0] will be uninitialized (and doesn't even
exist, since it's declared as 'uchar types[count];').
Thanks for the hint. I acknowledge that the analyser cannot know that 
count > 0 here. But if types[0] exists, it cannot be unitialized so the 
wording of the warning is not correct in this case. Anyway, this leads 
to a less obtrusive workaround than the current one.

Thomas

--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: [HEADSUP] Phasing out old Windows versions and 32 bit support [XEmacs for 64-bit?]

2021-10-27 Thread Dan Harkless via Cygwin


On 10/26/2021 1:55 PM, Corinna Vinschen via Cygwin wrote:

We're also planning to drop Support for the 32 bit release of Cygwin in
2022, thus Cygwin 3.4.0 won't come in 32 bit anymore, and the package
maintainers won't have to update 32 bit packages anymore.  If you're
still running Cygwin under WOW64, consider to move to 64 bit in the next
couple of months.
Except for my 32-bit Windows 7 (upgraded to 8.1) netbook, the only 
reason I still install Cygwin32 in parallel with Cygwin64 is so I can 
install the XEmacs packages.  Anyone know more about the difficulty in 
getting those packages to work on 64-bit?  XEmacs from EPEL works fine 
on 64-bit Linux, FWIW.


From past attempts, I know it would take far too much time (and Elisp 
programming) to get GNU Emacs up to the usability level that I've had 
XEmacs at since the '90s.


(w3m-img is another package only available on Cygwin32 that I install, 
but I don't use it and am not concerned about that one.)


Thanks,
Dan Harkless



--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

[ANNOUNCEMENT] lynx 2.8.9-13

The following packages have been uploaded to the Cygwin distribution:

* lynx-2.8.9-13

Lynx is a text-based Web browser. Lynx does not display any images,
but it does support frames, tables, and most other HTML tags. One
advantage Lynx has over graphical browsers is speed; Lynx starts and
exits quickly and swiftly displays web pages.

-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: [HEADSUP] Phasing out old Windows versions and 32 bit support [XEmacs for 64-bit?]

2021-10-27 Thread Dan Harkless via Cygwin


On 10/26/2021 1:55 PM, Corinna Vinschen via Cygwin wrote:

We're also planning to drop Support for the 32 bit release of Cygwin in
2022, thus Cygwin 3.4.0 won't come in 32 bit anymore, and the package
maintainers won't have to update 32 bit packages anymore.  If you're
still running Cygwin under WOW64, consider to move to 64 bit in the next
couple of months.
Except for my 32-bit Windows 7 (upgraded to 8.1) netbook, the only 
reason I still install Cygwin32 in parallel with Cygwin64 is so I can 
install the XEmacs packages.  Anyone know more about the difficulty in 
getting those packages to work on 64-bit?  XEmacs from EPEL works fine 
on 64-bit Linux, FWIW.


From past attempts, I know it would take far too much time (and Elisp 
programming) to get GNU Emacs up to the usability level that I've had 
XEmacs at since the '90s.


(w3m-img is another package only available on Cygwin32 that I install, 
but I don't use it and am not concerned about that one.)


Thanks,
Dan Harkless



--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: [HEADSUP] Phasing out old Windows versions and 32 bit support

On Wed, Oct 27, 2021 at 11:04:16PM +0200, Thomas Wolff wrote:
> Hi Peter,

Greetings, Thomas,

> Am 27.10.2021 um 18:46 schrieb Peter A. Castro:
> > On Wed, Oct 27, 2021 at 11:37:26AM +0200, Thomas Wolff wrote:
> > 
> > Greetings, Thomas,
> > 
> > > Am 27.10.2021 um 10:49 schrieb Corinna Vinschen via Cygwin:
> > > > On Oct 27 09:24, Takashi Yano via Cygwin wrote:
> > > > > On Tue, 26 Oct 2021 22:55:01 +0200
> > > > > Corinna Vinschen wrote:
> > > > > > We're also planning to drop Support for the 32 bit release of 
> > > > > > Cygwin in
> > > > > > 2022, thus Cygwin 3.4.0 won't come in 32 bit anymore, and the 
> > > > > > package
> > > > > > maintainers won't have to update 32 bit packages anymore.  If you're
> > > > > > still running Cygwin under WOW64, consider to move to 64 bit in the 
> > > > > > next
> > > > > > couple of months.
> > > > > I agree with you that 32 bit cygwin under WOW64 is not worth to
> > > > > support any more. However, 32 bit version of Windows 10 will be
> > > > > still supported at least until Oct. 2025. Personally, I think it
> > > > > would not be nice to exclude the supported windows version from
> > > > > cygwin support.
> > > > Well, it's not much effort to support WOW64 if we support 32 bit anyway.
> > > > The problem is that Cygwin is somehow outgrowing 32 bit systems in terms
> > > > of the available memory.  Also, 32 bit Cygwin is still using a 32 bit
> > > > time_t, https://en.wikipedia.org/wiki/Year_2038_problem
> > > > 
> > > > Per the download statistics, as far as those statistics are trustable,
> > > > 32 bit systems are less than 5% of the installed base, with the majority
> > > > of them being WOW64 installations.  Those can move over to 64 bit Cygwin
> > > > easily.
> > > > 
> > > > Less than 1% are real 32 bit systems.
> > > I think roughly 1% is still a community to consider. Working old machines
> > > shouldn't be trashed just because they are missing a few bits :)
> > > 
> > > > Dropping 32 bit support will reduce code complexity in Cygwin and it 
> > > > will
> > > > reduce the workload of the package maintainers.
> > > Code complexity was also an argument when dropping XP support, but there 
> > > was
> > > quite some discussion at its time.
> > > For `egrep "# *if.*(32|64)"` I'm counting roughly 160 matches in winsup, 
> > > but
> > > only in a few files. Is it really necessary?
> > > 
> > > > Those few still running
> > > > Cygwin on a real 32 bit system will still have a chance to run Cygwin
> > > > by utilizing Peter's time machine.
> > > Peter's time machine is a very appreciable effort. It's a bit fiddly 
> > > though to figure out how to use it, particularly to identify the "latest 
> > > XP version". Maybe some explicit howto could be published on the cygwin 
> > > pages?
> > Could you please give an example of the "fiddly" bit?  I list the URLs
> > to use with the install and it's clearly labeled "The last version of
> > Cygwin that supports XP is 2.5.2-1".  Or were you, perhaps, refering to
> > the actual usage of the URL in the Setup program?
> On http://www.crouchingtigerhiddenfruitbat.org/Cygwin/timemachine.html, I
> see a setup link and a repository URL.
> If I run that setup and enter the URL on the mirror selection page, I get an
> error popup
> ---
> Cygwin Setup
> ---
> Can't open /software/windows/cygwin32/x86_64/setup.xz.sig for reading: No
> such file or directory
> ---
> OK
> ---
> So I should have deselected the preselected repository explicitly. If I fix
> that or click the popup off a few times, there's another popup
> ---
> Cygwin Setup
> ---
> Unable to get 
> http://ctm.crouchingtigerhiddenfruitbat.org/pub/cygwin/circa/64bit/2016/08/30/104235/x86_64/setup.xz.sig
> from 
> 
> ---
> OK
> ---
> repeatedly.

I see.

Yes, that is the setup signature file.  At the top of the timemachine
webpage there is a note is bold saying:

"NOTE: Please remember to use the '-X' option when running setup!! (See
update 08/05/2008 for details)."

Now, it could be that setup is ignoring that option or that that option
doesn't fully bypass the check for the signature file.  It used to and I
though it still does, but perhaps, that functionality has change?  Need
to ask Jon about that.

> The command line you mentioned in the other mail does not seem to work
> either. The 32-bit version works (from the command line only). Also setup
> suggests my existing cygwin installation as its installation target which
> needs to be fixed carefully to avoid destruction...

So, that is an issue with how setup is invoked.  Running from the
command line and using the -X works, as you say, but staring it from an
icon doesn't give you any option to supply the -X. so, yes, I can see
that is a

Re: [HEADSUP] Phasing out old Windows versions and 32 bit support [XEmacs for 64-bit?]

2021-10-27 Thread Dan Harkless via Cygwin

Oops, sorry for the direct email.  Didn't realize you now have to use 
the "Reply List" button that pops into existence rather than the normal 
Reply button.  I re-sent to the list.


- Dan Harkless


On 10/27/2021 3:35 PM, Dan Harkless wrote:

On 10/26/2021 1:55 PM, Corinna Vinschen via Cygwin wrote:

We're also planning to drop Support for the 32 bit release of Cygwin in
2022, thus Cygwin 3.4.0 won't come in 32 bit anymore, and the package
maintainers won't have to update 32 bit packages anymore.  If you're
still running Cygwin under WOW64, consider to move to 64 bit in the next
couple of months.
Except for my 32-bit Windows 7 (upgraded to 8.1) netbook, the only 
reason I still install Cygwin32 in parallel with Cygwin64 is so I can 
install the XEmacs packages.  Anyone know more about the difficulty in 
getting those packages to work on 64-bit?  XEmacs from EPEL works fine 
on 64-bit Linux, FWIW.


From past attempts, I know it would take far too much time (and Elisp 
programming) to get GNU Emacs up to the usability level that I've had 
XEmacs at since the '90s.


(w3m-img is another package only available on Cygwin32 that I install, 
but I don't use it and am not concerned about that one.)


Thanks,
Dan Harkless



--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: [HEADSUP] Phasing out old Windows versions and 32 bit support

On Oct 26 18:52, Michel LaBarre wrote:
> Corinna , thank you for the heads up regarding subsequent updates wrt Window
> 7.
> 
> Would it be possible to create a short "how-to" for installing the most
> recently "known-to-work-with-Windows-7" version of Cygwin (presuming that
> old versions remain accessible indefinitely...).  Alternately, how one can
> download a repository now that is compatible with Windows 7 and useable for
> installing Cygwin in anticipation of the upcoming loss of support.

No hurry.  As I wrote, 3.4.0 in 2022 will be the last version we support
on W7.  That doesn't mean Cygwin will immediately stop working on W7, we
just won't make concessions for W7 anymore in later versions than 3.4.x.
If you can reproduce a bug in 3.4.x, make sure to reproduce it on W8.1
or W10/11.

Corinna

-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: [HEADSUP] Phasing out old Windows versions and 32 bit support

2021-10-27 Thread Corinna Vinschen via Cygwin-announce via Cygwin

On Oct 26 21:29, Peter A. Castro wrote:
> On Tue, Oct 26, 2021 at 06:52:02PM -0400, Michel LaBarre wrote:
> 
> Greetings, Michel & Corinna,
> 
> > Corinna , thank you for the heads up regarding subsequent updates wrt Window
> > 7.
> > 
> > Would it be possible to create a short "how-to" for installing the most
> > recently "known-to-work-with-Windows-7" version of Cygwin (presuming that
> > old versions remain accessible indefinitely...).  Alternately, how one can
> > download a repository now that is compatible with Windows 7 and useable for
> > installing Cygwin in anticipation of the upcoming loss of support.
> 
> As these milestones occur I will make notes in the Cygwin Time Machine
> concerning the ending release snapshot and installers, like what I have
> for the last XP release.
> 
> Corinna, I presume you will post when these milestones occur so that we
> have a more exact message in the Cygwin mail archive?

In which way do you mean?  My planning was this:

When I release 3.3.0 (next couple of days), I will add a note to the
announcement that this is the last major release supporting Vista and
Server 2008.

When I release 3.4.0 (in some nebular future of 2022), I will add a
note to the announcement that this version does not support Vista and
2008 anymore, and that 3.4.0 is the last version supporting
W7, 8, 2008R2, 2012.

That ok?  Or do you think of somehting else?

Oh, that reminds me... I should have sent the headsup to cygwin-announce,
not to the cygwin ML.  I will fix this omission immediately...

Thanks,
Corinna

-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

[ANNOUNCEMENT] [HEADSUP] Phasing out old Windows versions and 32 bit support

[I sent this announcement to the Cygwin mailing list accidentally.
 Now sending it to cygwin-announce, too, to reach more people.  Please
 reply on the cygwin mailing list if you have any concerns or comments]


Hi folks,


The upcoming version 3.3.0 is the last version officially supporting
Windows Vista and Windows Server 2008.

The next major release 3.4.0 will be released in 2022 and will be the
last one officially supporting Windows 7, Windows 8, Windows Server 2008
R2, and Windows Server 2012.

We're also planning to drop Support for the 32 bit release of Cygwin in
2022, thus Cygwin 3.4.0 won't come in 32 bit anymore, and the package
maintainers won't have to update 32 bit packages anymore.  If you're
still running Cygwin under WOW64, consider to move to 64 bit in the next
couple of months.


Corinna

-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

gcc 11 weird bug

I noticed that mintty did not compile anymore after upgrade to gcc 11, 
but only on cygwin 32-bit.
I tried to minimize the test case as much as possible without having the 
bug vanish, to the attached standalone file.

Compile this with
cc -O2 -Wall -Werror m0.c
and it gives a false positive warning about possible uninitialized data 
usage.
While data flow analysis is not perfect, it is weird that this used to 
happen on 32 bit but not on 64 bit.
Meanwhile, after updating some other packages (not sure which), but 
still the same gcc version, the report on the test case also happens on 
64 bit, while the original, unstripped file, as part of mintty, still 
works without error on 64 bit, which is even weirder.
I have not yet had the opportunity to test this on Linux, sorry, so I'm 
reporting it here.

Thomas
#include 
typedef unsigned short wchar;// UTF-16
typedef unsigned char uchar;
#define lengthof(array) (sizeof(array) / sizeof(*(array)))

#define when break; case
#define or : case
#define otherwise break; default

typedef unsigned int ucschar;

typedef struct {
} bidi_char;

/* bidi classes (Unicode: PropertyValueAliases.txt) */
enum {
  L, LRE, LRO, R, AL, RLE, RLO, PDF, EN, ES, ET, AN, CS, NSM, BN, B, S, WS, ON,
  LRI, RLI, FSI, PDI
};

#define leastGreaterOdd(x) ( ((x)+1) | 1 )
#define leastGreaterEven(x) ( ((x)+2) &~ 1 )


static bool
is_NI(uchar bc)
{
  return 1 & (1 << (bc));
}


/*
 * The Main Bidi Function, and the only function that should
 * be used by the outside world.
 *
 * line: a buffer of size count containing text to apply
 * the Bidirectional algorithm to.
 */
int
do_bidi(bool autodir, int paragraphLevel, bool explicitRTL, bool box_mirror, 
bidi_char * line, int count)
{
  uchar currentEmbedding;
  uchar currentOverride;
  uchar tempType;
  int i, j;

  uchar bidi_class_of(int i) {
(void)i;

if (explicitRTL)
  return R;

return ON;
  }

 /* Rule (P2), (P3)
  * P2. In each paragraph, find the first character of type L, AL, or R 
while skipping over any characters between an isolate initiator and 
its matching PDI or, if it has no matching PDI, the end of the paragraph.
  * P3. If a character is found in P2 and it is of type AL or R, then set
  * the paragraph embedding level to one; otherwise, set it to zero.
  */
  int isolateLevel = 0;
  int resLevel = -1;


 /* Initialize types, levels */
  uchar types[count];
  uchar levels[count];
  (void)levels;

 /* Rule (X1)
X1. At the beginning of a paragraph, perform the following steps:
  • Set the stack to empty.
  • Push onto the stack an entry consisting of the paragraph embedding level,
a neutral directional override status, and a false directional isolate 
status.
  • Set the overflow isolate count to zero.
  • Set the overflow embedding count to zero.
  • Set the valid isolate count to zero.
  • Process each character iteratively, applying rules X2 through X8. 
Only embedding levels from 0 through max_depth are valid in this phase. 
(Note that in the resolution of levels in rules I1 and I2, 
the maximum embedding level of max_depth+1 can be reached.)
  */
  currentEmbedding = paragraphLevel;
  currentOverride = ON;
  bool currentIsolate = false;

  // By making the dss as large as the whole line, we avoid overflow handling.
  uchar dss_emb[count + 1];
  uchar dss_ovr[count + 1];
  bool dss_isol[count + 1];
  int dss_top = -1;

  int countdss() { return dss_top + 1; }

  void pushdss() {
dss_top++;
dss_emb[dss_top] = currentEmbedding;
dss_ovr[dss_top] = currentOverride;
dss_isol[dss_top] = currentIsolate;
  }

  void popdss() {
// remove top
if (dss_top >= 0)
  dss_top--;
// then set current values to new top
if (dss_top >= 0) {
  currentEmbedding = dss_emb[dss_top];
  currentOverride = dss_ovr[dss_top];
  currentIsolate = dss_isol[dss_top];
}
  }

  pushdss();
  //int ovfIsolate = 0;
  //int ovfEmbedding = 0;
  isolateLevel = 0;

 /* Rule (X2), (X3), (X4), (X5), (X6), (X7), (X8)
  * X2. With each RLE, compute the least greater odd embedding level.
  * X3. With each LRE, compute the least greater even embedding level.
  * X4. With each RLO, compute the least greater odd embedding level.
  * X5. With each LRO, compute the least greater even embedding level.
  * X6. For all types besides RLE, LRE, RLO, LRO, and PDF:
  *  a. Set the level of the current character to the current
  *  embedding level.
  *  b. Whenever the directional override status is not neutral,
  *  reset the current character type to the directional
  *  override status.
  * X7. With each PDF, determine the matching embedding or override code.
  * If there was a valid matching code, restore (pop) the last
  * remembered (pushed) embedding level and directional override.
  * X8. All explicit directional embeddings and overrides are completely
  * terminated at the end of each paragraph. Paragraph separators are

Re: [HEADSUP] Phasing out old Windows versions and 32 bit support

On Oct 27 09:24, Takashi Yano via Cygwin wrote:
> On Tue, 26 Oct 2021 22:55:01 +0200
> Corinna Vinschen wrote:
> > We're also planning to drop Support for the 32 bit release of Cygwin in
> > 2022, thus Cygwin 3.4.0 won't come in 32 bit anymore, and the package
> > maintainers won't have to update 32 bit packages anymore.  If you're
> > still running Cygwin under WOW64, consider to move to 64 bit in the next
> > couple of months.
> 
> I agree with you that 32 bit cygwin under WOW64 is not worth to
> support any more. However, 32 bit version of Windows 10 will be
> still supported at least until Oct. 2025. Personally, I think it
> would not be nice to exclude the supported windows version from
> cygwin support.

Well, it's not much effort to support WOW64 if we support 32 bit anyway.
The problem is that Cygwin is somehow outgrowing 32 bit systems in terms
of the available memory.  Also, 32 bit Cygwin is still using a 32 bit
time_t, https://en.wikipedia.org/wiki/Year_2038_problem

Per the download statistics, as far as those statistics are trustable,
32 bit systems are less than 5% of the installed base, with the majority
of them being WOW64 installations.  Those can move over to 64 bit Cygwin
easily.

Less than 1% are real 32 bit systems.

Dropping 32 bit support will reduce code complexity in Cygwin and it will
reduce the workload of the package maintainers.  Those few still running
Cygwin on a real 32 bit system will still have a chance to run Cygwin
by utilizing Peter's time machine.

Corinna

-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: [HEADSUP] Phasing out old Windows versions and 32 bit support





Am 27.10.2021 um 10:49 schrieb Corinna Vinschen via Cygwin:

On Oct 27 09:24, Takashi Yano via Cygwin wrote:

On Tue, 26 Oct 2021 22:55:01 +0200
Corinna Vinschen wrote:

We're also planning to drop Support for the 32 bit release of Cygwin in
2022, thus Cygwin 3.4.0 won't come in 32 bit anymore, and the package
maintainers won't have to update 32 bit packages anymore.  If you're
still running Cygwin under WOW64, consider to move to 64 bit in the next
couple of months.

I agree with you that 32 bit cygwin under WOW64 is not worth to
support any more. However, 32 bit version of Windows 10 will be
still supported at least until Oct. 2025. Personally, I think it
would not be nice to exclude the supported windows version from
cygwin support.

Well, it's not much effort to support WOW64 if we support 32 bit anyway.
The problem is that Cygwin is somehow outgrowing 32 bit systems in terms
of the available memory.  Also, 32 bit Cygwin is still using a 32 bit
time_t, https://en.wikipedia.org/wiki/Year_2038_problem

Per the download statistics, as far as those statistics are trustable,
32 bit systems are less than 5% of the installed base, with the majority
of them being WOW64 installations.  Those can move over to 64 bit Cygwin
easily.

Less than 1% are real 32 bit systems.
I think roughly 1% is still a community to consider. Working old 
machines shouldn't be trashed just because they are missing a few bits :)



Dropping 32 bit support will reduce code complexity in Cygwin and it will
reduce the workload of the package maintainers.
Code complexity was also an argument when dropping XP support, but there 
was quite some discussion at its time.
For `egrep "# *if.*(32|64)"` I'm counting roughly 160 matches in winsup, 
but only in a few files. Is it really necessary?



Those few still running
Cygwin on a real 32 bit system will still have a chance to run Cygwin
by utilizing Peter's time machine.


Peter's time machine is a very appreciable effort. It's a bit fiddly though to figure out 
how to use it, particularly to identify the "latest XP version". Maybe some 
explicit howto could be published on the cygwin pages?

Thomas


--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: Phasing out old Windows versions and 32 bit support

2021-10-27 Thread L A Walsh





On 2021/10/26 13:55, Corinna Vinschen via Cygwin wrote:

Hi folks,


The upcoming version 3.3.0 is the last version officially supporting
Windows Vista and Windows Server 2008.

The next major release 3.4.0 will be released in 2022 and will be the
last one officially supporting Windows 7, Windows 8, Windows Server 2008 R2, 
and Windows Server 2012.


   Is that like 2022-Jan, or 2022-Dec?  Sigh.

--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: Phasing out old Windows versions and 32 bit support

On Oct 27 04:03, L A Walsh wrote:
> 
> 
> On 2021/10/26 13:55, Corinna Vinschen via Cygwin wrote:
> > Hi folks,
> > 
> > 
> > The upcoming version 3.3.0 is the last version officially supporting
> > Windows Vista and Windows Server 2008.
> > 
> > The next major release 3.4.0 will be released in 2022 and will be the
> > last one officially supporting Windows 7, Windows 8, Windows Server 2008 
> > R2, and Windows Server 2012.
> 
>Is that like 2022-Jan, or 2022-Dec?  Sigh.

We simply don't know yet.  Jan is very unlikely, though.


Corinna

-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: [HEADSUP] Phasing out old Windows versions and 32 bit support