Re:_Proposal_—_Seamless_Windows_Application_Virtua lization_via_bhyve
Date: Sat, 08 Aug 2026 13:27:51 UTC
I must give you some clarifications because taken by enthusiasm, I made some mistake : What I've described is essentially WinApps / WinBoat. WinApps uses FreeRDP as a backend to render Windows applications alongside Linux ones, with the host /home directory reachable inside Windows via \tsclient\home, and WinBoat exposes individual Windows program windows to the host using FreeRDP and Windows' RemoteApp protocol, avoiding the overhead of streaming an entire desktop by returning individual windows to the compositor. Nobody has built this on FreeBSD/bhyve. That gap is the actual contribution. GitHub <https://github.com/winapps-org/winapps>Windows Forum <https://windowsforum.com/windows-news.4/winboat-run-real-windows-apps-on-linux-with-per-app-remoteapp-windows.395476/> But three parts of my sketch were wrong, and they're the load-bearing ones. *1. Looking Glass cannot give me seamless windows.* LG captures the guest's *whole framebuffer* as one surface. It has no concept of a top-level window. I would get a Windows desktop in a box — exactly the VNC experience I'm trying to escape, just faster. The mechanism that produces "one Photoshop window on my FreeBSD desktop, no desktop behind it" is RDP *RemoteApp (RAIL)*: the guest exports each top-level window as its own surface and FreeRDP maps each one to a local X11 window. So my "without remote desktop server and client" requirement has to be restated. I *do* use RDP. I just never see a desktop. The protocol is an implementation detail; the UX is what you described. If I want to insist on literally no RDP, I have to write a RAIL-equivalent myself — a guest agent hooking window creation, plus a host compositor client — which is a multi-year project for a strictly worse result. *2. Windows cannot live in a jail or a podman container.* A jail shares the FreeBSD kernel. Podman on FreeBSD runs FreeBSD containers. dockur/windows on Linux is not containerized Windows — it's a container that *wraps QEMU*; the isolation is the VM. On FreeBSD the sandbox is bhyve, full stop. A vnet jail is still useful, but as a wrapper around the *bhyve process* (network confinement, resource limits), not as the thing Windows runs in. *3. sshfs-win points the wrong direction, and I probably don't need it.* sshfs-win mounts *my FreeBSD* filesystem *inside Windows* — that's the useful direction, but RDP already does it for free with /drive:home,/home/marietto, appearing as \\tsclient\home, over the same connection, no WinFsp, no extra daemon. The apps then read and write my real FreeBSD files natively, which makes "access files installed inside the VM" a non-goal — I never need to reach into C:\Program Files. If I still want host→guest visibility, I have to run SMB in the guest and mount_smbfs it; do not mount the live zvol. *What the FreeBSD stack actually is* net/freerdp3 is in ports and supports /app:program:... — the RAIL client is done, cross-platform, already builds on FreeBSD. That's the piece that looked hardest and isn't. The rest is: - bhyve + edk2, virtio-blk on a zvol, headless, VNC only for the initial install - Win11 Pro (your own DVD/key), RemoteApp unlocked via the TSAppAllowList registry keys — Microsoft doesn't expose RemoteApp on client SKUs but it works; this is what WinApps does - a thin CLI + a guest agent that enumerates Start Menu .lnk entries into a JSON manifest on the shared drive, from which the host generates shims and .desktop files install and run then become two RDP invocations: install launches the installer as a RemoteApp (or drops me into a full session for the ones that demand it), run launches the registered target. *The part that's genuinely better on FreeBSD than on Linux:* ZFS. Snapshot the zvol before every install, and uninstall becomes a rollback. Per-app clones give me real per-application sandboxes off one golden Windows dataset, at near-zero disk cost. That's a feature Wine structurally cannot have and WinApps doesn't bother with. *Where Looking Glass does fit* — as a *second display path*, not the primary one. RAIL for normal apps; LG for fullscreen GPU-accelerated single-app mode where RDP's encode/decode latency hurts. My ivshmem-plain work isn't wasted, it's just answering a different question. Don't let this project block on it. *Honest weaknesses* - Cold start. Wine launches in ~1s; I need a warm VM. bhyve suspend/resume exists but is still experimental and requires kernel and userland rebuilt with the BHYVE_SNAPSHOT option, and has had limitations with multiple devices of the same type. Plan on a daemon holding the VM up, first launch 30–60s, subsequent ~1–2s. FreeBSD <https://man.freebsd.org/cgi/man.cgi?query=vm&sektion=8&manpath=freebsd-release-ports> FreeBSD <https://reviews.freebsd.org/D35590> - GPU. Under RDP the presentation surface is encoded on the host-guest link. A passthrough GPU still serves compute (Adobe's accelerated filters, CUDA), but I need the "use hardware graphics adapters for all RDS sessions" policy set. - Multi-monitor RAIL has known artifacts depending on compositor. *Gate 0*, before writing any CLI: bring up a headless Win11 Pro guest under bhyve, unlock RemoteApp, and get xfreerdp3 /app:program:notepad.exe /drive:home,/home/marietto to paint a single Notepad window on my FreeBSD X session that can open a file from my home directory. If that works, everything else is orchestration. If it doesn't, no amount of CLI design saves it. On Sat, Aug 8, 2026 at 3:11 PM Asiye Sarıyıldız <asiyee994@gmail.com> wrote: > Hmm. Actually it's... It's true. I was overly cautious there looking at > Looking Glass's actual requirements, iGPU + dedicated GPU is officially one > of their two supported configurations (the other being iGPU + vGPU), and > it's explicitly called out as the common laptop/desktop scenario. Your > Aorus Pro setup (iGPU + GTX 1060 + RTX 2080 Ti) is well beyond what's > needed. > The only real caveat in their docs is that if the iGPU is used on the host > side, you may hit some bandwidth/resolution limits since it shares system > RAM but that's a minor tradeoff, not a blocker. So GPU passthrough is much > more broadly achievable than I gave it credit for. Stepping back a bit I'd > love to hear what you think of where this thread has landed overall. > Between the qemu-bhyve install/run workflow, bringing your own Windows ISO > to sidestep licensing, sshfs-win or a jail for file access, and now Looking > Glass for near-native seamless display, it feels like the pieces could > actually fit together into something coherent. > Do you think this is realistic to build, or are we underestimating the > effort? My hope is that if something like this existed, it could genuinely > make FreeBSD a more viable desktop choice for people who are currently > stuck on Windows just for a handful of apps > > > 8 Ağu 2026 Cmt 14:03 tarihinde Mario Marietto <marietto2008@gmail.com> > şunu yazdı: > >> ->The main constraint I see is GPU passthrough requirements Looking Glass >> typically needs >dedicated/secondary GPU (or at least IOMMU-capable >> hardware) for good performance, which not >every FreeBSD desktop user will >> have >> >> Are you sure ? Today every mobo has one integrated gpu embedded inside >> it. And a dedicated GPU for intensive tasks. I regularly run the Intel GPU >> integrated inside my Aorus Pro with one Intel I9 cpu on top of it and two >> dedicated GPUs I use for programming. A GTX 1060 and one RTX 2080 ti. I >> think this is the common scenario for most people. >> >> On Sat, Aug 8, 2026 at 2:53 PM Asiye Sarıyıldız <asiyee994@gmail.com> >> wrote: >> >>> Looking Glass is a brilliant addition to this idea exactly the kind of >>> "seamless" experience I was hoping for, and much better than VNC in terms >>> of latency. Having the client run natively on FreeBSD while the server runs >>> inside the jail/VM with Windows would make the whole thing feel like a real >>> native app rather than a remote session. >>> The main constraint I see is GPU passthrough requirements Looking Glass >>> typically needs a dedicated/secondary GPU (or at least IOMMU-capable >>> hardware) for good performance, which not every FreeBSD desktop user will >>> have. Maybe we could fall back to a VNC-based mode when passthrough isn't >>> available, and use Looking Glass as the "fast path" when it is. >>> Combined with the qemu-bhyve install/run workflow and sshfs-win (or a >>> jail-based file mount) for file access, this is shaping up to be a pretty >>> complete picture. Really appreciate you connecting the dots here. >>> >>> 8 Ağu 2026 Cmt 13:48 tarihinde Mario Marietto <marietto2008@gmail.com> >>> şunu yazdı: >>> >>>> >Thanks for the feedback Actually what I had in mind is closer to how >>>> WSL2 works on Windows >>>> >>>> qemu-bhyve install Windows (and here you should insert the WIndows DVD >>>> to avoid licensing issues). >>>> Windows will be installed inside the sandbox. Actually I like the idea >>>> to use sshfs-win >>>> >>>> Later,you can do : qemu-bhyve "tool". And again the tool will be >>>> installed inside the sandbox. >>>> >>>> This is the perfect chance to port Looking Glass,with the client part >>>> which runs on FreeBSD and the server part inside the jail where Windows is >>>> installed :) >>>> >>>> So nice. >>>> >>>> On Sat, Aug 8, 2026 at 2:39 PM Asiye Sarıyıldız <asiyee994@gmail.com> >>>> wrote: >>>> >>>>> I haven't yet considered how to resolve the licensing issue; if we >>>>> were to implement something like WSL2, it shouldn't come pre-installed the >>>>> user would need to download the ISO or a similar file themselves. >>>>> >>>>> 8 Ağu 2026 Cmt 13:35 tarihinde Asiye Sarıyıldız <asiyee994@gmail.com> >>>>> şunu yazdı: >>>>> >>>>>> Thanks for the feedback Actually what I had in mind is closer to how >>>>>> WSL2 works on Windows: it runs a real Linux kernel inside a lightweight >>>>>> Hyper-V VM, but the user never manages the VM directly file sharing, >>>>>> networking, and even GUI apps (via WSLg) are fully integrated, so it feels >>>>>> native. >>>>>> I'd love something like that for FreeBSD + Windows apps: bhyve >>>>>> running a minimal Windows VM in the background, but the user just does >>>>>> qemu-bhyve install adobe and interacts with the app almost like a native >>>>>> FreeBSD program — no manual VM management, no VNC. Your container/jail idea >>>>>> for file access sounds like a great way to get part of that seamlessness >>>>>> without needing full window integration. >>>>>> Regular Wine can't run Adobe or Teams reliably because of missing >>>>>> Win32 API coverage, which is exactly why I think a real Windows kernel >>>>>> (even a minimal one) is needed rather than translation >>>>>> >>>>>> 8 Ağu 2026 Cmt 13:18 tarihinde Mario Marietto <marietto2008@gmail.com> >>>>>> şunu yazdı: >>>>>> >>>>>>> >Yes, I know about Wine, but Wine tries to replicate Windows APIs >>>>>>> which often causes compatibility >bugs or performance overhead. My idea >>>>>>> with bhyve was closer to a lightweight virtualized Windows >kernel >>>>>>> operating in the background, where the GUI windows are seamlessly >>>>>>> integrated into the >FreeBSD desktop environment (like seamless mode in >>>>>>> VirtualBox or WSLg in Linux). I thought bhyve >could achieve better raw >>>>>>> hardware compatibility for specific professional Windows apps. Example >>>>>>> >Adobe >>>>>>> >>>>>>> Your idea is intriguing me,but probably not in the same way you are >>>>>>> thinking about it. In my vision I would keep the way wine works almost >>>>>>> intact,but I would use plane bhyve or qemu accelerated with bhyve instead >>>>>>> of wine,so that we can have something like this : >>>>>>> >>>>>>> qemu-bhyve install or run "application". >>>>>>> >>>>>>> The tool (for example Adobe) will be installed inside a sandbox >>>>>>> after having issued "install" or it can be run in the same way. And you can >>>>>>> have direct access to the files installed without accessing inside the vm >>>>>>> with vnc viewer,but easier,we can install a container (podman ? a jail ? ). >>>>>>> It sounds nice to me. >>>>>>> >>>>>>> ERRATA CORRIGE : we can install the desired tool directly inside a >>>>>>> container (podman ? a jail ? sshfs-win ? >>>>>>> >>>>>>> >>>>>>> https://forums.freebsd.org/threads/windows-drive-mapping-to-freebsd-directory-fails-with-sshfs-win.96474/ >>>>>>> >>>>>>> What do you think ? >>>>>>> >>>>>>> On Sat, Aug 8, 2026 at 12:32 PM Asiye Sarıyıldız < >>>>>>> asiyee994@gmail.com> wrote: >>>>>>> >>>>>>>> Yes, I know about Wine, but Wine tries to replicate Windows APIs >>>>>>>> which often causes compatibility bugs or performance overhead. My idea with >>>>>>>> bhyve was closer to a lightweight virtualized Windows kernel operating in >>>>>>>> the background, where the GUI windows are seamlessly integrated into the >>>>>>>> FreeBSD desktop environment (like seamless mode in VirtualBox or WSLg in >>>>>>>> Linux). I thought bhyve could achieve better raw hardware compatibility for >>>>>>>> specific professional Windows apps. Example Adobe >>>>>>>> >>>>>>>> 8 Ağu 2026 Cmt 11:30 tarihinde Mario Marietto < >>>>>>>> marietto2008@gmail.com> şunu yazdı: >>>>>>>> >>>>>>>>> ---> have you tried wine11? >>>>>>>>> >>>>>>>>> I think he wants to "duplicate" the look and feel and the exterior >>>>>>>>> working of wine,but using bhyve at the place of wine ? Did I understand >>>>>>>>> correctly ? >>>>>>>>> >>>>>>>>> On Sat, Aug 8, 2026 at 12:17 PM Tomek CEDRO <tomek@cedro.info> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> have you tried wine11? >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> CeDeROM, SQ7MHZ, http://www.tomek.cedro.info >>>>>>>>>> >>>>>>>>>> On Sat, Aug 8, 2026, 00:22 Asiye Sarıyıldız <asiyee994@gmail.com> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> I've been thinking about a potential enhancement to bhyve that >>>>>>>>>>> could make Windows application compatibility much smoother for FreeBSD >>>>>>>>>>> desktop users. >>>>>>>>>>> Currently, running Windows applications (e.g., Adobe products) >>>>>>>>>>> requires manually setting up a full Windows VM in bhyve — creating disk >>>>>>>>>>> images, configuring UEFI/BIOS, installing drivers, and manually managing >>>>>>>>>>> the guest OS. This works, but it's a heavy, manual process compared to >>>>>>>>>>> solutions like Wine/Proton on Linux or Parallels' seamless mode on macOS. >>>>>>>>>>> What if bhyve offered a more automated, "appliance-style" >>>>>>>>>>> workflow: the user supplies their own Windows installation ISO (and their >>>>>>>>>>> own license), and bhyve handles VM provisioning, NT kernel boot >>>>>>>>>>> configuration, and required virtio/driver setup automatically — with >>>>>>>>>>> minimal manual steps. Since the user brings their own ISO and license, this >>>>>>>>>>> avoids any licensing or redistribution concerns on the project's side. >>>>>>>>>>> Ideally, this could eventually extend toward seamless window integration >>>>>>>>>>> (running individual Windows apps like Adobe software without exposing the >>>>>>>>>>> full Windows desktop), similar to what VMware Fusion or Parallels offer on >>>>>>>>>>> macOS. >>>>>>>>>>> I understand this raises real challenges — driver signing, GPU >>>>>>>>>>> passthrough for apps like Adobe's Creative Suite, and the significant >>>>>>>>>>> engineering effort seamless integration would require compared to a >>>>>>>>>>> standard full-VM setup. >>>>>>>>>>> Is this something the core team has considered, or is it already >>>>>>>>>>> covered by existing tools (e.g., vm-bhyve, or work in progress)? I'd >>>>>>>>>>> appreciate your perspective on whether this is a realistic direction for >>>>>>>>>>> bhyve, or whether the complexity outweighs the benefit compared to just >>>>>>>>>>> using a standard full VM setup. >>>>>>>>>>> Thank you for your time and for your work on FreeBSD. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Mario. >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Mario. >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Mario. >>>>>>> >>>>>> >>>> >>>> -- >>>> Mario. >>>> >>> >> >> -- >> Mario. >> > -- Mario.