I was going to report a bug with the transition to lts-19.13 in stack.yaml as I couldn't
get for instance commit [[!commit d2bc2683173ca1ade437aa294b26fd5e54353a55]] "lts-19.13 (ghc 9.0.2)"
that introduced it to compile on windows (with stack). But then I procrastinated too long and commit
[[!commit d01530ac21aead6607085b5cc90b62a52acd03a9]] came along which reverted the transition and
went back to lts-18.13 due to Joey having trouble getting ghc 9.0.2 to install. That was kind of fortunate
to me because I didn't want to be the bringer of bad news regarding Windows in a bug report setting.

The problem with compiling with LTS 19 on Windows is the following:

[[!format sh """
[...]
[109 of 670] Compiling Utility.LockFile.Windows

Utility\LockFile\Windows.hs:64:17: error:
    * Variable not in scope:
        c_CreateFile
          :: LPTSTR
             -> AccessMode
             -> ShareMode
             -> GHC.Ptr.Ptr a0
             -> CreateMode
             -> FileAttributeOrFlag
             -> GHC.Ptr.Ptr a1
             -> IO HANDLE
    * Perhaps you meant `createFile' (imported from System.Win32.File)
   |
64 |                 c_CreateFile c_f gENERIC_READ sharemode security_attributes

   |                 ^^^^^^^^^^^^
Completed 229 action(s).

--  While building package git-annex-10.20220624 (scroll up to its section to see the error) using:
      C:\Users\jkniiv\Projektit\git-annex.branchable.com\git-annex--BUILD-220630-d2bc26831\.stack-work\dist\d53b6a14\setup\setup --builddir=.stack-work\dist\d53b6a14 build exe:git-annex --ghc-options " -fdiagnostics-color=always"
    Process exited with code: ExitFailure 1
"""]]

I digged into this and it turned out that as of Win32-2.12.0.0 it does not include those bindings
anymore that begin with `c_` in its exports and considers them as internal details. Unfortunately in
System.Win32.File the alternative, `createFile`, is a "cooked" API in the sense that if there are
intermittent errors opening the file there is some Haskell code that busy-waits on behalf of the user.
But according to Joey that is undesirable for a lockfile implementation (.\Utility\LockFile\Windows.hs:53):

```
 - Note that createFile busy-waits to try to avoid failing when some other
 - process briefly has a file open. But that would make checking locks
 - much more expensive, so is not done here. Thus, the use of c_CreateFile.
 
```

So what to do when the authors of package Win32 pull the rug from under you? Should we perhaps weave
our own tiny c_CreateFile API with FFI, or, could we do without it and use one of the implementations
using Windows LockFileEx, for instance the one by my compatriot: <https://hackage.haskell.org/package/lukko>

[[!meta title="windows: prepare for System.Win32.File not exporting c_ entities"]]
[[!meta author=jkniiv]]
