ImDisk: a Windows virtual disk driver whose design stopped in 1994

What the driver emulates

ImDisk is a virtual disk driver for Windows that emulates hard disk partitions, floppy drives and CD/DVD-ROM drives. The backing store is one of three things: disk image files, virtual memory, or redirected I/O through a cooperating service or proxy server.

That third option is the one that distinguishes the design. Because the I/O does not have to live in a local file, a virtual disk can be served from a machine on the network, with ImDskSvc forwarding the traffic over TCP/IP or serial connections, and devio providing the native server side.

The repository is organised as a set of components with a clear division of responsibility. The sys directory holds the kernel-mode driver, imdisk.sys. The cli directory holds the command-line tool, imdisk.exe. The cpl and cplcore directories hold the Control Panel applet and the core native API library behind it. The svc directory holds ImDskSvc, the helper service that forwards proxy I/O over TCP/IP or serial connections, and devio is the native server for ImDisk proxy operation. ImDiskNet is a set of VB.NET projects holding the ImDisk API wrapper, the DevioNet client and server library, and DiscUtilsDevio image-format integration.

The main source is C, the licence field on the repository is classified as a custom one, and the repository has no GitHub releases. The last push was on 2026-09-24.

The compatibility warning is the first thing to read

The project states plainly that ImDisk uses a legacy design and is not recommended for recent versions of Windows, that its design preserves compatibility with systems as old as Windows NT 3.51, and that many applications written for Windows Vista and later require features it does not provide.

It then draws a line between maintenance and design. No new features are planned for the repository. Maintenance has continued, and the May 2026 changes include a driver bug fix, installer and signing updates, and an ImDiskNet update. The README is careful that none of this removes the design limitations on modern Windows, including Windows 10 and 11.

The historical testing record is listed too: 32-bit Windows NT 3.51, NT 4.0, 2000, XP, Server 2003, Vista, 7, 8, 8.1 and 10, and x86-64 Windows XP, Server 2003, Vista, 7, 8, 8.1 and 10. The README immediately qualifies it, saying this is a record of past testing and not a statement that every current build supports every listed system, which is the kind of caveat that separates a compatibility claim from a compatibility list.

Feature development by the original author has moved to Arsenal Image Mounter, which emulates complete disks and works in many scenarios where applications expect physical disks. The README frames the relationship as complementary rather than a replacement: ImDisk remains available for older systems and specific uses that fit its partition and volume level design.

Where the driver files moved to

The AWEAlloc and DevIoDrv components were removed from this repository in May 2026, and their source now lives in Arsenal Image Mounter.

That removal has a practical consequence for anyone following an old setup guide. The driver files can be installed with Arsenal Image Mounter, including its free versions, and those versions of awealloc.sys and deviodrv.sys can also be used with ImDisk. Older instructions may still refer to an AWEAlloc copy bundled with ImDisk, and the README says to obtain that driver from Arsenal Image Mounter instead.

So the picture for a new user is a split. The ImDisk driver, the command line tool, the control panel applet and the service come from this project, while the AWEAlloc driver that provides the AWE allocation capability now comes from the other project. Since AWEAlloc is what allows allocation on 32-bit Windows, where the address space is the limiting factor, that is not a trivial component to lose.

The README also notes that historical NT 3.51 install and uninstall routines require manual registry setup or resource-kit tools, and that ARM and ARM64 installations also require manual setup, pointing at an ARM64 setup guide and the AWEAlloc migration note.

The community forks carrying the modern work

The README lists three forks that it says have substantive changes in 2026, checked in September 2026, and it is explicit that each fork's own documentation and releases are the place to check current status, supported Windows versions and installation instructions.

The DavidXanatos fork adds Windows Mount Manager integration to address Windows 11 24H2 compatibility, automatic device removal if a user-mode proxy crashes, and subsequent Windows 10 and app-package compatibility fixes. It targets x64 and ARM64. The automatic device removal is the interesting one, because it addresses a failure mode where a crashed proxy leaves a virtual disk device attached, and a modern Windows version will not let you remove it through the usual path.

The lxl66566 fork builds on that one and adds a path that completes eligible RAM disk reads and writes directly in the calling thread, plus fixes for byte-swapped writes, zero-buffer detection and I/O control buffer validation. Doing the work in the calling thread removes a copy from the proxy path, which is where a RAM disk's throughput advantage is usually lost.

