Vim for Windows
Looking for Emacs?
Table of Contents
There are several projects which tried or are trying to provide Vim builds for Windows. However, some of them are either already dead or struggle with crashes from time to time, for example, because of using miserable toolchains (like Visual C++) and/or lack of experience in building native software in general. I'm not going to poke a finger in these projects or provide any links to them as this is irrelevant for further discussion after all.
The goal of this project is to provide high-quality native builds of Vim for Windows with support for both x86 (32-bit) and x64 (64-bit) architectures, "huge" feature set, and scripting interfaces for most popular programming languages:
- Windows 2000;
- Windows XP;
- Windows Vista;
- Windows 7;
- Windows 8.
- x86 (x86-32, x32, i686);
- x64 (x86-64, amd64).
- Go to Downloads and obtain archive with desired version and compatible with your current platform and architecture (see Requirements);
- Extract the archive wherever you like;
- Enjoy, and happy Vimming!
I'm going to talk about trivial stuff here, but last time some people had issues
even with this part. Can you believe that?!
First of all, please, understand that usually scripting interfaces come in the form of shared libraries — external reusable binary components, intended to be (dynamically, i.e. at run time) loaded and bound to some (already) running process which depends on certain functionality provided by them. On Windows platforms the concept of shared library is implemented as dynamic-link library (DLL), while on Unix platforms it is implemented as shared object (SO).
Scripting interfaces for Vim are not an exception here. As a result, for them to
work properly in Vim, all you have to do is to make sure that their
corresponding DLLs (with versions that your chosen Vim distribution expects)
are visible to both
gvim.exe (so that these DLLs can be loaded
and bound by Vim at run time). You have 2 options to achieve that:
- Drop corresponding DLLs into the extracted Vim distribution, i.e. the same
- Add paths to directories containing corresponding DLLs to the
Of course in overwhelming majority of cases you should choose option 2 because
that's how computer-literate people customize their environment, right? But if
you are still at school and/or don't know what
PATH is, then I guess option 1
is fine, keep trying tho.
The next important thing to realize is that the targeted architecture of corresponding DLLs has to match the targeted architecture of the Vim distribution you chosen. In other words, if you have chosen 64-bit Vim distribution, then you should expose 64-bit corresponding DLLs to it. Conversely, if you have chosen 32-bit Vim distribution, then you should expose 32-bit corresponding DLLs to it. Why? Because memory addressing models (which are defined by targeted architectures) of statically/dynamically linked binary components must match, otherwise there is binary incompatibility and BOOM! The universe folds back on itself... Don't do this at home... No, seriously, you were warned!
Finally, all programming languages for the supported (by these Vim distributions) scripting interfaces employ natural and widely accepted triad versioning scheme:
<version> = <major>.<minor>.<patch>
Changes in the interface can only occur when the
<major> and/or the
numbers are incremented, i.e. backward compatibility is broken, while
increments in the
<patch> number preserve backward compatibility. What this
means for you is that you should not care about what is the
<patch> number of
corresponding DLLs you expose to Vim. For instance, you can freely
(independently of your current Vim distribution) upgrade/downgrade corresponding
DLLs as long as changes occur only in the
<patch> number, while the
<minor> numbers remain complying with the ones your current Vim
distribution expects. Also, if you recall how, for example, Python (Lua, Perl)
DLLs are named, i.e.
python34.dll, then you'd
see that all the aforementioned suddenly makes sense again.
NOTE: The only exception here is Ruby, which corresponding DLLs always contain the
<patch>number in their names as well (see Ruby).
<major> and the
<minor> (and the
<patch> in case of Ruby
only) numbers of required versions for corresponding DLLs are listed in
Downloads and appear in names of archives, you can
still find out which versions are required by your current Vim distribution from
gvim.exe directly by simply typing
:version. Look to the
bottom of the received message and you should see something similar to:
Dependency: python27.dll, python34.dll, x64-msvcrt-ruby200.dll, lua52.dll, perl518.dll, libintl.dll, libiconv.dll, iconv.dll
Now this tells you exactly which versions of corresponding DLLs your current Vim distribution expects. Pay attention to the memory addressing model as well, for example:
MS-Windows 64-bit GUI version with OLE support
reminds you that your current Vim distribution is targeted at x64 architecture, and you have to expose corresponding DLLs targeting the same x64 architecture accordingly.
NOTE: These Windows MSI installers will put Python DLLs into system directories:
which are included into the
PATHenvironment variable by default. Therefore, you don't have to do any additional manipulations to expose Python DLLs to your Vim distribution because everything should already work out of the box.
To test whether Python 2 works properly with your current Vim distribution, type:
:py import sys; print(sys.version)
To test whether Python 3 works properly with your current Vim distribution, type:
:py3 import sys; print(sys.version)
NOTE: Pay attention to the fact that for the Ruby scripting interface the
<patch>number of the corresponding DLLs matters and has to match your current Vim distribution expectations (see Downloads).
To test whether Ruby works properly with your current Vim distribution, type:
:ruby print RUBY_VERSION
To test whether Lua works properly with your current Vim distribution, type:
To test whether Perl works properly with your current Vim distribution, type:
If you are interested which toolchain I use to build Vim for Windows as well as other native software for Windows in general, then I'd be glad to say that I'm using MinGW-w64 (not MinGW!) which is a production quality toolchain, bringing bleeding-edge GCC features to Windows for both x86 and x64 architectures.
|x64||x86||Vim||Python 2||Python 3||Ruby||Lua||Perl|
|x64||x86||Vim||Python 2||Python 3||Ruby||Lua||Perl|