Appliances

UnoDOS can run another operating system inside a window on the desktop. An appliance is a Linux system that UnoDOS boots itself, on the same machine, at the same time - with a screen you can see, a keyboard it answers, and a connection of its own on your real network. Chromium runs in one.

A preview, honestly labelledThis is the newest part of UnoDOS and the least finished. Everything described here works and none of it is simulated - but it runs one appliance at a time, it needs an Intel processor, the results below were produced with UnoDOS itself running in a virtual machine, and the browser appliance is built on a Chromium with a known crash in it. Read What it cannot do yet before you plan anything around it.

What it actually does

Open Appliances from the Start menu or its desktop icon. It has three views, and Tab moves between them: a list of the appliances this machine has, the console of the one that is running, and its display.

Appliances on a machine that has none yet: New makes one, and the line above the buttons is the status - here no appliance running, and on a machine that cannot host a guest at all, the reason why. — **Appliances** on a machine that has none yet: **New** makes one, and the line above the buttons is the status - here *no appliance running*, and on a machine that cannot host a guest at all, the reason why.

The console is the guest's serial port. What you type goes in at exactly the place a real keystroke would arrive, so the guest's own driver wakes up and its own shell reads the byte. Nothing is being simulated at the top: a Linux shell reads your command and answers it.

The Display view. Everything inside the black border is the guest drawing on its own screen: UnoDOS hands it a linear framebuffer and describes it in the boot parameters the way firmware would, so a stock Linux kernel drives it with no driver from us. The keyboard is an emulated PS/2 controller, which is why the guest's own input stack sees ordinary key events. — The **Display** view. Everything inside the black border is the guest drawing on its own screen: UnoDOS hands it a linear framebuffer and describes it in the boot parameters the way firmware would, so a stock Linux kernel drives it with no driver from us. The keyboard is an emulated PS/2 controller, which is why the guest's own input stack sees ordinary key events.

F12 leaves the display and gives the keyboard back to the desktop.

The browser appliance

The appliance that makes the point is a small Alpine system running Chromium in a kiosk compositor. It takes its own address from your router, resolves names, validates certificates and renders live pages - inside a window on the UnoDOS desktop.

You can drive it from the host. Ctrl+L focuses the address bar, and what you type goes to the guest's browser letter by letter through the emulated keyboard.

An address typed on the host - in UnoDOS, not in the guest - committed in Chromium's address bar, with the page fetched and rendered under it. The keystrokes crossed into the guest through an emulated PS/2 controller and arrived as ordinary key events; the page came off the internet over the guest's own network connection. — An address typed on the **host** - in UnoDOS, not in the guest - committed in Chromium's address bar, with the page fetched and rendered under it. The keystrokes crossed into the guest through an emulated PS/2 controller and arrived as ordinary key events; the page came off the internet over the guest's own network connection.

Chromium restarts sometimes, and whyThe browser appliance is built on Alpine's Chromium, which links against a system copy of a formatting library whose internal checks are left switched on. A value that ordinary Chromium would format and forget can therefore abort the process. It is restarted automatically inside the compositor, so what you see is a browser that occasionally restarts rather than one that dies - but it is a real fault, it is upstream of UnoDOS, and it is not fixed.

One appliance, different applications

Which application the appliance runs is a small description file rather than a different build, so the same kernel and the same machinery run something else by naming it. GIMP is the second one, and it needed nothing from the hypervisor that the browser had not already needed.

What your machine needs

