adding to GHC/win32 Handle operations support of Unicodefilenamesand files larger than 4 GB

[Simon Marlow]

On 24 November 2005 01:17, Bulat Ziganshin wrote:

> so, as first step i propose to move middle-level code from GHC.Handle
> to Posix.Internals, join FD type definitions, replace CString with
> CFilePath where appropriate, and so on. and only after this - make
> changes specific for windows. i can do it all. what you will say?

Please, go ahead!  Your plan to add a new platform-indpendent
abstraction layer over the low-level I/O is a good one, I agree with the
arguments you put forward.  This will indeed make it easier to replace
the Handle library in the future, too.

> if my changes will be committed only to GHC 6.6 (HEAD) branch, the
> problem that types of c_* functions is changed will not be a big
> problem - you anyway change some interfaces between major releases.
> but now i'm realized that Posix.Internals is part of libraries common
> for several Haskell compilers. can such changes break their working?

This is a .Internals library, so in theory you only have to look at code
in the same package in order to determine whether it breaks anything.
It wouldn't hurt to ask the Hugs & nhc98 folk too, just in case.

> moreover, i plan to move "throwErrnoIfMinus1RetryOnBlock" to
> Foreign.C.Error, and sEEK_CUR/sEEK_SET/sEEK_END - to Posix.Internals.
> can it be done?

I think so, but this module follows the FFI spec, so it should at the
least be documented as an extension (fortunately, strictly speaking
Foreign.C.Error doesn't have to always follow the FFI spec, but CError
does).

> -- Support for Unicode filenames and files>4GB
> #ifdef mingw32_HOST_OS

Note that we have had support for >4Gb files on Unix for quite some
time, it is only Windows that is lacking in this regard.

> in ALL the places where this feature test must take place. it will
> document the code and give ability to easily find/edit all these
> places if this will be needed sometime in the future

If you want to make it clearer, then add new CPP symbols

  WIN32_UNICODE_FILENAMES
  WIN32_64BIT_OFFSETS

these can be set based on mingw32_HOST_OS for now, but it leaves the
possibility of using autoconf later.
 
> can i also ask several questions about "new i/o" library? as i see,
> this library solves 3 problems:

Each of the questions you asked needs more than a one paragraph answer,
and there has been a great deal of discussion on these topics in the
past.

For now, I'll just say that certain aspects of my prototype I/O library
replacement are clearly wrong, and need redesigning (eg. creating
multiple streams from a single File isn't implementable).  I don't
really have the bandwidth to put any serious thought into this right
now, but there's nothing stopping you from modifying my proposal and/or
coming up with something of your own.

Cheers,
	Simon