Re:_Proposal_—_Seamless_Windows_Application_Virtua lization_via_bhyve

 this is exactly the kind of grounding this thread needed  a clear,
testable Gate 0 instead of more speculation. Thanks for laying out the
RDP/RAIL tradeoffs so concretely too.
Really appreciate everyone's input here  Wine limitations, licensing,
sshfs-win, Looking Glass, and now this  this has been a great discussion.



8 Ağu 2026 Cmt 14:28 tarihinde Mario Marietto <marietto2008@gmail.com> şunu
yazdı:

> 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.
>