[ANNOUNCEMENT] TEST: Cygwin 3.0.0-0.2

[ANNOUNCEMENT] TEST: Cygwin 3.0.0-0.2

[Corinna Vinschen]

Hi folks,


I uploaded a new Cygwin test release 3.0.0-0.2

This release comes with a couple of new features and some interesting
bug fixes.

It also changes the output of uname(2) for newly built applications.
Applications built so far (that includes uname(1) from coreutils)
will still print the old uname output.  The new format allows for longer
strings.  Compare:

Old uname content:

  sysname:  CYGWIN_NT-10.0     or  CYGWIN_NT-10.0-WOW   on WOW64
  release:  3.0.0(0.335/5/3)   or  3.0.0s(0.335/5/3)    for snapshots
  version:  2019-01-29 19:23   Local build time 

Upcoming new uname content:

  sysname:  CYGWIN_NT-10.0-17763   or  CYGWIN_NT-10.0-17763-WOW64
  release:  3.0.0-335.x86_64       or  3.0.0-335.x86_64.snap
  version:  2019-01-29 19:23 UTC   Build time in UTC


Changes to 3.0.0-0.1:

- fix raise to perform more POSIX compliant
- fix a permissions problem on Windows 7 and Vista.


Please test.

=======================================================================

What's new:
-----------

- Support for CLOCK_REALTIME_COARSE, CLOCK_MONOTONIC_COARSE,
  CLOCK_MONOTONIC_RAW, CLOCK_BOOTTIME, CLOCK_REALTIME_ALARM,
  CLOCK_BOOTTIME_ALARM clocks.

- Support for case sensitive directories.  mkdir(2) automatically
  creates directories within the Cygwin installation dir as case
  sensitive now.

  This feature requires Windows 10 1803 or later and WSL installed!

- New file ioctls's FS_IOC_GETFLAGS and FS_IOC_SETFLAGS.  The actual
  inode flags are Cygwin-specific.  This allows to set or reset
  DOS attributes, file sparseness, FS level encryption and compression,
  as well as directory case sensitivity programatically.

- New tools chattr(1) and lsattr(1) to utilize setting and viewing the
  aforementioned new ioctl's on the command line.

- Support for exFAT.

- Support Linux-specific open(2) flag O_PATH.

- Support Linux-specific linkat(2) flag AT_EMPTY_PATH.

- Support overrun counter for posix timers (via timer_getoverrun() or
  siginfo_t::si_overrun).

- New APIs: signalfd, timerfd_create, timerfd_gettime, timerfd_settime,
  timer_getoverrun.


What changed:
-------------

- clock_nanosleep, pthread_condattr_setclock and timer_create now support
  all clocks, except CLOCK_PROCESS_CPUTIME_ID and CLOCK_THREAD_CPUTIME_ID.

- clock_setres is a no-op now.

- Use the new POSIX unlink semantics on NTFS starting with Windows 10 1709.
  Deleting an in-use file now actually removes the file, rather than moving
  it to the recycler bin.

- Use the new POSIX rename semantics on NTFS starting with Windows 10 1809.
  Renaming a file to another in-use file now actually removes the other file,
  rather than moving it to the recycler bin.

- open(..., O_TMPFILE) now moves the file to the trash bin immediately,
  to free the parent directory.

- Wctype functions updated to Unicode 11.0.

- Remove matherr, and SVID and X/Open math library configurations.
  Default math library configuration is now IEEE.

- Improve uname(2) for newly built applications.

- Kerberos/MSV1_0 S4U authentication replaces two old methods:
  Creating a token from scratch and Cygwin LSA authentication package.


Bug Fixes
---------

- Fix a thread race when initializing CLOCK_MONOTONIC.
  Addresses: https://cygwin.com/ml/cygwin/2018-11/msg00017.html

- Fix early timeout from pthread_cond_timedwait.
  Addresses: https://cygwin.com/ml/cygwin/2018-11/msg00171.html

- Fix a bug in recognizing remote FAT/FAT32/exFAT correctly.

