1.5.0 release text

Corinna Vinschen vinschen@redhat.com
Fri Jul 4 21:12:00 GMT 2003


On Fri, Jul 04, 2003 at 01:47:59PM -0400, Christopher Faylor wrote:
> This announcement should probably be accompanied with a detailed
> description of what package maintainers need to do in cygwin-apps to
> deal with 64 bit file I/O.  Anyone want to draft that?

I wrote down a start.  The description how the package maintainers
should work together to get new 1.5.0 versions done is still lacking
detail I guess.

  What is that 64 bit babble?
  ---------------------------

  Up to release 1.3.x, Cygwin had some limitations which were induced
  by too small datatypes:

  off_t was 32 bit, so not allowing to seek more than 2 Megs and to
  show filesizes over 2 Megs correctly.  This has been changed to
  64 bit, allowing to access all files correctly.

  fpos_t, ditto.

  blkcnt_t, used in struct stat, change from 32 to 64 bit for the same
  reason.

  ino_t, changed from 32 to 64 bit to allow 1:1 mapping of Windows 
  file index numbers to inode numbers.

  uid_t and gid_t were 16 bit which result in problems mapping Windows NT
  user accounts to uids and gids.  Changed to 32 bit.

  All related structures (FILE, struct stat, struct dirent, struct group)
  has been changed accordingly.

  How does that all work?
  -----------------------

  First of all, all affected types has been defined twice, once for
  releases up to 1.3.22, once for 1.5.0ff.  The usage of the new 
  datatypes is controlled by a define in include/cygwin/config.h
  called __CYGWIN_USE_BIG_TYPES__.  If this define exists, the new
  bigger datatypes are used.  Note that this define is *not* under
  package developer control!  It marks the switch from small to big
  datatypes in conjunction with the used import library.

  To make this clear:  If you build an application with header files
  from 1.3.22 and libcygwin.a from 1.5.0, the result is very likely
  broken.  And vice versa, if you build an application with 1.5.0
  headers and 1.3.x libcygwin.a the result will probably not work.
  If you need to build applications running under 1.3.x, keep the
  1.3.x headers and import libraries.

  As I mentioned above, Cygwin is using the big datatypes internally
  throughout.  So, how is it possible that an old application can call
  a function, say lseek(), with a 32 bit off_t and a newly build
  application calls it with a 64 bit off_t?

  The internal implementation of lseek looks like this:

    _off32_t lseek(int fd, _off32_t offset, int whence)
    {
      return (_off32_t) lseek64 (fd, (_off64_t) offset, whence);
    }

    _off64_t lseek64(int fd, _off64_t offset, int whence)
    {
       [actual implementation]
    }

  lseek and lseek64 are both exported from the Cygwin DLL.  Old
  applications still use the lseek entry point since they don't know
  better.  Newly build applications on the other hand will use the
  lseek64 entry point directly.  But how do they know?  That's done
  at link time.  The new libcygwin.a import library translates call
  to lseek to calls to lseek64 transparently.  Applications don't have
  to know anything, they just get it for free.

  How does that affect applications?
  ----------------------------------

  All current applications, build under Cygwin versions prior to 1.5.0
  don't have access to the new 64 bit world.  These applications will
  run, but they are still limited as before.

  Newly build applications are on the bright side of life.  They do
  use all the new types automatically.  But this transition of
  applications has to be done carefully.  Applications build under
  1.5.0 will not run under older Cygwin releases!

  How does that affect Cygwin package maintainers?
  ------------------------------------------------

  It's important to know, if the package depends on other external
  libraries besides Cygwin itself. 

  Packages only dependend on Cygwin can be build immediately and
  will run as expected (iff they are prepared to handle 64 bit types
  correctly).

  Packages which depend on external libs should be newly build only
  if all external libs have been newly build first.  E.g. vim depends
  on ncurses.  So I, the vim maintainer, will wait with creating a new
  vim version until Charles, the ncurses maintainer, has created a new
  ncurses version.

  This means, the package maintainers of libraries, especially those
  which provide DLLs should build a new version of their packages
  as soon as possible.  Only with all libs finished, we can finally
  migrate the whole Cygwin net distro to 64 bit.


Oh and I have a few missing items for the list:

> Changes since 1.3.22-1 (not a bad release as releases go):

- Implement ftok. (Charles Wilson)

- Implement vsyslog. (Corinna Vinschen)

- Implement wcscoll, wcswidth and wcwidth. (Corinna Vinschen)

- Detect Windows 2003 Server. (Corinna Vinschen)

- Add inttypes.h and stdint.h (Corinna Vinschen)

Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Developer                                mailto:cygwin@cygwin.com
Red Hat, Inc.



More information about the Cygwin-developers mailing list