Re:_Proposal_—_Seamless_Windows_Application_Virtua lization_via_bhyve

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