AltSnap: Alt+Drag Window Moving and Resizing on Windows

The problem AltSnap solves for Windows users

On most Linux desktops, holding Alt and dragging anywhere inside a window moves it, and Alt plus a right-drag resizes it. Windows has never offered this. The title bar is the only reliable drag handle, and on a maximized or high-DPI window the title bar can be a thin strip that is easy to miss. AltSnap exists to close that gap. The README states plainly that the behaviour "is very common on Linux distributions and is not actually hard to implement on Windows."

The audience is broad on paper and narrower in practice. The README says the project is "oriented towards all Windows users from Windows NT 4 to Windows 11, even though it is mostly tested on Windows XP and Windows 10." That testing note is worth taking literally. NT 4 and Windows 11 are supported targets, not equally exercised ones. If you run an unusual Windows configuration, you are relying on the code path working rather than on the maintainer having recently walked it. AltSnap is a fork of Stefan Sundin's AltDrag, and the README warns that the original documentation is "not 100% accurate because it is a fork," pointing readers to the changelog instead.

How AltSnap hooks input without injecting into other processes

AltSnap keeps a low-level keyboard and mouse hook inside its own process. When you press Alt and then click, the hook sees the input before the target window does, and AltSnap repositions or resizes the window under the cursor itself. The repository layout reflects this split: hooks.c and hooks.h handle input capture, snap.c handles window snapping, zones.c handles screen zones, tray.c handles the notification area icon, and config.c handles settings. The entry point is altsnap.c.

The architectural decision that separates this fork from AltDrag is what happens next. The README states that the Hooks windows feature was removed, and describes it as code that "required however to inject a dll in every application and induced thus an obvious security risk." AltDrag also needed a 32-bit and a 64-bit process running side by side for that feature. AltSnap does not inject anything, so a single build covers both architectures. That is the trade the project made: less code, one process, no per-application DLL, and no window snapping during ordinary (non-Alt) drags.

A second removal is focus on typing, which the README says was "too much unusable for me to even start testing, so I removed it." Both removals are subtractive. AltSnap is not a superset of AltDrag; it is a re-cut with different edges.

Installing AltSnap and moving a window on first run

The README does not give end-user install steps. It gives build steps, and the repository ships altsnap.nsi, an NSIS installer script, plus altsnap.exe.manifest. In practice you obtain AltSnap from the project's GitHub releases rather than compiling it. The README does not document a package-manager install, though it mentions Chocolatey only in the context of VirusTotal verdicts.

If you build from source, the README specifies gcc plus MinGW-w64 and says the maintainer uses TDM-gcc 10.3. The top-level Makefile is the 32-bit Win32 target:

make

That produces the i386 Win32 GCC build. For a 64-bit binary the repository provides a separate makefile, which the README documents as:

make -fMakefileX64

Note the missing space between -f and the filename. That is how the README writes it, and it is how the file is named: MakefileX64 with no extension. There are parallel targets for Clang (MakefileClang), tcc (MakefileTCC), and an ARM64 build through Docker (MakefileARM64Docker), the last of which has its own BUILD_ARM64.md. For Visual Studio, the README points at mkmsvc.bat.

Once running, the interaction is the whole product: hold Alt, press the left mouse button anywhere in a window, and drag. The window follows the cursor. Alt plus a right-button drag resizes. The README notes that some options are only reachable by editing AltSnap.ini, and that you open it by middle-clicking the tray icon. That is the first thing to check after install, because the options dialog does not expose every setting.

What you give up compared with AltDrag

The clearest limitation is stated by the project itself. Removing the Hooks windows feature means AltSnap cannot snap windows while you drag them normally, with the mouse alone and no modifier key. If snapping on a plain title-bar drag is part of your workflow, this fork does not do it, and no configuration key brings it back. You would need AltDrag for that.

Focus on typing is gone too. The README is blunt that the maintainer found it unusable and removed it rather than fix it. Anyone who relied on that behaviour has no migration path inside AltSnap.

The third limitation is documentation drift. The README links to the original AltDrag documentation and then says it is not fully accurate for this fork. A user reading the upstream docs will find features described that AltSnap no longer has. The project directs you to the changelog and the Wiki instead, which means the authoritative reference is a moving document rather than a stable manual. For a desktop utility that mostly matters at the edges, but the edges are exactly where AltDrag users will look.

Finally, antivirus noise. The README devotes a section to VirusTotal false positives, naming SecureAge APEX and saying the maintainer stopped contacting that vendor every release. The README also notes that Chocolatey treats up to five positives on VirusTotal as not even suspicious. This is a real friction point on managed machines, where an endpoint agent may quarantine the binary regardless of what the README says.

AltSnap compared with AltDrag and with Linux window managers

AltDrag is the direct ancestor and the obvious alternative. The difference is not cosmetic. AltDrag injects a DLL into every application to support Hooks windows snapping, and consequently ships as both a 32-bit and a 64-bit program running simultaneously. AltSnap removes the injection, which removes the dual-architecture requirement and a class of security concern, at the cost of the snapping feature and the focus-on-typing behaviour. If your reason for using AltDrag is snapping during ordinary drags, AltSnap is a downgrade. If your reason is Alt+drag moving and resizing, AltSnap is the same idea with a much smaller surface area, and the README claims it also "fixed a ton of undesired behavior and bugs from the original AltDrag."

The other comparison is with the Linux desktops that inspired the tool. There, Alt+drag is implemented by the window manager itself, so it composes with tiling, workspaces and compositor effects because it is the same code path that manages windows. AltSnap sits outside the Windows window manager and manipulates windows from a hook. It cannot integrate with Windows snapping the way a compositor integrates with its own drag logic, and the Hooks removal is a direct consequence of that position. AltSnap is a convincing imitation of a window-manager behaviour, not a window manager.

Maintenance, licence and build cost

The repository is not archived and the last push was on 2026-09-16. Release 1.68 landed on 2026-07-04, following 1.67 on 2025-11-14 and 1.66 on 2025-09-21. That cadence suggests a project that ships when there is something to ship rather than on a schedule, with roughly two releases a year in the recent record.

The licence is GPL-3.0, and the repository carries License.txt. For an end user running the binary, that is unremarkable. For anyone embedding AltSnap in a product, the copyleft terms apply to distributed derivative works, and the practical consequence is that you would need to release the corresponding source under a compatible licence. That is a general property of GPL-3.0, not legal advice for your situation.

Upgrade cost is low by design. The program is a single C codebase with no injected components, so there is no per-application state to reconcile between versions. The thing to watch on upgrade is AltSnap.ini, because the README says some options exist only as ini keys. A new release can add keys that the options dialog does not surface, so diffing the ini against the changelog is more useful than clicking through the dialog. Building from source is a heavier commitment: the README lists separate makefiles for i386, x86_64, Clang, tcc, ARM64 under Docker, and Visual Studio, and each is a distinct target rather than a flag on one.

Editorial conclusion

AltSnap suits Windows users who want Linux-style Alt+drag window control without a DLL injected into every running application, and it is the right pick for anyone on a 32-bit or ARM64 Windows install where a single-architecture build matters. Skip it if you depend on AltDrag's Hooks windows snapping or its focus-on-typing behaviour, because the README states both were removed. Before adopting it, verify the current release on the project's release page, then confirm the ini file path and the blacklist keys in AltSnap.ini, since the README notes that some options are only reachable by editing that file rather than through the options dialog.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. RamonUnch/AltSnap on GitHub
4. README
5. Releases