- Allow open(2)/stat(2)/linkat(2) of a file via /proc/PID/fd/DESCRIPTOR
  even if file has been deleted.
  Addresses: https://cygwin.com/ml/cygwin/2018-12/msg00125.html
             https://cygwin.com/ml/cygwin/2018-12/msg00028.html

- Fix a bug in select(2) when polling HANDLE-less descriptors.

- Fix WEOF handling in wctype functions.
  Addresses: https://cygwin.com/ml/cygwin/2018-12/msg00173.html

- Fix thread names in GDB when cygthreads get reused.

- Fix return value of gethostname in a border case.

- Disallow seteuid on disabled or locked out accounts.
  Addresses: https://cygwin.com/ml/cygwin/2019-01/msg00197.html

- Fix raise to work as required by POSIX.
  (Partially) addresses: https://cygwin.com/ml/cygwin/2019-01/msg00149.html

=======================================================================


Have fun,
Corinna

-- 
Corinna Vinschen
Cygwin Maintainer

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

Re: [ANNOUNCEMENT] TEST: Cygwin 3.0.0-0.2

[Brian Inglis]

On 2019-01-30 07:03, Corinna Vinschen wrote:
> I uploaded a new Cygwin test release 3.0.0-0.2
> It also changes the output of uname(2) for newly built applications.
> Applications built so far (that includes uname(1) from coreutils)
> will still print the old uname output.  The new format allows for longer
> strings.  Compare:
> Upcoming new uname content:
>   sysname:  CYGWIN_NT-10.0-17763   or  CYGWIN_NT-10.0-17763-WOW64
>   release:  3.0.0-335.x86_64       or  3.0.0-335.x86_64.snap
>   version:  2019-01-29 19:23 UTC   Build time in UTC

Re: "(*) It would really be nice not having to ask for these infos every time."
may want to append HKLM/SOFTWARE/Microsoft/Windows NT/CurrentVersion/UBR to
uname -s sysname to show the patch levels of installed builds, as there appears
to be substantial differences between editions and service models.

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

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

Re: [ANNOUNCEMENT] TEST: Cygwin 3.0.0-0.2

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1136 bytes --]

On Jan 30 09:11, Brian Inglis wrote:
> On 2019-01-30 07:03, Corinna Vinschen wrote:
> > I uploaded a new Cygwin test release 3.0.0-0.2
> > It also changes the output of uname(2) for newly built applications.
> > Applications built so far (that includes uname(1) from coreutils)
> > will still print the old uname output.  The new format allows for longer
> > strings.  Compare:
> > Upcoming new uname content:
> >   sysname:  CYGWIN_NT-10.0-17763   or  CYGWIN_NT-10.0-17763-WOW64
> >   release:  3.0.0-335.x86_64       or  3.0.0-335.x86_64.snap
> >   version:  2019-01-29 19:23 UTC   Build time in UTC
> 
> Re: "(*) It would really be nice not having to ask for these infos every time."
> may want to append HKLM/SOFTWARE/Microsoft/Windows NT/CurrentVersion/UBR to
> uname -s sysname to show the patch levels of installed builds, as there appears
> to be substantial differences between editions and service models.

Thanks for the info, but what to do with this?  Is there a thorough
description somewhere to allow deciphering what this means to us?


Thanks,
Corinna

-- 
Corinna Vinschen
Cygwin Maintainer

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [ANNOUNCEMENT] TEST: Cygwin 3.0.0-0.2

[Richard Campbell]

On Wed, Jan 30, 2019 at 11:31 AM Corinna Vinschen
<corinna-cygwin@cygwin.com> wrote:
>
> On Jan 30 09:11, Brian Inglis wrote:
> >
> > Re: "(*) It would really be nice not having to ask for these infos every time."
> > may want to append HKLM/SOFTWARE/Microsoft/Windows NT/CurrentVersion/UBR to
> > uname -s sysname to show the patch levels of installed builds, as there appears
> > to be substantial differences between editions and service models.
>
> Thanks for the info, but what to do with this?  Is there a thorough
> description somewhere to allow deciphering what this means to us?

