Wine+QEMU seems to be a reasonable way of executing many Windows programs on non-x86-64, non-Windows platforms. Alternatively, you could install a real Windows in a full-system emulator and run on that.

It's not like there are no options at all.

As someone who ran x86 software (primarily Windows at the time) via software emulation (virtualpc) on production PowerPC hardware (Apple PowerMac) I have to disagree.

If you don't need x86 compatibility, PPC is fine, and for open source stuff it's probably reasonably well supported in major distros.

But pretending you can have anywhere close to reasonable performance of x86 binaries on even the newest PPC chips is hopeful at best and realistically a fanciful notion.

You are comparing a system simulator to an instruction set simulator. Those are very different things.

When you run an application on QEMU on Linux, only the application code is simulated (by just-in-time compiling every basic block when it is first executed, then always just executing that compiled native code). System calls go to the Linux kernel on the host system, which runs as usual. Hardware is not virtualized. In contrast, Virtual PC (if I understand correctly) simulates the hardware of an entire PC, including graphics hardware, and runs all of Windows on top of that. That's a lot more expensive in terms of processing power.

That said, sure, you will probably lose some performance with QEMU. If the simulated code uses lots of fancy vector instructions that are not provided by the host hardware, you'll even lose a lot.

Emulating the MMU alone is quite a big issue...

I don't think QEMU in instruction set emulation mode emulates the MMU. Does it? The host system has a perfectly fine MMU. QEMU translates assembly code to assembly code. That is all it does, as far as I know.

Correct, currently usermode QEMU does not emulate the mmu, but just has a flat mapping of guestaddr = hostaddr + constant_base_addr. There has been some thought of adding mmu emulation to usermode, though, as the simple fixed mapping has problems (eg if the guest wants to map at some address where there's already something in the host address space, or for guest archs where the highbits of guest addresses are important like ia64).

I wasn't as concerned about Windows-only programs as I was about non-open x86 programs in general. While there's definitely more closed Windows programs, there are Linux builds of closed-source tools which are only available for x86.

That having been said, I need to look into QEMU.

I wonder how true that still is. 10 years ago Wintel was the dominant software platform, now it's Chrome.

(Which in my view kinda sucks, I prefer native apps to web apps for many purposes, but the market has spoken.)

I'd say it isn't the market that has spoken. Software developers have spoken for the market. Local programs are usually what people want (remember the original iPhone and the backlash against not having applications). Today most business, program managers, and devs prefer to either have the compatibility, fast development time, or full control that a web based service provides. Many times it is a negative for the customers.

This. I think it’s an interesting idea, however it will be relegated to hobbyists and enthusiasts, not the main stream.

The iPad and Raspberry Pi have demonstrated how much overrated x86 compatibility is.