The shadowjohn fork takes a different approach and adds a WPF management GUI with built-in disk benchmarks, configurable automatic saving to image files, and controls for expanding mounted RAM disks. Its GUI uses the original ImDisk driver binaries, which is a useful data point about how much of the driver is still usable as-is.

The pattern across the three is instructive. The upstream repository is doing compatibility and packaging maintenance, while the interesting engineering, the modern Windows integration, the performance work and the user interface, is happening in forks.

Installing and running the components

The install path runs through the distribution rather than the source checkout, and the README is precise about that: use the distribution from the project website, and the installation instructions apply to an extracted distribution containing the built driver, service and tools, rather than just this source checkout.

Given that distribution, installing the components means right-clicking imdisk.inf and selecting Install, and uninstalling means using Add/Remove Programs in Control Panel. Running the command-line tool with no parameters prints the syntax, so the first thing to do after installing is:

imdisk

The FAQ covers RAM disks, image files, proxy operation and mount points.

So a first use goes like this. Download the distribution, extract it, install the driver through the INF file, and then use the imdisk command line tool or the control panel applet to create a virtual disk and mount it. The command line tool without arguments gives you the syntax to work from, which is the piece of the documentation you actually need at the start.

The proxy mode is the more involved setup, because it needs the service on one machine and the devio server on the other, and the README does not walk through it beyond pointing at the FAQ.

The repository top level shows the older Windows build era in its filenames: 7zS.sfx and 7zSDcfg.txt for the self-extracting distribution, imdisk.props with light, dbg and imp variants, and a set of property sheets for older WDK versions including wdk7_wnet_x64.props and vs2013_sse.props. Those are the older Visual C++ toolsets, WDK 8.1 and 10 driver configurations and WDK 7 property sheets, and the root Makefile is for the older WDK build environment and distribution packaging.

Where ImDisk is the wrong choice

The first limitation is stated by the project itself and there is no way to argue around it: this design does not work well on modern Windows. If you are deploying to Windows 10 or 11 today, the project tells you not to, and the fork table shows that the people maintaining it are addressing the gaps rather than arguing they do not exist.

The second is that the project's own successor is better for most modern work. Arsenal Image Mounter emulates complete disks rather than partitions, which is what applications that expect physical hardware actually want, and it is where the original author is putting new features. If you are starting fresh rather than maintaining something, the choice is not ImDisk or a fork, it is ImDisk or Arsenal Image Mounter.

The third is the build environment, which is a real barrier for anyone wanting to modify the code. The native projects need a Visual Studio with older toolsets plus WDK configurations that Microsoft has since moved on from, and the project files still reference them. The Makefile is for the older WDK build environment and expects environment variables to be set for the architecture, with an explicit error if the build architecture is not defined for WDK 7.x or earlier. The managed side is more current, targeting .NET 8, 9 and 10 alongside older .NET Framework targets, but the managed targets do not change the Windows driver requirements.

There is also a licensing dimension worth checking. The licence field on the repository is classified as a custom one that GitHub cannot classify, and the README points to LICENSE.md for copyright notices, licence terms and information about alternative commercial licensing. For a driver that has been in service since the 1990s and is installed into the kernel of other people's machines, the terms deserve reading rather than assuming.

The fair comparison is with the built-in tooling. Windows has a RAM disk feature in some editions, and the Hyper-V and VHD attach machinery covers the image file case for most purposes. What ImDisk still offers that those do not is the partition-level granularity, the floppy and CD emulation, and the proxy mode, and on a system old enough to need them, that is the whole value.

Editorial conclusion

ImDisk fits a lab or virtualisation workflow that needs a RAM disk or an image-mounted volume on an old Windows system, or a specific partition-level use case the newer tools do not cover. It does not fit a modern Windows 10 or 11 deployment, by the project's own statement. Before deploying it, read the compatibility section rather than the feature list, check which community fork matches your Windows build, remember that the driver, the control panel applet and the command line tool are separate components installed from an INF file, and confirm that the AWEAlloc driver you need now comes from Arsenal Image Mounter rather than from this repository.

Frequently asked questions

Official sources

1. Issues
2. LTRData/ImDisk on GitHub
3. README