An Intel processor with VT-x and EPT (Intel's hardware virtualisation and its second-level page tables), switched on in the firmware. Most Intel PCs made in the last decade or so have both, but many ship with VT-x turned off. The status line above the buttons tells you which it is, in one sentence, when you try to start an appliance. If it is off, turn on Intel VT-x (sometimes Intel Virtualization Technology) in the firmware setup and start again.

Not on AMDThe AMD side (AMD-V, or SVM Mode) is written and builds, but its first entry into a guest has never returned, so an AMD machine cannot run appliances today.

Memory is the other requirement: at least about 1.8 GB free. UnoDOS sets aside a block of memory for guests while it is starting up, and how much it can spare depends on the machine. On a machine with too little to set aside there is no guest at all, and the status line says so.

The guest reaches your network through the machine's own network card. So far that has only worked on Intel wired network cards. On one real machine with a Realtek card the browser appliance booted but got no network; a fix is in but has not yet been seen carrying a guest. Realtek and ASIX USB adapters cannot carry a guest yet.

Making an appliance

New adds a row, and each row is four things you can edit:

Field	What it is
Name	What you want to call it
Kernel	A Linux `bzImage` on a UnoDOS volume
Initrd	An initial ramdisk, usually a small busybox image. May be empty.
Disk	A disk image file, which the guest sees as a drive. May be empty.

Copy the kernel and initrd onto the UnoDOS disk the same way you would copy anything else, then name them here. Start boots it, Console switches to its console and Stop shuts it down. A brand-new appliance with its paths left empty boots whatever is already staged in EFI\UNODOS\VM, so it starts rather than failing at you.

Your appliances are kept in EFI\UNODOS\VM\VMS.CFG, one line each, as plain text. It is deliberately a file you can read and fix in the Editor rather than something only the app understands, and it holds up to eight appliances.

Foreign apps, and what works today

The same machinery is meant to end somewhere specific: you double-click an Android .APK in Files, an icon appears on the desktop, and opening it opens a window. No launcher, and nothing on screen that says "Android".

Installing works, the runtime runs, opening does not yetInstalling works, and the runtime runs; the two are not joined yet. Installing is real: UnoDOS reads the package, registers it, the icon appears without a reboot, and it is still there after a restart. The Android runtime is real too: the appliance boots, starts the Android container, installs the app it carries and puts it on screen full-size and on the network, from a cold boot with nobody driving it - the two figures below are that boot. That boot was under an ordinary PC emulator, not yet under UnoDOS's own hypervisor. What is missing is the channel between the desktop icon and that runtime, so opening an installed foreign app today tells you the runtime is not connected. Treat this section as a description of where it is going, not as a feature to use.

The Android appliance, booted with nobody driving it: Firefox full-screen, with no launcher and no status bar in sight.

The same appliance a moment later: a real page over TLS, its address typed on the keyboard UnoDOS presents to the guest.

One consequence is worth knowing even at this stage: the package file is not copied onto the UnoDOS disk, because the filesystem underneath writes whole files only and a large package would have to be held in memory all at once. The installed app remembers where you put the package, so deleting or unplugging it leaves an app that reports its package is missing.

What it cannot do yet

One appliance at a time. Start refuses while another is running rather than quietly replacing it. This is a real limit of how the guest is set up, not an oversight.
Guest disks are read-only. The guest can mount a disk image and read it; it cannot write to it. Writing needs a change further down in the filesystem code.
The pointer drifts. The emulated mouse reports movement rather than position, so the guest's pointer and yours gradually disagree and a target moves as you reach for it. The keyboard does not have this problem.
No kernel is included. UnoDOS does not ship a Linux to run, and the release images carry no appliance: the kernel and the Alpine system the browser and GIMP appliances run on are third-party GPL and MIT software. They are built from pc64/guest/appliance/ in the source tree on a Linux machine and copied onto the disk yourself, so a fresh appliance has nothing to boot until you do.
Intel only. Everything above has been demonstrated on Intel VT-x, and every result on this page was produced with UnoDOS itself running in a virtual machine on an Intel host. The AMD side is written and builds, but its first guest entry has never returned, so an AMD machine cannot run an appliance.
The guest gets a slice, not a core. It runs a short budget of time each frame alongside the desktop, so it is unhurried by design. It is for a shell, a browser and a service, not for work you are timing.
The guest has a coarse clock. It settles on a 10 ms timer rather than anything finer, which is fine for everything above and wrong for anything that measures itself.