mintty 0.1 → 0.1.1

raw patch · 3 files changed

+47/−4 lines, 3 files

Files

• CHANGELOG.md +5/−0
• mintty.cabal +1/−2
• src/System/Console/MinTTY/Win32.hsc +41/−2

@@ -1,2 +1,7 @@+### 0.1.1 [2017-03-17]+* Work around a serious bug on 32-bit Windows GHC that causes linker errors+  when mintty is used together with code that uses certain `msvcrt` functions,+  such as `atan`+ ## 0.1 [2017-01-30] * Initial release

@@ -1,5 +1,5 @@ name:                mintty-version:             0.1+version:             0.1.1 synopsis:            A reliable way to detect the presence of a MinTTY console on Windows description:         MinTTY is a Windows-specific terminal emulator for the                      widely used Cygwin and MSYS projects, which provide@@ -55,7 +55,6 @@       include-dirs:    include       includes:        windows_cconv.h, winternl_compat.h       other-modules:   System.Console.MinTTY.Win32-      extra-libraries: ntdll    hs-source-dirs:      src   default-language:    Haskell2010

@@ -1,5 +1,5 @@ {--This is a direct copy of System.Win32.MinTTY from the Win32 library. We need+This is a (mostly) direct copy of System.Win32.MinTTY from the Win32 library. We need this for backwards compatibility with older versions of Win32 which do not ship with this module. -}@@ -38,8 +38,9 @@ #if MIN_VERSION_base(4,6,0) import Control.Exception (catch) #endif+import Control.Monad (void) import Data.List (isPrefixOf, isInfixOf, isSuffixOf)-import Foreign+import Foreign hiding (void) import Foreign.C.Types import System.FilePath (takeFileName) @@ -141,11 +142,24 @@       bufSize   = sizeOfONI + mAX_PATH * sizeOfTCHAR   allocaBytes bufSize $ \buf ->     alloca $ \p_len -> do+      {-+      See Note [Don't link against ntdll]       _ <- failIfNeg "NtQueryObject" $ c_NtQueryObject              h objectNameInformation buf (fromIntegral bufSize) p_len+      -}+      ntQueryObject h objectNameInformation buf (fromIntegral bufSize) p_len       oni <- peek buf       return $ usBuffer $ oniName oni +-- See Note [Don't link against ntdll]+ntQueryObject :: HANDLE -> CInt -> Ptr OBJECT_NAME_INFORMATION+              -> ULONG -> Ptr ULONG -> IO ()+ntQueryObject h cls buf bufSize p_len = do+  lib <- getModuleHandle (Just "ntdll.dll")+  ptr <- getProcAddress lib "NtQueryObject"+  let c_NtQueryObject = mk_NtQueryObject (castPtrToFunPtr ptr)+  void $ failIfNeg "NtQueryObject" $ c_NtQueryObject h cls buf bufSize p_len+ fileNameInfo :: CInt fileNameInfo = #const FileNameInfo @@ -186,10 +200,22 @@           , fniFileName       = vfniFileName           } +{-+In an ideal world, we'd use this instead of the hack below.+See Note [Don't link against ntdll]+ foreign import WINDOWS_CCONV "winternl.h NtQueryObject"   c_NtQueryObject :: HANDLE -> CInt -> Ptr OBJECT_NAME_INFORMATION                   -> ULONG -> Ptr ULONG -> IO NTSTATUS+-} +type F_NtQueryObject+  =  HANDLE -> CInt -> Ptr OBJECT_NAME_INFORMATION+  -> ULONG -> Ptr ULONG -> IO NTSTATUS++foreign import WINDOWS_CCONV "dynamic"+  mk_NtQueryObject :: FunPtr F_NtQueryObject -> F_NtQueryObject+ type NTSTATUS = #type NTSTATUS type ULONG    = #type ULONG @@ -238,3 +264,16 @@  sizeOfTCHAR :: Int sizeOfTCHAR = sizeOf (undefined :: TCHAR)++{-+Note [Don't link against ntdll]+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~++We deliberately avoid using any direct foreign imports from ntdll, and instead+dynamically load any functions we need from ntdll by hand. Why? As it turns+out, if you're using some versions of the 32-bit mingw-w64-crt library (which+is shipped with GHC on Windows), statically linking against both ntdll and+msvcrt can lead to nasty linker redefinition errors. See GHC Trac #13431.+(Curiously, this bug is only present on 32-bit Windows, which is why it went+unnoticed for a while.)+-}