Part 7 · Platform, hosting and artificial intelligence
Windows applications on Linux
What to do with a Windows application that has no Linux equivalent on a Blue Fox OS workstation: the five questions to ask in order, the four available routes, and what each one costs.
Almost every migration to Blue Fox OS runs into the same sentence: "everything would work, except that one program". A technical drawing application, accounting software from a local vendor, a tool imposed by a client's own supplier, an old database that has been running for fifteen years. This chapter explains how the decision gets made, in what order, and what each answer really costs. It is written for the person who decides about the fleet, not for the person who installs it: none of the four routes is put in place without us.
What the workstation already carries#
A Blue Fox OS workstation is an immutable system. Its contents are laid down as one block at each version, and anything added to it has to be maintained at every version that follows. So knowing what it already carries settles part of the question.
It carries a remote display client that speaks Microsoft's Remote Desktop protocol, version 3. An application living on a Windows host therefore appears on the workstation with nothing to install. It also carries what is needed to run containers.
It carries neither a Windows compatibility layer nor a hypervisor. Neither one is in the image, and adding them is a real change rather than a setting. That is why the order of the questions below is not arbitrary: the route that requires no addition is also the one that keeps the promise of the workstation, which is a system that reinstalls identically in twenty minutes and is never tinkered with machine by machine.
The five questions, in order#
The order matters. Each question ruled out costs more than the one before it, so the process stops at the first one that says yes.
- Does the application have a web version? Many vendors have been serving one for years without their customers noticing, because the desktop shortcut never changed. If the web version covers the work, the workstation has nothing to install and the question disappears. We declare it as a web application on your policy record, with its own icon, and it opens like a program.
- Does a Linux equivalent cover the actual work? The right question is not "does this software exist elsewhere" but "what does the person do with it during the day". A spreadsheet used to keep three lists can be replaced. The same spreadsheet carrying twenty years of macros cannot.
- Does the application run on a compatibility layer? A compatibility layer runs Windows software directly on the workstation, without Windows. It works application by application, and it gets verified before anything is promised: we try it on a test workstation, with your files, before saying yes.
- Can the application live on a single Windows host that the workstations display? This is the route we recommend most often once the first three say no. One place to license, to back up and to update, and the workstations stay free of Windows.
- Is there still a reason to keep Windows on the workstation itself? Three reasons hold up: a connected device that only the Windows driver recognises, use without a network, or a hardware licence key. Without one of those three, a local virtual machine adds nothing that the central host does not already provide.
The four routes#
The compatibility layer#
The application opens like a Linux application, in its own window, and its files are the files on the workstation. No Windows licence, no virtual machine to maintain, no server.
What it takes: a compatibility layer installed on the workstation, which we declare in your policy. A free version and a commercial version both exist, the latter at around 74 US dollars per workstation per year at the time of writing, which adds support from its publisher. Price and terms are confirmed at purchase.
The limits: it works application by application, and an update to the application can break what used to work. The publisher of your software does not support running it this way. We therefore keep this route for applications we have verified, and we say so when an update ships.
The application served by a Windows host#
The application runs on a Windows host and the workstation displays only its window. For the person working, the result looks like the previous route: a window beside their other windows, which resizes and prints.
What it takes: a Windows host somewhere. Three shapes come up, depending on size. A Windows machine you have already paid for, kept in a corner and left running, is enough for one or two people. A Windows server with its remote desktop service serves a team. A virtual workstation rented by the month from a provider, at around 28 to 56 US dollars per person per month depending on power at the time of writing, avoids running a server of your own.
The limits: the application depends on the network link, and every local device (label printer, card reader, scanner) is redirected case by case, which gets tested before any commitment. Licensing for a shared host is confirmed with a Microsoft reseller before any purchase, because the rules differ depending on whether you bring your own licences or rent them from the provider. And if the host is rented from one of the large providers, your data goes back to that provider, which may contradict the reason you chose Blue Fox OS in the first place.
Windows in a virtual machine on the workstation#
Windows runs in a window on the workstation, with its own disk. Fidelity is complete, use without a network is possible, and a connected device can be handed through to the virtual machine.
What it takes: a hypervisor and its parts added to the workstation image, a Windows licence per machine, 8 to 16 gigabytes of memory and about 80 gigabytes of disk set aside. The licence that came stuck to the old computer does not follow: it belongs to that machine.
The limits: two systems to keep updated on every workstation, and a Windows attack surface back where you had removed it. This is the most expensive route to maintain and the one that undoes most of the point of the workstation. We take it when one of the three reasons in the fifth question holds, and we then build it as a separate image variant for those workstations rather than changing the image of the whole fleet.
The container#
You will often read that container images of "Windows" exist for Linux. They do, but what they contain is a virtual machine wrapped in a container: the Windows licence is still required, and the window you get integrates less well with the desktop than an ordinary virtual machine does. A true Windows container needs a Windows kernel to run, so it cannot execute on Linux, and no tool works around that.
The container is therefore not a fifth route. It serves elsewhere: for a Windows application with no screen, called by a server, whose window nobody watches.
What gets decided together#
To settle one application we need five answers, and they come from you.
| What we ask for | Why it changes the answer |
|---|---|
| The exact name and version of the application | A recent version often has a web version that the older one lacked. |
| What the person does with it during the day | Decides whether an equivalent covers the work or only the feature list. |
| The devices plugged into the machine | A card reader or a licence key points to the local virtual machine. |
| How many people use it | A shared host makes sense from a few people onward, not for one. |
| Whether it is used without a network | Stock counting in a warehouse with no coverage rules out the central host. |
On our side, we test the application on a workstation before committing, we confirm licensing with a reseller whenever a shared host is involved, and we write the result into your file. Applications that pass none of the four routes do exist. When that happens we say so, and the workstation in question stays on Windows until the work changes or the publisher moves.