This is the mail archive of the cygwin-apps@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

HEADSUP package maintainers: Welcome to Cygwin 1.5.0


Ok, this is my "Welcome to 1.5.0" message for package maintainers.  I hope
it answers most questions.  If not, feel free to ask on cygwin-apps.


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 Gigs and to
  show filesizes over 2 Gigs 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)
  have been changed accordingly.

  Ditto all related functions (lseek, fseeko, stat, setuid, getgid, ...).


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

  First of all, all affected types have 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!

  Again, please note that the new datatypes are used automatically.
  There isn't any choice between e.g. a off_t with 32 bit and a off64_t
  with 64 bit and no corresponding functions as stat and stat64.
  Building under 1.5.0 means, off_t is 64 bit now.  stat is expecting
  a struct stat with 64 bit off_t.  Full stop.  No compile time
  options.  All or nothing.  Well, you got the idea, I guess...

  Think about it.  Especially if you're maintaining an older package
  (my own inetutils is a good candidate) it might require some code
  changes.  To stick with off_t as example, old packages often expect
  off_t to fit well into long. 

    printf("%ld", off);

  will print... interesting... values.  Other similar traps are possible.


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.


HTH,
Corinna

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]