Isn't it just the part of the build number after the decimal in "Build
17134.523" or similar?

https://support.microsoft.com/en-us/help/4018124/windows-10-update-history
https://support.microsoft.com/en-us/help/4480966

-Richard Campbell.

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

Re: [ANNOUNCEMENT] TEST: Cygwin 3.0.0-0.2

[Brian Inglis]

On 2019-01-30 10:31, Corinna Vinschen wrote:
> On Jan 30 09:11, Brian Inglis wrote:
>> On 2019-01-30 07:03, Corinna Vinschen wrote:
>>> I uploaded a new Cygwin test release 3.0.0-0.2
>>> It also changes the output of uname(2) for newly built applications.
>>> Applications built so far (that includes uname(1) from coreutils)
>>> will still print the old uname output.  The new format allows for longer
>>> strings.  Compare:
>>> Upcoming new uname content:
>>>   sysname:  CYGWIN_NT-10.0-17763   or  CYGWIN_NT-10.0-17763-WOW64
>>>   release:  3.0.0-335.x86_64       or  3.0.0-335.x86_64.snap
>>>   version:  2019-01-29 19:23 UTC   Build time in UTC
>> Re: "(*) It would really be nice not having to ask for these infos every time."
>> may want to append HKLM/SOFTWARE/Microsoft/Windows NT/CurrentVersion/UBR to
>> uname -s sysname to show the patch levels of installed builds, as there appears
>> to be substantial differences between editions and service models.
> Thanks for the info, but what to do with this? Is there a thorough
> description somewhere to allow deciphering what this means to us?

UBR Update Build Revision appears to be incremented for each patch set released
for the W10 feature set OS build, to complete a unique revision id, similar to
Cygwin 335 above.
Would save those of us who know to, having to also run and append the output of

$ cmd /c ver

Microsoft Windows [Version 10.0.17134.523]

and save asking those who don't know that, in case the revision makes a difference.
Insider build feature sets bump the builds, and patch sets bump those revisions;
up to base releases with known feature sets, builds, and revisions; then patch
Tuesdays bump those revisions higher; so you can tell if installs are Insider,
base, or patched.

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

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

Re: [ANNOUNCEMENT] TEST: Cygwin 3.0.0-0.2

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 2332 bytes --]

On Jan 30 11:47, Brian Inglis wrote:
> On 2019-01-30 10:31, Corinna Vinschen wrote:
> > On Jan 30 09:11, Brian Inglis wrote:
> >> On 2019-01-30 07:03, Corinna Vinschen wrote:
> >>> I uploaded a new Cygwin test release 3.0.0-0.2
> >>> It also changes the output of uname(2) for newly built applications.
> >>> Applications built so far (that includes uname(1) from coreutils)
> >>> will still print the old uname output.  The new format allows for longer
> >>> strings.  Compare:
> >>> Upcoming new uname content:
> >>>   sysname:  CYGWIN_NT-10.0-17763   or  CYGWIN_NT-10.0-17763-WOW64
> >>>   release:  3.0.0-335.x86_64       or  3.0.0-335.x86_64.snap
> >>>   version:  2019-01-29 19:23 UTC   Build time in UTC
> >> Re: "(*) It would really be nice not having to ask for these infos every time."
> >> may want to append HKLM/SOFTWARE/Microsoft/Windows NT/CurrentVersion/UBR to
> >> uname -s sysname to show the patch levels of installed builds, as there appears
> >> to be substantial differences between editions and service models.
> > Thanks for the info, but what to do with this? Is there a thorough
> > description somewhere to allow deciphering what this means to us?
> 
> UBR Update Build Revision appears to be incremented for each patch set released
> for the W10 feature set OS build, to complete a unique revision id, similar to
> Cygwin 335 above.
> Would save those of us who know to, having to also run and append the output of
> 
> $ cmd /c ver
> 
> Microsoft Windows [Version 10.0.17134.523]
> 
> and save asking those who don't know that, in case the revision makes a difference.
> Insider build feature sets bump the builds, and patch sets bump those revisions;
> up to base releases with known feature sets, builds, and revisions; then patch
> Tuesdays bump those revisions higher; so you can tell if installs are Insider,
> base, or patched.

