AppleWin and the Apple II card layer it refuses to drop
Apple II emulator for Windows
At a glance
- What is it?
- AppleWin is a Windows emulator for Apple II hardware that goes as deep as peripheral cards, video standards and a symbolic debugger, but it still stops well short of the //c and the IIgs. It suits people who need the plug-in cards rather than the machine itself.
- Who is it for?
- Adopt AppleWin if you need the peripheral cards, the NTSC and RGB paths or the built-in symbolic debugger rather than a general Apple II machine. Skip it if the //c, the Laser 128 family or the IIgs matters, since none of those machines are emulated, and if you are not on Windows, because the official build target is Visual Studio for Windows and the Linux and macOS ports are unofficial.
- Can I use it commercially?
- Yes, with conditions. GPL-2.0 is a copyleft licence: if you distribute software that includes it, you must release that software's source code under the same licence. Running it internally without distributing it does not trigger that obligation.
- Is it still maintained?
- Yes. The repository last received commits 2 days ago.
- What is it written in?
- Mainly C, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 23, 2026, and from our analysis. They are not legal advice.
Editorial analysis
Apple II models emulated, and the machines deliberately left out
AppleWin describes itself as an Apple II emulator for Windows, and the model coverage is explicit rather than open ended. The list covers the original II, the II Plus, the original //e and the enhanced //e, plus a set of clones named Pravets, TK3000 and Base 64. What is missing matters more than what is present for some users. There is currently no support for the //c, the //c+, the Laser 128, the Laser 128EX, the Laser 128EX2 or the Apple IIgs.
That single sentence removes a large slice of later Apple II software from reach. A disk image written for the IIgs, or a program that expects the //c's serial and mouse hardware, has no machine to run on here. The tag line on the repository is 6502, appleii, emulator, so the target is clearly the 8-bit era rather than the transitional models.
The stated goal is not a bare processor emulation. The documentation says AppleWin is a fully featured emulator supporting different Apple II models and clones, with a variety of peripheral cards and video display modes such as NTSC and RGB, and an extensive built in symbolic debugger.
The card list is the real specification of this emulator
The peripheral inventory reads like an expansion card catalog, and it is where the design effort of the project is visible. Sound is handled by the Mockingboard, Phasor and SAM cards. Storage comes through a Disk II interface for floppy drives and a hard disk controller. The Super Serial Card, a parallel printer card and a mouse interface cover the usual I/O expansion, and the Apple IIe Extended 80-Column Text Card plus RamWorks III with 8MB of memory extend the enhanced //e.
Video is not a single path. RGB cards include Apple's own Extended 80-Column Text and AppleColor Adaptor Card and the 'Le Chat Mauve' Féline, which is why NTSC and RGB are both listed as display modes. Networking appears as Uthernet I and Uthernet II, and the CP/M SoftCard is supported, which is how a period-correct CP/M environment is expected to be run.
Smaller details suggest the same attention. The list includes the Language Card and Saturn 64/128K for the II and II Plus, with Saturn 128K usable in any slot on any Apple II. Joystick support comes through the 4Play and SNES MAX cards, the VidHD card is present but its functionality is limited to the IIgs' Super Hi-Res video modes, and the Game I/O Connector copy protection dongles are emulated.
Getting a running copy, and where the build instructions stop
The documentation points at a downloadable stable release rather than a package manager entry, so the shortest path to a running emulator is a zip archive. The page names the stable build and its release notes.
Download latest (stable) release: [AppleWin v1.32.0.0](https://github.com/AppleWin/AppleWin/releases/download/v1.32.0.0/AppleWin1.32.0.0.zip)Source builds are a separate matter. The build section does not spell out steps, it defers to a file in the repository.
* [docs/compiling.txt](https://github.com/AppleWin/AppleWin/blob/master/docs/compiling.txt)The top level of the repository backs that up with two Visual Studio solutions named for different toolchains, one for VS2022 and one for VS2026, and the main project is written in C. Third party libraries are vendored rather than pulled in by a manifest: the layout shows libyaml, minizip, zlib and spng directories, a ddraw_lib folder, and hardware specific subtrees such as snesmax and firmware.
That layout has a practical consequence. Building is a Visual Studio exercise on Windows, and the third party code travels inside the tree, so a fork inherits those versions rather than choosing newer ones.
The debugger input hook and a whole system input freeze
The symbolic debugger is described as extensive and is tied closely to the Windows host, which produces a specific failure worth knowing about before you rely on it. Under MSVC 2022, debugging can cause system wide input unresponsiveness. The cause is the input thread that the debugger installs for system keys.
The project publishes a command line argument that avoids it.
-no-hook-system-keyThe documentation points at three pieces of code behind this: g_bHookSystemKey, HookFilter::HookFilterForKeyboard() and HookFilter::HookThread(). That is a rare level of detail in a project README, and it tells you the hook is a deliberate subsystem rather than an accident.
Three workarounds are listed alongside the argument. Debug with MSVC 2026, debug with MSVC 2019, or manually use the older v5.01 Windows Common Controls. The alternatives all involve changing the toolchain or the control library, which is a heavier cost than passing one flag.
A Windows program with unofficial ports on Linux and macOS
The distribution story is deliberately uneven. The project is an Apple II emulator for Windows, and the build path points at Visual Studio solutions for Windows. Yet a section titled Unofficial Ports points at two community forks, one for Linux and one for macOS, described as allowing AppleWin to be built and run on other platforms.
The distinction matters for anyone on macOS or Linux. A macOS build means a fork rather than the upstream repository, so upstream fixes arrive on your schedule, not the maintainers. The word unofficial in the heading is doing real work.
The channel structure is also worth reading before you pick a build. Contributors are pointed at the CONTRIBUTING document before raising new bugs, features and especially pull requests, and the Next Version section lists the experimental build as pending, with new issues invited on the tracker.
Release cadence, old Windows floor and what the licence permits
The last push was on 2026-10-17, and the repository is not archived, so work is still landing. Recent releases include v1.32.1.0 on 2026-10-04, v1.32.0.0 on 2026-05-23 and v1.31.0.4 on 2026-04-18, which was tagged as a beta.
Older operating systems are handled by freezing builds rather than by a compatibility shim. The last version supporting Windows XP is v1.30.21.0, the last supporting Windows 2000 is v1.29.16.0, and the last supporting Windows 98 and ME is v1.25.0.4. Anyone running on those platforms is reading archived release notes, not the current tree.
The licence field on the repository says GPL-2.0, with the GNU General Public License text stored at the top level of the repository. For a GPL project, the practical questions for an engineer are what happens to modifications and what the licence requires when the emulator is distributed or shipped alongside other software. Those are obligations you read in the licence file itself, and anyone planning to embed or redistribute the emulator should check the terms there rather than assume.
Editorial conclusion
Adopt AppleWin if you need the peripheral cards, the NTSC and RGB paths or the built-in symbolic debugger rather than a general Apple II machine. Skip it if the //c, the Laser 128 family or the IIgs matters, since none of those machines are emulated, and if you are not on Windows, because the official build target is Visual Studio for Windows and the Linux and macOS ports are unofficial. Before committing, open the card list in the README and check that the specific expansion your software depends on is present, and confirm that the release you download still matches the Windows version you run, since support for Windows 98, 2000 and XP ended in separate older builds.
Frequently asked questions
Does AppleWin support the Apple IIc or the Apple IIgs?
No. The project states there is currently no support for the //c, the //c+, the Laser 128, the Laser 128EX, the Laser 128EX2 or the Apple IIgs. The VidHD card is listed, but its functionality is limited to the IIgs' Super Hi-Res video modes.
How do I build AppleWin from source?
The README points at docs/compiling.txt for compiling for Windows from source, and the repository carries Visual Studio solutions for VS2022 and VS2026. The main project is written in C, with third party libraries such as libyaml, minizip, zlib and spng vendored in the tree.
What is the last AppleWin version that runs on Windows XP?
The last version supporting Windows XP is v1.30.21.0. Earlier platforms are also frozen: v1.29.16.0 is the last for Windows 2000, and v1.25.0.4 is the last for Windows 98 and ME.
Why does debugging in AppleWin freeze system wide input under MSVC 2022?
The debugger installs an input thread for system keys, and under MSVC 2022 that can make the whole system unresponsive to input. Passing the command line argument -no-hook-system-key prevents that thread, and the project also suggests debugging with MSVC 2026, with MSVC 2019, or using the older v5.01 Windows Common Controls.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/applewin-applewin)Was this useful?