I’ve ported Vim to Win64. Native binaries for AMD64 can be found on my Vim page.

In the end, it wasn’t all that hard. Last weekend, I fixed ap­prox­i­mate­ly 400 warnings that were thrown up by the x86_amd64 cross compiler. Most of them were due to the widening of size_t (especially the value returned from strlen()) and ptrdiff_t to 64-bits. Several years ago, I went through a similar exercise in fixing these warnings for Vim6, but I never finished the port.

This week, I scrounged access to an AMD64 box at work. Today, I turned on the /Wp64 flag, which found several new, subtler problems, where pointers where being truncated to __int32s or conversely __int32s were being widened to pointers. Judicious in­tro­duc­tion of (the equivalent of) (INT_PTR) casts fixed most of those.

At that point, I tried running the binary. It refused to start! After a few detours, I had WinDbg installed, and ran gvim under WinDbg. That showed that the error was 14001 (ER­ROR_SXS_­CAN­T_­GEN_ACTC­TX, "The ap­pli­ca­tion has failed to start because its side-by-side con­fig­u­ra­tion is incorrect. Please see the ap­pli­ca­tion event log for more detail.") The event log showed nothing.

After more in­ves­ti­ga­tion, I found a WinSxS manifest for the Windows Common Controls:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
  <assemblyIdentity
    processorArchitecture="X86"
    version="6.2.0.0"
    type="win32"
    name="Vim"
  />
  <description>Vi Improved - A Text Editor</description>
  <dependency>
    <dependentAssembly>
      <assemblyIdentity
        type="win32"
        name="Microsoft.Windows.Common-Controls"
        version="6.0.0.0"
        publicKeyToken="6595b64144ccf1df"
        language="*"
        processorArchitecture="X86"
      />
    </dependentAssembly>
  </dependency>
</assembly>

Once the two instances of proces­so­rAr­chi­tec­ture="X86" were set to proces­so­rAr­chi­tec­ture="AMD64", Vim started working without a hitch. Despite my naïve ex­pec­ta­tions, none of the other fields in the comctl32 assembly needed to be changed.