I'm not so sure this makes sense from a Cygwin perspective.  We're
interested in the major releases introducing changing and/or new
functionality.  The monthly updates don't do that so they have no
meaning to us.

I just wonder if we should replace the build number with the ReleaseId
(i.e. 17763 vs. 1809), but that excludes the fast lane updates from
being visible.


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [ANNOUNCEMENT] TEST: Cygwin 3.0.0-0.2

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 2884 bytes --]

On Jan 30 19:53, Corinna Vinschen wrote:
> On Jan 30 11:47, Brian Inglis wrote:
> > On 2019-01-30 10:31, Corinna Vinschen wrote:
> > > On Jan 30 09:11, Brian Inglis wrote:
> > >> On 2019-01-30 07:03, Corinna Vinschen wrote:
> > >>> I uploaded a new Cygwin test release 3.0.0-0.2
> > >>> It also changes the output of uname(2) for newly built applications.
> > >>> Applications built so far (that includes uname(1) from coreutils)
> > >>> will still print the old uname output.  The new format allows for longer
> > >>> strings.  Compare:
> > >>> Upcoming new uname content:
> > >>>   sysname:  CYGWIN_NT-10.0-17763   or  CYGWIN_NT-10.0-17763-WOW64
> > >>>   release:  3.0.0-335.x86_64       or  3.0.0-335.x86_64.snap
> > >>>   version:  2019-01-29 19:23 UTC   Build time in UTC
> > >> Re: "(*) It would really be nice not having to ask for these infos every time."
> > >> may want to append HKLM/SOFTWARE/Microsoft/Windows NT/CurrentVersion/UBR to
> > >> uname -s sysname to show the patch levels of installed builds, as there appears
> > >> to be substantial differences between editions and service models.
> > > Thanks for the info, but what to do with this? Is there a thorough
> > > description somewhere to allow deciphering what this means to us?
> > 
> > UBR Update Build Revision appears to be incremented for each patch set released
> > for the W10 feature set OS build, to complete a unique revision id, similar to
> > Cygwin 335 above.
> > Would save those of us who know to, having to also run and append the output of
> > 
> > $ cmd /c ver
> > 
> > Microsoft Windows [Version 10.0.17134.523]
> > 
> > and save asking those who don't know that, in case the revision makes a difference.
> > Insider build feature sets bump the builds, and patch sets bump those revisions;
> > up to base releases with known feature sets, builds, and revisions; then patch
> > Tuesdays bump those revisions higher; so you can tell if installs are Insider,
> > base, or patched.
> 
> I'm not so sure this makes sense from a Cygwin perspective.  We're
> interested in the major releases introducing changing and/or new
> functionality.  The monthly updates don't do that so they have no
> meaning to us.
> 
> I just wonder if we should replace the build number with the ReleaseId
> (i.e. 17763 vs. 1809), but that excludes the fast lane updates from
> being visible.

On second thought there's also the format discrepancy.  Right now the
new uname crates the version string like "10.0-17763", but it might be
better to use "10.0.17763", replacing the dash with a dot, to follow
more closely the OS layout.  On third thought it seems prudent to
print either

  10.0-1809{-WOW64}

or

  10.0.17763.253{-WOW64}


Hmm.  The second form appears to make the most sense, actually.


Corinna


-- 
Corinna Vinschen
Cygwin Maintainer

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [ANNOUNCEMENT] TEST: Cygwin 3.0.0-0.2

[Andrey Repin]

Greetings, Brian Inglis!

> Re: "(*) It would really be nice not having to ask for these infos every time."
> may want to append HKLM/SOFTWARE/Microsoft/Windows NT/CurrentVersion/UBR to
> uname -s sysname to show the patch levels of installed builds, as there appears
> to be substantial differences between editions and service models.

Anything from persistent storage is easily falsified.


