Re:_Proposal_—_Seamless_Windows_Application_Vir tualization_via_bhyve
- In reply to: Asiye Sarıyıldız : "Re:_Proposal_—_Seamless_Windows_Application_Virtua lization_via_bhyve"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Sat, 08 Aug 2026 12:47:44 UTC
On 8/8/26 14:39, Asiye Sarıyıldız 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. > Since you're brain storming, and suggest a parallel with WSL2, you could also consider ReactOS as an "unencubered" backend. I don't know how mature it is, but for certain workloads should be good enough. Definitely good enough for office suites and the like. I suspect it is not ready for gaming though. > 8 Ağu 2026 Cmt 13:35 tarihinde Asiye Sarıyıldız <asiyee994@gmail.com > <mailto: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 <mailto: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/ <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 <mailto: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 <mailto: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 <mailto:tomek@cedro.info>> wrote: > > have you tried wine11? > > -- > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info > <http://www.tomek.cedro.info> > > On Sat, Aug 8, 2026, 00:22 Asiye Sarıyıldız > <asiyee994@gmail.com <mailto: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. > -- Guido Falsi <mad@madpilot.net>