From nobody Sat Aug 08 13:03:03 2026 X-Original-To: freebsd-virtualization@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4hHLmw0Fl6z6ndnk for ; Sat, 08 Aug 2026 13:03:44 +0000 (UTC) (envelope-from marietto2008@gmail.com) Received: from mail-pg1-x532.google.com (mail-pg1-x532.google.com [IPv6:2607:f8b0:4864:20::532]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4hHLmv4z9Mz3WQK for ; Sat, 08 Aug 2026 13:03:43 +0000 (UTC) (envelope-from marietto2008@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pg1-x532.google.com with SMTP id 41be03b00d2f7-cb5a6aa8760so205615a12.1 for ; Sat, 08 Aug 2026 06:03:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1786194220; cv=none; d=google.com; s=arc-20260327; b=SCsGKUxxypAIEwZdEzZDEB4ttFXLg8KSAAeUQfCd5CBzIKxg0e6+8lMMpGX6C+R2fR 8KoHS+zqS1AJD+GXBCl5AXEWPLB18AD9KL5XohOz7YnnKT5Gy98kwXwomV7sxbaS23mw JUXvIb/7WqbABXfvv8mMygXQ48mI3s6vCY8jlvPg9ATESf+ZDUtei0Y2OJN/QwL1mwPy DxHHLhCDJeNOuHwEXT3WiF8WP4ICA5WKmjxE1p1xB1buL4MpjDDufjtHpTPUa2mqy3mE XC6H2RGA6qMGhYStYEQVX1z+Ny5HhmjXJ6Uhinw343g3FCbB265FeTYylFk8VN5L5wIH yqkA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=ahT+3RI2T8Iwq1IjEFzDMBezQx6yoE6tox2a+RkMM2s=; fh=Xcoq4M4ryPnTp9IXmbxELnMEgWZVm3SgTbUPNrR76ew=; b=DgSe6WCWFGgwT/d+GkohEAcMVMKUy0uWVhNNQlO+P+oAhoul0GTjw1uBtHTgAGL51y WOEQTvXYyjejcWL2pZHlWXcRO1qE+6V+awfVFdOLRmGNZVgXq0rplHdwnQBdsdfuP89e ZuSiVA2rlxMQpaRjH23dY/EUUGiZnGTr/QElVOobO/2p8u7UIv6g3020pWAAw+1BNfOt RzerjUefccF8BzTVDgBrQID+MpKCMbzoDlXAC3fBMKiR2L3NcMak8qB2MysWoXai+UOM j7twK+7F25JleE52AYA1BhFj8jjxec3DI7hc07fJDGCBW3jj08l4fulWcWAtbOCOSU6V hQYQ==; darn=freebsd.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1786194220; x=1786799020; darn=freebsd.org; h=content-type:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:from:to:cc:subject:date:message-id:reply-to :content-type; bh=ahT+3RI2T8Iwq1IjEFzDMBezQx6yoE6tox2a+RkMM2s=; b=kzSfICYI0yGyJfcjR2fuIJruAKZYOFuBhxNpdkHXeGhYfajgPYhdzTlSNirp5Y/4kP ruJOO7GZcQO79ho/RwPB478lRLMdy7fptaeF7rSjciRrocaGN4+jRu500ROuMTDXKs7x kRHSKW6r06HBb8otdoyLixz6kHQA90fej8WKVxASPVUwatbE/DRkj4DUPtNtqy9x6cOF Zi2J/U4ZlBVY/5ZzLa0lIirudhYVOdg1G/9Slb1aTQvxuOQQ3j02iOVtBeQHdSMjbWcL f9ojcd8stzPiDVEamK/QBaYkxQ7oESK1X78A3wmNZVuL8FIvAEYmi8JyvTtvrFWSMSKq lhMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786194220; x=1786799020; h=content-type:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to:content-type; bh=ahT+3RI2T8Iwq1IjEFzDMBezQx6yoE6tox2a+RkMM2s=; b=JGq0ycPrNI5tRCg/U5XcX5pur8DxHS2kPBRL2k49+wsMLDCSAelNwwLY0gPxIoTJUx miPFNEL9uwSstNC1nYIsz/qdaA8ihTxzmA6pkrjh50+jy1+qmWfVNfbpZQ7wDw6aamoh MfvwTufRa3sRqM/BwR3128IjU3R/GNQCI5C++pd44lyEj+h9EoRgToxe85QkAFtggc4h bUxqYklfn38+zdWm2uOc81PTy3xWbVTki1GzpxOZjIoMqh9pjsTtuWCr2RW/lAQ+k1It 4P00dBnw2TEC9wMc5TZjnb5imWH2OqKDhncXcQblIHRyBI/y+Z50dK+Qz+k5qeLEIQlN n+iw== X-Gm-Message-State: AOJu0Yx6qm+0RlTYdnPtaQNTY6R+m6SluQfxfjAL3cDsSp+9GFI/zl4N SokyZ8CYQhVOxLUJqWd0tEJj985Zw/Aof8kwotI+kMs0waCjil2YsKGKwo1IHKOuxge/PVE1ilx LBcdAmhBvl13rfMFGoFkl8yPfYq2kYQoNrw== X-Gm-Gg: AR+sD13SuoKYykaMFt1CUl2+q56NhoTL0yG23S+gDVuK5e8LIjel3hK093or1+djfuW UTKAY+6PnOo3yYOtLe/zdFxpkMZNax4nDiauZQu/KATmQcQj5c6aNq6yHSHwsucfVOLrSwYrK0Q uSGjEDyCh3aWqP8DsO2VDL1F4jdbmKDLLDGKk+uVA+ACjs1aOCO8UYVgLfapFyZEv+eJ6YrJyXY YdtiGpX9TINidORp2FSerSOyq4yyMWFtDsBMdWbDokb5bDQmnShs2DcYkqO1q2/mncdeF7Ly7sB e8lpYFBKFuvVWgiF+IKbVoVw96Jnh0hSQ+oKtC0xZ5WjfW0Pr/yJMHcLpYE+276WctnzMLnOq03 S0puO6Be6AXsv9olS9Smtpm544/zbhbNrGNzMUf3Chnz+V1WHNJX2xxWNAlODc2+jPQdJriosPk qCZWrM6lFw3lmraAGR2JukYwVhp69tLQEla7RnAcylm1ttUUfiUvcQGQyvpMe20RpPzQRHJJJOX zawEQv+GIufO8JX/fKK0cSIs0j02qNBOpw1iLZSCPQ1vsxFsNkwwWFWXky6iiPFTGQ2xBOBbPDX mUWsisNiUwtd9kdk/tDW8TGn7Pyyxkz3+lwoxIPibatVVaOBx957gLTAXaOWinT7gAW7vQ== X-Received: by 2002:a05:6a21:1690:b0:3c2:dcdd:a85a with SMTP id adf61e73a8af0-3cbadb039e8mr22104445637.13.1786194220207; Sat, 08 Aug 2026 06:03:40 -0700 (PDT) List-Id: Discussion List-Archive: https://lists.freebsd.org/archives/freebsd-virtualization List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-virtualization@freebsd.org Sender: owner-freebsd-virtualization@FreeBSD.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 References: In-Reply-To: From: Mario Marietto Date: Sat, 8 Aug 2026 15:03:03 +0200 X-Gm-Features: AUfX_mySJ9pWu1T1_3uD-gRC0aehWuzsVBlJhPBU4pYUVrQHvocyhRMDh1qmqe0 Message-ID: Subject: =?UTF-8?Q?Re=3A_Proposal_=E2=80=94_Seamless_Windows_Application_Virtua?= =?UTF-8?Q?lization_via_bhyve?= To: =?UTF-8?B?QXNpeWUgU2FyxLF5xLFsZMSxeg==?= Cc: freebsd-virtualization@freebsd.org Content-Type: multipart/alternative; boundary="000000000000fed15b065888bf75" X-Rspamd-Queue-Id: 4hHLmv4z9Mz3WQK X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Spamd-Bar: ---- --000000000000fed15b065888bf75 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable ->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=E2=80=AFPM Asiye Sar=C4=B1y=C4=B1ld=C4=B1z 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 ru= ns > inside the jail/VM with Windows would make the whole thing feel like a re= al > 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=C4=9Fu 2026 Cmt 13:48 tarihinde Mario Marietto > =C5=9Funu yazd=C4=B1: > >> >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 t= o >> avoid licensing issues). >> Windows will be installed inside the sandbox. Actually I like the idea t= o >> 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=E2=80=AFPM Asiye Sar=C4=B1y=C4=B1ld=C4=B1z <= 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 u= ser >>> would need to download the ISO or a similar file themselves. >>> >>> 8 A=C4=9Fu 2026 Cmt 13:35 tarihinde Asiye Sar=C4=B1y=C4=B1ld=C4=B1z >>> =C5=9Funu yazd=C4=B1: >>> >>>> 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 lightweigh= t >>>> 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 f= eels >>>> 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-bh= yve >>>> install adobe and interacts with the app almost like a native FreeBSD >>>> program =E2=80=94 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 Win3= 2 >>>> API coverage, which is exactly why I think a real Windows kernel (even= a >>>> minimal one) is needed rather than translation >>>> >>>> 8 A=C4=9Fu 2026 Cmt 13:18 tarihinde Mario Marietto >>>> =C5=9Funu yazd=C4=B1: >>>> >>>>> >Yes, I know about Wine, but Wine tries to replicate Windows APIs >>>>> which often causes compatibility >bugs or performance overhead. My id= ea >>>>> 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 r= aw >>>>> hardware compatibility for specific professional Windows apps. Exampl= e >>>>> >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 almos= t >>>>> intact,but I would use plane bhyve or qemu accelerated with bhyve ins= tead >>>>> 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-d= irectory-fails-with-sshfs-win.96474/ >>>>> >>>>> What do you think ? >>>>> >>>>> On Sat, Aug 8, 2026 at 12:32=E2=80=AFPM Asiye Sar=C4=B1y=C4=B1ld=C4= =B1z >>>>> wrote: >>>>> >>>>>> Yes, I know about Wine, but Wine tries to replicate Windows APIs >>>>>> which often causes compatibility bugs or performance overhead. My id= ea with >>>>>> bhyve was closer to a lightweight virtualized Windows kernel operati= ng in >>>>>> the background, where the GUI windows are seamlessly integrated into= the >>>>>> FreeBSD desktop environment (like seamless mode in VirtualBox or WSL= g in >>>>>> Linux). I thought bhyve could achieve better raw hardware compatibil= ity for >>>>>> specific professional Windows apps. Example Adobe >>>>>> >>>>>> 8 A=C4=9Fu 2026 Cmt 11:30 tarihinde Mario Marietto >>>>>> =C5=9Funu yazd=C4=B1: >>>>>> >>>>>>> ---> 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 unders= tand >>>>>>> correctly ? >>>>>>> >>>>>>> On Sat, Aug 8, 2026 at 12:17=E2=80=AFPM Tomek CEDRO >>>>>>> wrote: >>>>>>> >>>>>>>> have you tried wine11? >>>>>>>> >>>>>>>> -- >>>>>>>> CeDeROM, SQ7MHZ, http://www.tomek.cedro.info >>>>>>>> >>>>>>>> On Sat, Aug 8, 2026, 00:22 Asiye Sar=C4=B1y=C4=B1ld=C4=B1z >>>>>>>> wrote: >>>>>>>> >>>>>>>>> I've been thinking about a potential enhancement to bhyve that >>>>>>>>> could make Windows application compatibility much smoother for Fr= eeBSD >>>>>>>>> desktop users. >>>>>>>>> Currently, running Windows applications (e.g., Adobe products) >>>>>>>>> requires manually setting up a full Windows VM in bhyve =E2=80=94= creating disk >>>>>>>>> images, configuring UEFI/BIOS, installing drivers, and manually m= anaging >>>>>>>>> the guest OS. This works, but it's a heavy, manual process compar= ed to >>>>>>>>> solutions like Wine/Proton on Linux or Parallels' seamless mode o= n macOS. >>>>>>>>> What if bhyve offered a more automated, "appliance-style" >>>>>>>>> workflow: the user supplies their own Windows installation ISO (a= nd their >>>>>>>>> own license), and bhyve handles VM provisioning, NT kernel boot >>>>>>>>> configuration, and required virtio/driver setup automatically =E2= =80=94 with >>>>>>>>> minimal manual steps. Since the user brings their own ISO and lic= ense, this >>>>>>>>> avoids any licensing or redistribution concerns on the project's = side. >>>>>>>>> Ideally, this could eventually extend toward seamless window inte= gration >>>>>>>>> (running individual Windows apps like Adobe software without expo= sing the >>>>>>>>> full Windows desktop), similar to what VMware Fusion or Parallels= offer on >>>>>>>>> macOS. >>>>>>>>> I understand this raises real challenges =E2=80=94 driver signing= , GPU >>>>>>>>> passthrough for apps like Adobe's Creative Suite, and the signifi= cant >>>>>>>>> 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 direct= ion for >>>>>>>>> bhyve, or whether the complexity outweighs the benefit compared t= o just >>>>>>>>> using a standard full VM setup. >>>>>>>>> Thank you for your time and for your work on FreeBSD. >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Mario. >>>>>>> >>>>>> >>>>> >>>>> -- >>>>> Mario. >>>>> >>>>> >>>>> -- >>>>> Mario. >>>>> >>>> >> >> -- >> Mario. >> > --=20 Mario. --000000000000fed15b065888bf75 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
->The main constraint I see is GPU passthrough req= uirements Looking Glass typically needs >dedicated/secondary GPU (or at least IOMMU-capable=20 hardware) for good performance, which not >every FreeBSD desktop user=20 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 Inte= l I9 cpu on top of it and two dedicated GPUs I use for programming. A GTX 1= 060 and one RTX 2080 ti. I think this is the common scenario for most peopl= e.=C2=A0

On Sat, Aug 8, 2026 at 2:53=E2=80=AFPM Asiye Sar= =C4=B1y=C4=B1ld=C4=B1z <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 wit= h Windows would make the whole thing feel like a real native app rather tha= n a remote session.
The main constraint I see is GPU passt= hrough requirements Looking Glass typically needs a dedicated/secondary GP= U (or at least IOMMU-capable hardware) for good performance, which not ever= y FreeBSD desktop user will have. Maybe we could fall back to a VNC-based m= ode when passthrough isn't available, and use Looking Glass as the &quo= t;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 app= reciate you connecting the dots here.

8 A=C4=9Fu 2026 Cmt 13:48 tarihi= nde Mario Marietto <marietto2008@gmail.com> =C5=9Funu yazd=C4=B1:
>Than= ks for the feedback Actually what I had in mind is closer to how WSL2 works= on Windows

qemu-bhyve install Windows (and here y= ou should insert the WIndows DVD to avoid licensing issues).
Wind= ows will be installed inside the sandbox. Actually I like the idea to use s= shfs-win

Later,you can do : qemu-bhyve "tool&= quot;. And again the tool will=C2=A0be installed inside the sandbox.
<= div>
This is the perfect chance to port Looking Glass,with th= e client part which runs on FreeBSD and the server part inside the jail whe= re Windows is installed :)=C2=A0=C2=A0

So nice.

On Sat, Aug 8, 2026 at 2:39=E2=80=AFPM Asiye Sar=C4=B1y=C4=B1ld=C4=B1z &= lt;asiyee994@gmail.com> wrote:
I haven't yet considered how t= o 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 IS= O or a similar file themselves.

8 A=C4=9Fu 2026 Cmt 13:35 tarihinde Asiye Sa= r=C4=B1y=C4=B1ld=C4=B1z <asiyee994@gmail.com> =C5=9Funu yazd=C4= =B1:
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 Hy= per-V VM, but the user never manages the VM directly=C2=A0 file sharing, ne= tworking, and even GUI apps (via WSLg) are fully integrated, so it feels na= tive.
I'd love something like that for FreeBSD + Windo= ws 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 =E2=80=94 no manual VM management, no VNC. Your co= ntainer/jail idea for file access sounds like a great way to get part of th= at 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 (eve= n a minimal one) is needed rather than translation

8 A=C4=9Fu 2026 Cmt= 13:18 tarihinde Mario Marietto <marietto2008@gmail.com> =C5=9Funu yazd=C4=B1:

=

qemu-bhyve install or run "application".=C2= =A0

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 with= out accessing inside the vm with vnc viewer,but easier,we can install a con= tainer (podman ? a jail ? ). It sounds nice to me.

ERRATA CORRIGE : we can install the desired tool directly inside a contain= er (podman ? a jail ? sshfs-win ?=C2=A0

https://forums.freebsd.org/threads/windows-driv= e-mapping-to-freebsd-directory-fails-with-sshfs-win.96474/
What do you think ?

=
On Sat, Aug 8, 2026 at 12:32=E2=80=AF= PM Asiye Sar=C4=B1y=C4=B1ld=C4=B1z <asiyee994@gma= il.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 integrat= ed into the FreeBSD desktop environment (like seamless mode in VirtualBox o= r WSLg in Linux). I thought bhyve could achieve better raw hardware compati= bility for specific professional Windows apps. Example Adobe=C2=A0
8 A=C4=9F= u 2026 Cmt 11:30 tarihinde Mario Marietto <mar= ietto2008@gmail.com> =C5=9Funu yazd=C4=B1:
---> have you tr= ied wine11?

I think he wants to "duplicate&qu= ot; the look and feel and the exterior working of wine,but using bhyve at t= he place of wine ? Did I understand correctly ?

On Sat, Aug 8, 2026 = at 12:17=E2=80=AFPM Tomek CEDRO <tomek@ce= dro.info> wrote:
have you tried wine11?

<= div>--
CeDeROM, SQ7MHZ, http://www.to= mek.cedro.info

On Sat, Aug 8, 2026, 00:22 Asiye Sar=C4=B1y=C4=B1ld= =C4=B1z <asiyee994@gmail.com> w= rote:
I've been thinking about a potential enhancement to bhyve tha= t could make Windows application compatibility much smoother for FreeBSD de= sktop users.
Currently, running Windows applications (e.g.= , Adobe products) requires manually setting up a full Windows VM in bhyve = =E2=80=94 creating disk images, configuring UEFI/BIOS, installing drivers, = and manually managing the guest OS. This works, but it's a heavy, manua= l process compared to solutions like Wine/Proton on Linux or Parallels'= seamless mode on macOS.
What if bhyve offered a mor= e 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 setu= p automatically =E2=80=94 with minimal manual steps. Since the user brings = their own ISO and license, this avoids any licensing or redistribution conc= erns on the project's side. Ideally, this could eventually extend towar= d seamless window integration (running individual Windows apps like Adobe s= oftware without exposing the full Windows desktop), similar to what VMware = Fusion or Parallels offer on macOS.
I understand thi= s raises real challenges =E2=80=94 driver signing, GPU passthrough for apps= like Adobe's Creative Suite, and the significant engineering effort se= amless 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 jus= t using a standard full VM setup.
Thank you for your= time and for your work on FreeBSD.


--
Ma= rio.


--
Ma= rio.


--
Mario.


--
Ma= rio.


--
Ma= rio.
--000000000000fed15b065888bf75--