-- 
With best regards,
Andrey Repin
Wednesday, January 30, 2019 21:56:32

Sorry for my terrible english...


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

Re: [ANNOUNCEMENT] TEST: Cygwin 3.0.0-0.2

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 2881 bytes --]

On Jan 30 20:01, Corinna Vinschen wrote:
> On Jan 30 19:53, Corinna Vinschen wrote:
> > On Jan 30 11:47, Brian Inglis wrote:
> > > On 2019-01-30 10:31, Corinna Vinschen wrote:
> > > > On Jan 30 09:11, Brian Inglis wrote:
> > > >> On 2019-01-30 07:03, Corinna Vinschen wrote:
> > > >>> I uploaded a new Cygwin test release 3.0.0-0.2
> > > >>> It also changes the output of uname(2) for newly built applications.
> > > >>> Applications built so far (that includes uname(1) from coreutils)
> > > >>> will still print the old uname output.  The new format allows for longer
> > > >>> strings.  Compare:
> > > >>> Upcoming new uname content:
> > > >>>   sysname:  CYGWIN_NT-10.0-17763   or  CYGWIN_NT-10.0-17763-WOW64
> > > >>>   release:  3.0.0-335.x86_64       or  3.0.0-335.x86_64.snap
> > > >>>   version:  2019-01-29 19:23 UTC   Build time in UTC
> > > >> Re: "(*) It would really be nice not having to ask for these
> > > >> infos every time." may want to append
> > > >> HKLM/SOFTWARE/Microsoft/Windows NT/CurrentVersion/UBR to uname
> > > >> -s sysname to show the patch levels of installed builds, as
> > > >> there appears to be substantial differences between editions
> > > >> and service models.
> > > [...]
> > > $ cmd /c ver
> > > 
> > > Microsoft Windows [Version 10.0.17134.523]
> > > 
> > > and save asking those who don't know that, in case the revision
> > > makes a difference.  Insider build feature sets bump the builds,
> > > and patch sets bump those revisions; up to base releases with
> > > known feature sets, builds, and revisions; then patch Tuesdays
> > > bump those revisions higher; so you can tell if installs are
> > > Insider, base, or patched.
> > 
> > I'm not so sure this makes sense from a Cygwin perspective.  We're
> > interested in the major releases introducing changing and/or new
> > functionality.  The monthly updates don't do that so they have no
> > meaning to us.
> > 
> > I just wonder if we should replace the build number with the ReleaseId
> > (i.e. 17763 vs. 1809), but that excludes the fast lane updates from
> > being visible.
> 
> On second thought there's also the format discrepancy.  Right now the
> new uname crates the version string like "10.0-17763", but it might be
> better to use "10.0.17763", replacing the dash with a dot, to follow
> more closely the OS layout.  On third thought it seems prudent to
> print either
> 
>   10.0-1809{-WOW64}
> 
> or
> 
>   10.0.17763.253{-WOW64}
> 
> 
> Hmm.  The second form appears to make the most sense, actually.

But then again, no OS before W10 printed that info, e.g.:

  Microsoft Windows [Version 6.3.9600]

We also have to make sure we're not breaking scripts, especially
autoconf etc., so on forth thought, I'll rather stick to the current
format.


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [ANNOUNCEMENT] TEST: Cygwin 3.0.0-0.2

[Brian Inglis]

On 2019-01-30 11:56, Andrey Repin wrote:
>> Re: "(*) It would really be nice not having to ask for these infos every time."
>> may want to append HKLM/SOFTWARE/Microsoft/Windows NT/CurrentVersion/UBR to
>> uname -s sysname to show the patch levels of installed builds, as there appears
>> to be substantial differences between editions and service models.
> Anything from persistent storage is easily falsified.

Should not even be modifiable if there is reg security on the subtree.
Not really a big concern as a target in anything I've seen.
Everything is easily falsified with root privs.

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

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

Re: [ANNOUNCEMENT] TEST: Cygwin 3.0.0-0.2

[Brian Inglis]

