Cygwin 1.7 release (was Re: ??? The library or libraries will be delivered[...])

[Corinna Vinschen <corinna-cygwin at cygwin dot com>]

On Jun  3 16:39, Charles Wilson wrote:
> Ken Brown said:
> >  But it does seem that the release of 1.7 is a good time to ...
> 
> You know, folks, at some point we need to stop saying "1.7 is a good
> time to <make massive change X>" and just release it. We already have
> the following "backwards incompatible" [*] changes 
> 
> 1) dropping support for Win9x

Uh oh.

> 2) no longer launch native programs from long or virtual CWDs (before,
> IIRC cygwin-1.5 would 'fake' the CWD as c:/ or something)

This was always a bit weird.  A 'cd /proc' never actually cd'ed to
something, so a native Win32 process ended up in the previous cwd.
We discussed this on cygwin-developers.

As for long pathnames, they weren't accessible before at all.

<rant>
And it's really not my fault that Win32 processes are not able to deal
with CWDs > 259 characters.  The original Win32 layer programmers IMHO
seriously screwed up when they decided to store the CWD in a 260 WCHARs
wide static array in the PEB instead of dynamically allocating the path.

Having said that, they also screwed us all with the strange distinction
between normal and long pathnames in the Win32 API.
</rant>

> 3) wide char support (and various existing changes related to LANG
> settings in console and other terminal sessions)

This turns out to be sort of a nightmare, but I'm still glad I did it.
We now have full wide char support and setting $LANG/etc does really
something useful.  I can't imagine how painful it would have been to
drag this change along in small steps.

Apart from the bugs I introduced with this change, what's missing is
real support for file-based locale data in /usr/share/locale and
support for the other LC_ categories (LC_TIME, LC_MONETARY, etc).
But that's something which can be improved over time.

> 4) removal of registry usage / new mount table

That change only affects how mount points are stored.  The day to day
usage is the same, basically.

> 5) old signal mask support removed (probably doesn't actually affect
> anyone)

Only applications which haven't been rebuilt for more than 10 years.

> 6) [possible] switch to gcc4 as official compiler (with associated
> deliberate ABI breakage *without* DLL version number bumps -- see
> http://cygwin.com/ml/cygwin-apps/2009-04/msg00034.html). It's pretty
> clear this will happen *eventually*. Whether it happens
> before/on/soon-after the 1.7 rollout is still TBD.

That's still a sore point.  Dave, is there any chance we can switch
to gcc-4 as standard compiler for Cygwin 1.7 within the next 4 weeks?

> Each time we say "1.7 is a good time to..." and pull the trigger, it's
> another month of stabilization.  During that month somebody ELSE has a
> bright idea about yet another thing "1.7 would be a good time to...". 
> This is not good.

Yeah, we should stop right here.  The biggest problem left is the
native language support, apparently.  I'm still hoping to get
1.7.1 out of the door end of this month, though.

What's left, AFAICS is

- The usual bugfixing.

- Creating the final version of setup-1.7.exe and replace
  cygwin.com/setup.exe with it.

- Move the old documentation somehwere else, move the new docs to
  the old place. (And don't forget to remove the "1.7" subdir from
  the URLs in the docs).

- Splitting off the union FS for release-2.

- New versions of GCC and binutils would be nice.  I'd especially
  appreciate if GCC would start to create executables with the TS-aware
  flag by default so that the distro is sort of self-healing in terms of
  running on Terminal Servers.

Am I missing something else?


Corinna

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