VxKex: running modern Windows apps on Windows 7 by rewriting import tables

The mechanism, which is two registry keys and an import table

The README explains the whole design in a few sentences, and it is worth reading closely because it explains why the tool is as contained as it is.

VxKex works by loading a DLL into each program where it is enabled, and it accomplishes that through the IFEO registry key, the Image File Execution Options registry key. Specifically, the VerifierDlls value is set to point to a VxKex DLL, and that DLL then loads into the process. This is a per-executable opt-in mechanism that the operating system applies at launch, which is why nothing needs to be running beforehand.

The second half is where the compatibility comes from. API extension is accomplished by editing the program's DLL import table, so that instead of importing from Windows 8, 8.1 or 10 DLLs, the program imports to VxKex DLLs instead. Those VxKex DLLs contain implementations of Windows API functions introduced in newer versions of Windows.

Two things follow from that architecture. A function that does not exist in Windows 7's DLLs but does in Windows 10's is exactly the kind of thing this fixes, which is why the release notes for 1.2.0.2222 lead with TLS 1.3 support and additional TLS 1.2 cipher suites for Schannel-based applications. And a program that does something VxKex has not reimplemented, such as calling an unusual entry point, is exactly what it cannot fix, which is where the compatibility list comes in.

Enabling it per program, not per system

Usage is deliberately mundane. You right click a program, either an .exe or an .msi, open the Properties dialog, select the VxKex tab, and check the box that says Enable VxKex for this program. Then you try to run it. That is the whole loop, and the per-program scope is the important part.

Some programs need additional configuration, and the README says where to find it: a file called Application Compatibility List.docx inside the VxKex installation folder, which is C:\Program Files\VxKex by default. The README's own framing is that for most part, all configuration is self-explanatory, which is a reasonable expectation given that the extra steps are things like enabling a specific toggle for a specific application.

Console applications are handled the same way, and the README answers that question directly: yes, once you have enabled VxKex for a program you can use it through the command prompt as normal. That is what makes the tool usable on a server rather than only on a desktop you can click through.

Getting the software is a releases page visit. The README's instruction is to download and install from the releases page, and if you are a developer the source code is provided as a 7z file on that same page rather than as a normal source tarball. The repository tree confirms this is a Visual Studio solution, with VxKex.sln at the root and a Build VxKex.bat, so the components are compiled Windows binaries with a batch build rather than something you would run through a Linux toolchain.

What the repository tree reveals about the scope

The tree is the clearest evidence of how much work this project is. There are numbered categories that read like a build order: 00-Common Headers, 00-Documentation, 00-Import Libraries, 01-Development Utilities, 01-Extended DLLs, 01-Tests, 02-Prebuilt DLLs and 02-Prebuilt Data.

Named projects sit alongside them. KexDll is the core extended DLL, KexCfg is the configuration component that drives the properties dialog, and KexGui is the user interface. KexKMSD, KexMLS and KexW32ML are the pieces most likely to relate to the kernel-mode and licensing-adjacent API surface that Windows 7 applications check for. KexPathCch and KexShlEx cover path handling and shell extension APIs, KexSmp and VxlView are supporting utilities, KxCfgHlp is configuration help, and VxKexLdr is the loader.

That directory listing explains the release notes better than the notes themselves do. When a release says it added support for applications requiring UiaDisconnectProvider or UiaDisconnectAllProviders, you are looking at a DLL that reimplements a UI Automation entry point, and the fix in 1.2.1.2229 for applications calling UiaDisconnectAllProviders failing to launch is exactly that kind of narrow gap. The presence of 01-Tests and 02-Prebuilt Data also explains why applications get named one at a time: someone tested them.

The repository carries 143 open issues and the last push was on 2026-07-21, one day before the most recent release tag. It is not archived, and it is being worked on.

The release notes read like a compatibility changelog

