Re:_Proposal_—_Seamless_Windows_Application_Virtua lization_via_bhyve

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