I have updated the Win64 port of Vim.
It now includes a working installer,
a working "Edit with Vim" shell extension,
and the first 195 patches for Vim 7.0.
Get it while it's hot!
I have been cleaning up some issues with the Win64 port of Vim,
including the Edit with Vim shell extension not working very well.
When I built the shell extension with VS 2005 on x86, I would
get the following whenever I right-clicked in Explorer:
Microsoft Visual C++ Runtime Library
Runtime Error!
Program: C:\WINDOWS\Explorer.EXE
R6034
An application has made an attempt to load the C runtime library incorrectly.
Please contact the application's support team for more information.
There was no mention of which application was at fault,
though it was obvious in this case.
I have also seen some mention of verclsid in the error dialog,
though not when I took this snapshot.
The underlying problem relates to SxS, Fusion, and all that good stuff.
By far the simplest fix was for me to statically link with libcmt.lib,
instead of msvcrt.lib, rather than figure out the necessary
manifest magic.
In my post about Printf Tricks a couple of years ago,
I mentioned that "%n is dangerous and disabled by default in Visual Studio 2005."
I got email today from someone who was porting a large codebase to VS 2005.
He was getting an assert from %n and he needed a way to get past it.
He intends to fix the uses of %n when he has a chance.
I spent several minutes digging around in MSDN and came up with
set_printf_count_output. Wikipedia's Format string attack page
led me to Exploiting Format String Vulnerabilities, which
describes in detail how %n (and %s) may be exploited.
In short, if you have printf(unvalidated_user_input),
instead of printf("%s", unvalidated_user_input),
then placing %n into unvalidated_user_input can
lead to printf writing arbitrary data into memory.