Version 1.2.0.2222, published 2026-07-21, is described as the biggest jump in functionality since the last several point releases, moving from the 1.1.x line to 1.2.x. Three changes are called out. TLS 1.3 support along with additional TLS 1.2 cipher suites, so Schannel-based applications can connect to modern websites that have dropped older configurations, which the notes describe as a growing pain point as the web moves on from older protocols. ANSI escape sequence support in console applications, so Python, Deno, Node.js and other console tools render colors and formatting instead of showing garbled escape codes. And a fix for mouse input problems affecting a range of Unity-based games, restoring mouse support in Hollow Knight: Silksong, Haste and other Unity titles.

Version 1.2.1.2229, published 2026-07-22, is a follow-up a day later fixing two startup failures: games built with Godot failing to start when run as Administrator on systems with Intel graphics, and applications calling UiaDisconnectAllProviders failing to launch, which the notes say fixes startup issues in recent Unity games. It also fixes garbled console output when multi-byte characters combine with ANSI escape sequences, Chromium versions newer than 149 closing immediately on systems missing certain updates, and the Open in Registry Editor button in the VxKex property tab remaining greyed out under UAC.

Version 1.1.5.1679, published 2026-05-08, is a visual and compatibility release: High-DPI scaling fixes for Chromium and Qt6 applications, desktop notifications restored in Chromium, Qt6 support extended to versions relying on ICU libraries through icuuc.dll, and Unity engine support covering Yandere Simulator and Touhou Hero of Ice Fairy. It also adds support for some Themida-protected applications with KakaoTalk confirmed working, and partial support for LINE Messenger.

Every one of those is a specific application failing in a specific way. Reading the three releases together, the pattern is that this project's progress is measured in programs that now start.

The honest contradiction between the FAQ and the release notes

The README's own FAQ contains a statement that the release notes contradict, and the contradiction is worth surfacing rather than smoothing over.

Asked whether it works for games, the README answers that at the moment VxKex is not intended for games, so you will probably have limited success, and the author hopes to address that shortcoming in a future release. Yet the 1.1.5 release notes add Unity engine support for two specific titles, and 1.2.0.2222 announces restored mouse support in Hollow Knight: Silksong and Haste, and 1.2.1.2229 fixes Godot-built game startup. The README's supported list also includes games, with Life is Strange: True Colors and osu!lazer among them, and notes that Yuzu gameplay was not tested.

The most charitable reading is that the README's FAQ predates a substantial run of game support work, and that game support remains partial and per title rather than general. The practical consequence for a reader is the same either way: do not plan on games working, but do check whether your specific title is named, because the answer has been changing release by release.

The same list has a useful pattern in it. The majority of Qt6 applications will work and many Electron applications will work, by the README's account, which tells you where the leverage is: two large application frameworks that share a common API surface, so one set of extensions covers a lot of ground. Python, Firefox, Chromium, VSCode and VSCodium are in the list, and Zig, Dasel and Steel Bank Common Lisp are there too. The README also says the list is not exhaustive.

Editorial conclusion

VxKex solves a problem with a very specific shape: a machine that must stay on Windows 7, and software on it that was built for something newer. If that is your situation, the mechanism is sound and unusually clean, since per program opt-in through the properties dialog and a documented absence of global hooks or background services means you can disable it per application. If you are choosing an operating system rather than being stuck with one, it is the wrong answer, because it works by faking API compatibility rather than by fixing anything. Two things to verify before you rely on it. First, Service Pack 1 is a hard requirement, and the README notes many programs also need KB2533623 and KB2670838 installed. Second, the documented application list is what the author could personally test, and the release notes for 1.1.5 make the same point, that improvements in a new version usually benefit a broader range of software than the changelog lists. Read Application Compatibility List.docx in the installation folder for the specifics of your program rather than assuming from a name on the list.

Frequently asked questions

Official sources

1. i486/VxKex on GitHub
2. Issues
3. README
4. Releases