Switch to high-level operations for obtaining OS handles

[jeltsch]

There is an effort to move some GHC-specific modules out of base. Candidates for such moving are GHC.IO.Handle.Types and GHC.IO.Handle.Internals. These modules are often used for obtaining operating-system handles (file descriptors, Windows handles) from Haskell handles. Such uses are also present in the haskeline package.

There is a proposal to add dedicated operations for operating-system handle acquisition to base. A corresponding draft implementation can be found in GHC merge request !14732. Furthermore, the Win32 package has been supporting the acquisition of Windows handles for quite some time. In fact, the code of Win32’s System.Win32.Types.withHandleToHANDLE operation is essentially the same as the code of haskeline’s System.Console.Haskeline.Backend.Win32.Echo.withHandleToHANDLE operation.

The present pull request changes haskeline to use the new operation withFileDescriptorReadingBiasedRaw from the above-mentioned draft implementation for acquiring POSIX file descriptors and withHandleToHANDLE from Win32 for acquiring Windows handles.

There are a few things to be aware of:

• The above-mentioned draft implementation also contains operations for acquiring Windows handles. However, these operations only work when using the Windows I/O manager, while withHandleToHANDLE also works when using the POSIX I/O manager on Windows, by performing an extra conversion from an acquired POSIX file descriptor to the corresponding Windows handle. Furthermore, unlike the operations from the draft implementation, withHandleToHANDLE does not block operations on the given handle, which may or may not be relevant.

• For detecting whether a given handle refers to a MinTTY console, haskeline used to require Win32 of at least version 2.5.0, while with the changes introduced by this pull request it requires Win32 of at least version 2.5.1. This is because version 2.5.1 of Win32 introduced the withHandleToHANDLE operation, and I did not deem it worthwhile to leave the previous, custom implementation of Windows handle acquisition in place just for supporting a single, rather old Win32 version.

• When running the test suite on the code in this pull request using Ubuntu 24.04, several test failures are reported, but these are also reported when running the test suite on the unmodified code.

[athas]

However, these operations only work when using the Windows I/O manager, while withHandleToHANDLE also works when using the POSIX I/O manager on Windows, by performing an extra conversion from an acquired POSIX file descriptor to the corresponding Windows handle.

What are the implications of this? I know nothing about Windows I/O. Will any users notice?

[jeltsch]

[The above-mentioned draft implementation also contains operations for acquiring Windows handles.] However, these operations only work when using the Windows I/O manager, while withHandleToHANDLE also works when using the POSIX I/O manager on Windows, by performing an extra conversion from an acquired POSIX file descriptor to the corresponding Windows handle.

What are the implications of this? I know nothing about Windows I/O. Will any users notice?

Those operations, which only work when using the Windows I/O manager, aren’t used by the code in this pull request. Instead, this pull requests replaces the use of haskeline’s custom withHandleToHANDLE operation by the use of the operation of the same name from Win32 (see further above in my pull request description). These two versions of withHandleToHANDLE are almost identical. The only difference that I’ve found is that the Win32 version works also for duplex handles (Handle values that use the DuplexHandle constructor). So, if there is any behavior change at all, then it should be such that haskeline works in more situations. That said, I doubt that anything will change, because my understanding is that duplex handles are typically used for network sockets, while haskeline deals with terminals.

I mentioned the new operations for acquiring Windows handles from !14732 only to explain why this pull request doesn’t use them. It uses operations from !14732 only to acquire file descriptors on POSIX systems.