The App Needed a Real Desktop, Not Just a Real Windows Machine

The App Needed a Real Desktop, Not Just a Real Windows Machine Before the debugging stories, gotchas, and architecture arguments in this series emerged, there was one earlier decision that set the stage for everything that followed. The system in question housed a Windows-only, GUI-first desktop application that required installation via a wizard and automation through a first-party SDK.

It had no web API or headless mode, designed solely for desktop use. The instinct was to run it inside a Windows compatibility layer on Linux, keeping it within cloud-native tooling and fitting the existing mental model. However, this approach proved unreliable. The automation layer intermittently failed to connect to the application, and the compatibility layer itself became unstable.

Eventually, the team abandoned this approach and ran the application on a real Windows machine. This solved the issue, but revealed a second requirement: the application's automation layer needed to run in an interactive, logged-in desktop session, not just on a real Windows machine. This is a common problem with Windows software that assumes a human is logged in, causing failures in headless or service-style contexts.

The key takeaway is that assumptions about software behavior can be limiting, and it's crucial to question whether a requirement truly meets the specific needs of the software. In this case, understanding that a real interactive desktop session was necessary, rather than just a real Windows machine, was essential for solving the problem efficiently.