Desktop Pet eSheep and the XML file that drives every animation

A sheep that walks down to the taskbar when you open a window

Desktop Pet recreates eSheep, the stray sheep that lived on Windows desktops in 1995. The joke in the project documentation is that the application is not a game, not a utility, and definitely not useful. Its only stated purpose is to keep a little pet on your screen. That is a fair description of the ambition, but it understates the mechanics, because the pet does not just sit in a corner of the desktop.

The pet can fall down to the taskbar, and it detects windows on your desktop. From that it walks, runs, and explores the workspace, including across multiple monitors. So the interesting part is not the sprite art, it is the behaviour model: an autonomous little character that reacts to what you are doing with your machine and moves on its own. Whether that is charming or irritating after twenty minutes of work is a matter of taste, and the answer changes for everyone.

The audience splits into two groups. The first is nostalgic: people who remember the original and want it back on a modern desktop. The second, and probably more interesting for engineers, is the set of people who want to build pets of their own. The project treats the pet as data, and the whole architecture follows from that choice.

animations.xml is the format, and the format is the API

With a simple XML file called animations.xml it is possible to change the pet and its animations. That single sentence carries most of the design. A pet is not a compiled resource buried in the exe; it is a set of animation definitions read from disk, so replacing one changes what appears on your desktop without a rebuild.

The repository layout backs this up. A Pets directory holds one folder per pet, and the project page links each of them individually, with eSheep itself in Pets/esheep64, colour variants in Pets/blue_sheep, Pets/green_sheep, Pets/orange_sheep, Pets/pink_sheep, Pets/purple_sheep, Pets/red_sheep and Pets/yellow_sheep, and characters including Bunny in Pets/bbunny, Asuna in Pets/negima, Neko in Pets/neko and Pingus in Pets/pingus. The src directory holds the application, Resources holds shared assets, and Tools holds the authoring utilities. The topics listed for the repository are desktop, ehseep, mate and xml, which is an accurate summary of the project in four words.

The consequence for an integrator is straightforward. If you can write XML describing frames, you can ship a new pet. If you can serve XML to a browser, you can run the same pets on a web page, and that is exactly what the JavaScript version does. The format outlives any one host, which is why a 1995 sheep is still the one people port.

Getting the Windows build: portable exe, store package, or both

There is no package manager entry and no install script in the project, so the route to a running pet is the download page. The Windows portable build is the primary distribution. It is compiled with .NET 4.7, it is a single exe, and the project states that it works on every 64-bit Windows, with a table listing Windows 7, 8, 9, 10 and 11 and version 1.6.0 updated in october 2026.

The workflow after downloading is short. Run the exe, then choose whether to install the application locally so it starts with the system, or leave the exe where you want it. The project insists that this EXE is compiled from the main project and is always the most recent, which is the reason to prefer it over a store copy that lags behind.

Two other Windows options exist. The Windows 10 store version is listed as 2.6.160, which the documentation maps to the 1.6.0 release, and it is a new version that removed all UA and UWP parts from the older build, since Microsoft allows native .NET applications in the store. The store project keeps only the installer project that creates the MSIX package, and you can build and install it locally.

For a first run on Windows, take the portable exe, put it somewhere permanent if you want autostart, and open animations.xml in the pet folder afterwards to see what you can change. The pet directory and the XML file are where customization happens, not in the application.

Four ports at four different versions, and the gap is the story

The version numbers across platforms are the most informative fact in the project. Windows portable is 1.6.0, the Windows 10 store build is listed as 2.6.160 and corresponds to 1.6.0, the Android store app is 1.4.0, the macOS build is 1.4.0, and the browser version is 1.2.6 with a last update of may 2021.

So the pets run everywhere and the feature set does not. The macOS version is not even a port of the current code: the documentation credits iappyx with creating it in Swift and AppKit, and says plainly that you have to build it on your system because there is no download. The browser version is described as really limited, while still able to show and animate every pet in the repository. The Android version is described as a simple port based on version 1.4.0, with a nostalgic Windows 95 look.

