George V. Reilly

Win64 port of Vim

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.

blog comments powered by Disqus
Barbecue University » « Subversive activity