On 2019-01-30 13:29, Corinna Vinschen wrote:
> On Jan 30 20:01, Corinna Vinschen wrote:
>> On Jan 30 19:53, Corinna Vinschen wrote:
>>> On Jan 30 11:47, Brian Inglis wrote:
>>>> On 2019-01-30 10:31, Corinna Vinschen wrote:
>>>>> On Jan 30 09:11, Brian Inglis wrote:
>>>>>> On 2019-01-30 07:03, Corinna Vinschen wrote:
>>>>>>> I uploaded a new Cygwin test release 3.0.0-0.2
>>>>>>> It also changes the output of uname(2) for newly built applications.
>>>>>>> Applications built so far (that includes uname(1) from coreutils)
>>>>>>> will still print the old uname output.  The new format allows for longer
>>>>>>> strings.  Compare:
>>>>>>> Upcoming new uname content:
>>>>>>>   sysname:  CYGWIN_NT-10.0-17763   or  CYGWIN_NT-10.0-17763-WOW64
>>>>>>>   release:  3.0.0-335.x86_64       or  3.0.0-335.x86_64.snap
>>>>>>>   version:  2019-01-29 19:23 UTC   Build time in UTC
>>>>>> Re: "(*) It would really be nice not having to ask for these
>>>>>> infos every time." may want to append
>>>>>> HKLM/SOFTWARE/Microsoft/Windows NT/CurrentVersion/UBR to uname
>>>>>> -s sysname to show the patch levels of installed builds, as
>>>>>> there appears to be substantial differences between editions
>>>>>> and service models.
>>>> [...]
>>>> $ cmd /c ver
>>>> Microsoft Windows [Version 10.0.17134.523]
>>>> and save asking those who don't know that, in case the revision
>>>> makes a difference.  Insider build feature sets bump the builds,
>>>> and patch sets bump those revisions; up to base releases with
>>>> known feature sets, builds, and revisions; then patch Tuesdays
>>>> bump those revisions higher; so you can tell if installs are
>>>> Insider, base, or patched.
>>> I'm not so sure this makes sense from a Cygwin perspective.  We're
>>> interested in the major releases introducing changing and/or new
>>> functionality.  The monthly updates don't do that so they have no
>>> meaning to us.
>>> I just wonder if we should replace the build number with the ReleaseId
>>> (i.e. 17763 vs. 1809), but that excludes the fast lane updates from
>>> being visible.
>> On second thought there's also the format discrepancy.  Right now the
>> new uname crates the version string like "10.0-17763", but it might be
>> better to use "10.0.17763", replacing the dash with a dot, to follow
>> more closely the OS layout.  On third thought it seems prudent to
>> print either
>>   10.0-1809{-WOW64}
>> or
>>   10.0.17763.253{-WOW64}
>> Hmm.  The second form appears to make the most sense, actually.
> But then again, no OS before W10 printed that info, e.g.:
>   Microsoft Windows [Version 6.3.9600]
> We also have to make sure we're not breaking scripts, especially
> autoconf etc., so on forth thought, I'll rather stick to the current
> format.

I have zero problems with your previous considerations and decisions, but as
some new features now also require WSL installed to work, should there be some
such indication from uname e.g. +WSL where -WOW would appear?

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

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

Re: [ANNOUNCEMENT] TEST: Cygwin 3.0.0-0.2

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 744 bytes --]

On Feb 17 10:48, Brian Inglis wrote:
> On 2019-01-30 13:29, Corinna Vinschen wrote:
> > We also have to make sure we're not breaking scripts, especially
> > autoconf etc., so on forth thought, I'll rather stick to the current
> > format.
> 
> I have zero problems with your previous considerations and decisions, but as
> some new features now also require WSL installed to work, should there be some
> such indication from uname e.g. +WSL where -WOW would appear?

I don't see an easy way to test if WSL is installed.  I'm also not
so sure we really need the info, at least not in uname output.
Maybe cygcheck is a candidate for that.  Feel free to add it
there.


Thanks,
Corinna

-- 
Corinna Vinschen
Cygwin Maintainer

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]