This is a real design constraint of the project rather than a flaw in a single binary. A pet format shared by five hosts is a strong idea, but each host needs its own rendering, input and window awareness code, and those implementations have clearly drifted. If you are evaluating the project as a cross platform pet, you are evaluating four different codebases of different vintages.

The repository itself is not archived, and the last push was on 2026-10-15. Recent releases come quickly: v1.6.0 on 2026-10-09, v1.5.0 on 2026-10-01 and v1.4.0 on 2026-09-02. The cadence is high, but as the version spread shows, the pace is applied to the Windows line, not to every port at once.

The Android port ships two pets and the signing is still pending

Two limits deserve to be stated plainly rather than discovered later.

The first is content. The Android port contains only 2 pets for the moment, with the promise that in future all GitHub pets will be integrated. That promise is a roadmap item, not a fact you can rely on today, and it means the widest list of pets is on the desktop, not on the phone.

The second is code signing. The project is applying to the SignPath Foundation program, which provides free code signing with a certificate from SignPath Foundation, and the artifacts are generated by a GitHub action, with the stated effect that SmartScreen messages and antivirus alerts no longer appear. The status line, however, reads Waiting for release-certificate. Signing is pending, so the reassurance in that section is about the intended end state rather than the current state of every download.

Neither of these blocks the core use, which is running a pet on your own machine. Both matter if you distribute the executable to other people, which is exactly the audience a nostalgia project tends to attract.

The Pet Editor is the alternative to hand-writing XML

The genuinely interesting alternative to this project is not another desktop pet, it is authoring a pet by hand in the XML. The project supports that path with a small set of tools, and describing them is more useful than listing rival toys.

The Pet Editor is a Windows application described as the official editor to create new pets using a spritesheet, and it is distributed from the same releases page as the main program. The Minecraft Generator is a web page where you select an avatar, generate a spritesheet and download the animation. Alongside those sit collections rather than tools: spritesheet sources at spritedatabase.net, the spriters-resource and deviantart, and editors such as piskelapp and graphicsgale.

So the pipeline is: find or draw sprites, cut them into a spritesheet, describe the frames in animations.xml, drop the pet into the Pets directory, and the application picks it up. The editor saves you from hand authoring frame rectangles, but the XML remains the contract, and the generator makes the contract easy to satisfy for a specific case rather than a general one.

This is also where the browser port earns its place. Because the animations live in XML, a web page can integrate the same sheep with a simple JavaScript snippet. The documentation describes that version as limited, and it is, but it proves the format is portable in the strict sense.

What a repackaged sheep does not solve

It is worth being blunt about what this project is not. It is not a productivity tool, and the project documentation says so first. It will not speed up a workflow, it does not integrate with anything on your machine beyond the windows it notices, and there is no documented way to make it do something useful.

The engineering value is in the format, not the creature. A pet defined by a readable XML file that you can generate from an image, ship in a repository, and render in a Windows application, an Android app, a Swift app and a browser page is a small, complete asset pipeline with a real cross platform exercise in it. If you are evaluating the project for that reason, the version spread across the ports is the number that matters, not the fact that the sheep is cute.

The MIT licence covers the repository, so the code and the pet assets can be reused and modified in your own application, subject to keeping the licence notice. That is the practical route if the upstream Windows build does not fit: take the XML, take the sprites, and host them in your own program.

Editorial conclusion

Desktop Pet fits people who want a nostalgia pet on a Windows 11 desktop and, more usefully, developers who want a pet format that is a readable XML file rather than a binary asset bundle. It is the wrong choice if you need a cross platform pet today, because the Android and macOS ports sit at 1.4.0 while Windows is at 1.6.0, and the browser version at 1.2.6 has not been touched since may 2021. Before you install anything, check that the exe you download is the portable Windows build, confirm the pet you want is present in the Pets directory, and read animations.xml, because that file, not the binary, is what decides how the pet looks and moves.

Frequently asked questions

Official sources

1. Adrianotiger/desktopPet on GitHub
2. License: MIT
3. Project website
4. README
5. Releases