Something seems a bit off about the combination of hype and disclaimers here. First it's "seamless integration". Then it warns me that I should "expect to occasionally run into hiccups and bugs" and "should be comfortable with some level of troubleshooting". But then it's back to saying I can "enjoy the full range of Windows applications" "without any hassle". These just don't seem compatible to me. If it's seamless and hassle-free, that would mean there aren't hiccups and bugs. If there are hiccups and bugs, it's not seamless and hassle-free.
It may be a good project, but I always get kind of annoyed when projects try to overhype how "easy" and "smooth" the experience will be. I guess in one sense this is better than that because it does have disclaimers, but that just makes it harder to know what the truth actually is about its abilities.
Literally at the top of the docs it says it's in Beta. I don't think you have to think too hard to figure out that seamless integration is the goal but they aren't there yet.
That seems fair, but then it makes it all feel somewhat tautological: what sort of integration wouldn't aspire to be seamless, other than a beta integration.
A different selection of words wouldn't have lead to this debate, which I think is the point being made.
it makes it all feel somewhat tautological: what sort of integration wouldn't aspire to be seamless
VMware or VirtualBox running within the VMware/Vbox window, as opposed to VMware Unity or VirtualBox Seamless mode. Those allow you to have a window from the guest VM appear on your desktop just like it's a native application running on the host.
That's what seamless means in this context. It's a specific feature, not a general descriptor of your experience with the software as a whole.
A different selection of words wouldn't have lead to this debate, which I think is the point being made.
Seamless is a word with a specific meaning within the context of VMs.
> what sort of integration wouldn't aspire to be seamless
That doesn't make sense to me. Seamlessness isn't an essential feature of any integration, just those that would lend themselves to zero-config deployments. I think the vast majority would require some form of configuration, either sharing credentials, or configuring resource limitations, devices, files and folders...
Then why say that it is that? It makes much more sense to me to say "The project is a beta that does X Y and Z and we hope it will eventually become this amazing seamless hassle-free thing." I don't get why projects don't distinguish future aspirations from present accomplishments.
"Seamless integration" in this case doesn't read as statement about how well it works to me. It means the applications from the windows appear on your Linux desktop without the "seam" of a full windows desktop around them.
I blame npm and the entire JavaScript ecosystem for promulgating the awful, sleazy-used-car-saleman practice of writing your readme in the form of advertising copy.
I suppose this is it. I just find it irritating when project descriptions don't clearly distinguish what they hope to eventually be from what they currently are.
"seamless integration" is an intention of the project - that doesn't mean the software is free of bugs and issues. What an absolute asinine and nonsensical argument.
Do you use an application launcher / configuration manager like Lutris to do this? Or do you mean directly through steam? There's a steam game that I play often that tends to work the most frequently with proton hotfix for reasons unknown to me.
No just directly in Steam. You can just add a non steam game to your library and select the .exe file you want, and steam will create a c drive environment for each non steam game you add.
In some cases you might have to change which exe file it runs, if you initially run a setup.exe which creates the real exe file you'd want to launch inside the c drive environment folder
Yeah, why not? Steam has non games on it by default - mostly art programs and utilities for whatever reason. When you're adding a non steam game to be run through steam it's just a wrapper and shortcut to it.
Yes, Battle.net runs flawlessly in Steam, have zero issues playing D2R and D4 this way. In fact D4 ran flawlessly on Linux on Day 1, which came as a bit of a surprise to me.
Lutris doesn't have to mean Wine. It can launch apps via Proton too (and so can Heroic). I think it uses https://github.com/Open-Wine-Components/umu-launcher behind the scenes, not sure, but so far I haven't run into any issues with this approach.
This is exactly what I do, works great. I may have had to try one or two different recent versions of Proton via the drop-down, but it's way less hassle than when I used Lutris.
I played WoW for several years this way without much issue. The only tweaking I ended up doing manually was to try to figure it out how to get the game to let me enable ray tracing, which I did get working but ended to being too much of a performance hit for my to leave on most of the time anyhow.
Looks like it's just a fancy Docker container running the Windows RemoteApp implementation, wrapped around some VM management skins?
I normally set this up on Windows boxes directly with https://github.com/kimmknight/remoteapptool and https://github.com/kimmknight/raweb to build a basic "remote Windows apps" box on my network overall -- it's nicer to be able to have one central Windows VM running that I can put the apps wherever I need them across whatever device in my house.
I don't understand what's your suggested setup is, could you expand on that?
So you have a Linux desktop that runs a Windows VM that runs multiple things at once: the app you want to run; an RDP server that is configured via 1 of those 2 tools to stream just the app's window instead of the whole Windows desktop; and on top of it you run the other 1 of those 2 tools you linked to wrap the RDP server's stream into a web server, so that instead of running an RDP client on your Linux host to access the Windows-hosted app you could simply use the browser?
Is that your suggested setup?
If yes - then it won't fit resource-demanding gaming, as for such games you'd need to pass your GPU to the Windows VM and thus your host Linux loses a GPU, so you need a 2-GPU setup for that to work comfortably.
This entire setup (mine and OP) relies on a Windows RDP feature called “RemoteApp” that allows single-application remoting over a transparent RDP session.
RATool lets you configure RemoteApp “apps” on a serving Windows computer, which generates .rdp files which are RemoteApp “application” sessions that can be launched.
RAWeb on top serves those .rdp files in a way that’s compatible with the “remote resource feed” in Remote Desktop/Windows App, which requires hosting it on IIS.
So basically, one Windows VM is sitting on an ESXi server in my house running RAWeb with a bunch of RemoteApp .rdp files I generated with RATool, and all of my RD clients have just a normal list of apps I can launch, as if it was a proper VDI farm.
I’m not doing GPU intensive tasks so this works out fine for me.
I know nothing about this project, but this appears to be using a docker image from here "https://github.com/dockur/windows/pkgs/container/windows".
Which says "Any product keys found in the code are just generic placeholders provided by Microsoft for trial purposes."
This app appears to be using windows with trial keys which goes against their intended usage and would have questionable legality. I would think if you do use this you would need to have a licensed version of windows and alter the docker settings to use your purchased key instead of the included trial keys.
Ideally this project would have this detail in big bold letters in it's README.
So the app you want to run (suppose that's a game) runs in a docker container? Wouldn't this, just like with running the game on a Windows -in-a-VM setup) require an extra GPU (since you want your game to be GPU accelerated, but if you pass the GPU resource to the docker container (does that even work?) - your host machine thus loses the GPU?
I don't think I'd try running anything more than a puzzle game over RDP myself. There are better alternatives for that. As far as GPU sharing, there are patches for many consumer GPUs that will unlock enterprise features like gpu resource splitting/sharing.
One comment and the prerequisites hint at this tool spinning up a docker container which runs a windows VM and pulls the windows out using some remote desktop tool
True enough... that said, most of the security enhancements came over the Vista/Win7 timeframe. Just be careful with what you run and what apps have internet access... this setup seems to have full access to your home directory, which for most users can be every bit as bad as a root exploit.
There are a bunch of great forks / integrations of WinApps project (& similar) on GitHub now - I highly recommend LinOffice (https://github.com/eylenburg/linoffice/) for those who need native Office 365 (I needed to reluctantly edit Excel macros, and dual booting from Linux into Windows many times a day wasn't efficient).
It's great to support the team at CrossOver, but if you need a recent version of office or a Windows application that Wine/Proton doesn't support properly, then Docker/Podman running QEMU/KVM in the background is surprisingly performant (which Lin Office orchestrates all for you).
Yes, it uses RemoteApps. You can set it up yourself using just a vanilla Windows VM + FreeRDP3, no need for this app and all the complexities (and bugs) they come with it.
Lately I've been using umu-launcher [1] which is a wrapper and compatibility tool for the proton used by steam and I'm quite satisfied about it. It's shipped with configurations for 3000+ games, might be worth a try if you're having trouble with the configs.
Take it with a grain of salt, I don't have much experience in running windows application on Linux, I just had some problems with wine and I discovered umu to be pretty straightforward and easy to use.
Same here. I used to have great success with PlayOnLinux, then it seems worked on it ceased 3-4 years ago? It was very duplicative, making a fresh Wine environment for each application, but for that cost it seemed to be less prone to issues than other approaches in the 2010-2020 era.
This doesn't seem to be using Wine though, as it requires Docker it's likely something lower level than a compatibility layer that translates syscalls.
More polished UI, easier to set up (distributed as an AppImage + a Windows Docker image), and it's written in Typescript + Go, whereas WinApps is mostly a collection of Bash scripts that requires you to manually set up your own Windows VM first.
But the core concept is the same, using RDP's RemoteApps feature via FreeRDP for the "seamless" integration.
" Run Any App: If it runs on Windows, it can run on WinBoat. Enjoy the full range of Windows applications as native OS-level windows in your Linux environment"
Bold claim. Lets see it run Fortnite with anti-cheat.
If you mean 'run macOS apps on Linux', Darling [0] already exists. Running command-line applications is already possible, GUI applications less so.
If you want to run Windows Games on macOS, that is also very much possible. Wine runs on macOS and Apple have themselves developed the 'Game Porting Toolkit' which provides an implementation of D3D12. I understand the best way to use that these days is to use CrossOver [1].
It should as it isn't running Windows app through wine but via a dedicated VM (managed by a docker container). Anything that can be ran in a qemu vm, should work fine.
Seems to be an evaluation license... that said, you can run recent versions of windows unregistered for pretty much as long as you want... they disable some UI enhancements, like changing the desktop, but it tends to function.
Not sure on older versions... MS used to generate new evaluation ISOs every few months with a hard fuse in them... Can't speak for recently since it's been years since I've needed to test for old IE versions. If you choose to customise, I'd suggest going with one of the "lite" modified versions of Windows 10... since this will reduce the default surface a lot without the bridge to some of what Win11 added while jumping the shark.
Fairly sure it requires you to have your own copy of Windows; it doesn’t provide one for you. Otherwise it would be a massive licensing violation / piracy. If you look at similar projects like WinApps, that’s how they work.
Hey HN, creator here. (I added my HN profile to GitHub Socials if you'd like to verify)
Honestly, I did not expect WinBoat to blow up as much as it did. I have never released desktop software before that got this large of an audience, I'm equally amazed and humbled by how many people decided to try it and how many different ways there are for things to break. Thanks to each and every one of you who decided to take WinBoat for a spin.
I deliberately did not post on HN, even though I've been recommended to do so. I'm not saying you folks are necessarily mean, but from years of reading I've come to learn that HN has a very critical eye. WinBoat is not feature-complete or an entirely stable experience, so I don't consider it worthy for HN. As such, I'm sorry if I disappointed anyone.
I'll try to answer some of your questions or criticisms honestly without bs.
Q: Why the hype if it's not seamless?
A: No software will ever perfect, but almost all programmers dream of people one day trying their software. In my view, you have to convince people to try it, then you have to improve it, and then perhaps you can scrape off the Beta label and hope your code stays 100% true to what was promised. This framework doesn't function without people with different machines and setups trying out your software and giving feedback. Alternatively, you could make your tagline "Run Windows apps on Linux
with seamless integration (If Docker, Linux, Windows, X11, XWayland, Wayland, and FreeRDP decide to perfectly work together in harmony)", but who would ever write such a tagline?
Q: What's WinBoat?
A: An Electron app, a Windows VM in Docker, FreeRDP (with RemoteApps), and a Golang HTTP server largely running PowerShell scripts mashed together into something that's supposed to make your life using Windows apps on Linux easier. It's supposed to be easy and elegant.
Q: Why not use Wine instead?
A: Wine is great, you can and most likely should use Wine for all the apps which it works for. WinBoat is more useful for apps that do not play well with Wine, and there's no shortage of such apps.
Q: Why not use WinApps instead? (Directly from winboat.app)
A: With WinApps you do the bulk of the setup manually, and there's no cohesive interface to bring it all together. There's a basic TUI, a taskbar widget, and some CLI commands for you to play with. WinBoat does all the setup once you have the pre-requisites installed, displays everything worth seeing in a neat interface for you, and acts like a complete experience. No need to mess with configuration files, no need to memorize a dozen CLI commands, it just works.
Q: Why not contribute to WinApps instead to make it better?
A: Their methodology is different. Not worse, just different. They have individual bash scripts that do certain things and leave the rest to the end user. They most definitely don't want Electron, and I don't want a collection of bash scripts the user has to tangle with. We have shared ideals, just go about achieving them differently. That doesn't mean one is better or worse than the other.
Q: Is the text written by AI?
A: No, I suspect emojis have something to do with folks saying that it's AI, but it's not. In my opinion emojis just provide a nice visual distinction and make the text a bit more colorful. But I also realize in hindsight that AI-s also write in this style sometimes.
Q: Is WinBoat some vibecoded slop?
A: No, I've poured dozens of hours of my time, knowledge, and passion into it. I don't claim to be the best programmer, or hell, even a good one at that, but I'm pretty sure you can't tell Cursor to make WinBoat from scratch and see a functional app an hour later. Much like anyone else, I use Cursor to get small, targeted tasks done and/or autocomplete where appropiate.
One minor/major though... depending on how much of the UI app is front-end code vs back-end, you might look towards a smaller wrapper like Tauri over Electron... It's rust on the "back end" though, so that may be a no-go for you.. but something that might be worth considering.
That said, when adding a full windows VM/Container, it's probably less of an issue.
Because WinApps is just a collection of Bash scripts, and not everyone might want to work on a project of this scale using Bash. In fact, I was considering a rewrite of WinApps myself, using Rust and egui, but never got around to it...
Something seems a bit off about the combination of hype and disclaimers here. First it's "seamless integration". Then it warns me that I should "expect to occasionally run into hiccups and bugs" and "should be comfortable with some level of troubleshooting". But then it's back to saying I can "enjoy the full range of Windows applications" "without any hassle". These just don't seem compatible to me. If it's seamless and hassle-free, that would mean there aren't hiccups and bugs. If there are hiccups and bugs, it's not seamless and hassle-free.
It may be a good project, but I always get kind of annoyed when projects try to overhype how "easy" and "smooth" the experience will be. I guess in one sense this is better than that because it does have disclaimers, but that just makes it harder to know what the truth actually is about its abilities.
Literally at the top of the docs it says it's in Beta. I don't think you have to think too hard to figure out that seamless integration is the goal but they aren't there yet.
That seems fair, but then it makes it all feel somewhat tautological: what sort of integration wouldn't aspire to be seamless, other than a beta integration.
A different selection of words wouldn't have lead to this debate, which I think is the point being made.
it makes it all feel somewhat tautological: what sort of integration wouldn't aspire to be seamless
VMware or VirtualBox running within the VMware/Vbox window, as opposed to VMware Unity or VirtualBox Seamless mode. Those allow you to have a window from the guest VM appear on your desktop just like it's a native application running on the host.
That's what seamless means in this context. It's a specific feature, not a general descriptor of your experience with the software as a whole.
A different selection of words wouldn't have lead to this debate, which I think is the point being made.
Seamless is a word with a specific meaning within the context of VMs.
That's fair. I was aware of that, but I wasn't thinking of that use of the word when I read it, I thought of the other meaning of "seamless".
> Seamless is a word with a specific meaning within the context of VMs.
The problem is it also has another specific meaning in the context of integrations in general: it means low fuss, minimal setup, no troubleshooting.
A different selection of words (windowless?) would have avoided this debate.
> what sort of integration wouldn't aspire to be seamless
That doesn't make sense to me. Seamlessness isn't an essential feature of any integration, just those that would lend themselves to zero-config deployments. I think the vast majority would require some form of configuration, either sharing credentials, or configuring resource limitations, devices, files and folders...
I was using the other definition of "seamless", meaning easy, no fuss, minimal difficulty etc.
Then why say that it is that? It makes much more sense to me to say "The project is a beta that does X Y and Z and we hope it will eventually become this amazing seamless hassle-free thing." I don't get why projects don't distinguish future aspirations from present accomplishments.
"Seamless integration" in this case doesn't read as statement about how well it works to me. It means the applications from the windows appear on your Linux desktop without the "seam" of a full windows desktop around them.
Sounds to me like this is similar to Coherence mode in Parallels. I'm sure it won't work 100% of the time, but could be good for basic use cases.
I blame npm and the entire JavaScript ecosystem for promulgating the awful, sleazy-used-car-saleman practice of writing your readme in the form of advertising copy.
I would have thought this traces back to GitHub making your readme the defacto "landing page" for your project?
That may be right. I want to blame JavaScript though. :(
I suppose this is it. I just find it irritating when project descriptions don't clearly distinguish what they hope to eventually be from what they currently are.
I read it as being seamless and hassle free until it isn't because there can still be issues. Like a car until it breaks down.
This is Linux in an nutshell. Great until it breaks, then it's a complete deep dive measured in days.
I don't think one should ever expect a "true seamless integration" from this kind of project.
"seamless integration" is an intention of the project - that doesn't mean the software is free of bugs and issues. What an absolute asinine and nonsensical argument.
I've found that running non steam apps on steam with the proton experimental compatibility usually just works, it has become my go to solution
Might work even better with CodeWeavers' CrossOver: https://www.codeweavers.com/
It costs a little bit of money, but it comes with support and directly finds the WINE project (CodeWeavers is a major contributor.)
Never had much luck with crossover in the end it's easier to hack your own winerunner for apps that don't work with standard wine.
Might want to send them some help directly if you're able then: https://www.winehq.org/donate
Do you use an application launcher / configuration manager like Lutris to do this? Or do you mean directly through steam? There's a steam game that I play often that tends to work the most frequently with proton hotfix for reasons unknown to me.
No just directly in Steam. You can just add a non steam game to your library and select the .exe file you want, and steam will create a c drive environment for each non steam game you add.
In some cases you might have to change which exe file it runs, if you initially run a setup.exe which creates the real exe file you'd want to launch inside the c drive environment folder
Wait, can I run non-games like that, too? Launch all kinds of windowed GUI programms from Steam?
Yeah, why not? Steam has non games on it by default - mostly art programs and utilities for whatever reason. When you're adding a non steam game to be run through steam it's just a wrapper and shortcut to it.
Very handy on the steam deck for some programs
So you could run battle.net inside Steam? That would be fun, I've had issues with battle.net on wine / lutris
Yes, Battle.net runs flawlessly in Steam, have zero issues playing D2R and D4 this way. In fact D4 ran flawlessly on Linux on Day 1, which came as a bit of a surprise to me.
The only thing I still can't run is League of Legends. I hope someone can figure that out somehow
Lutris doesn't have to mean Wine. It can launch apps via Proton too (and so can Heroic). I think it uses https://github.com/Open-Wine-Components/umu-launcher behind the scenes, not sure, but so far I haven't run into any issues with this approach.
This is exactly what I do, works great. I may have had to try one or two different recent versions of Proton via the drop-down, but it's way less hassle than when I used Lutris.
I played WoW for several years this way without much issue. The only tweaking I ended up doing manually was to try to figure it out how to get the game to let me enable ray tracing, which I did get working but ended to being too much of a performance hit for my to leave on most of the time anyhow.
This is what I do, it feels weird, but works perfectly and is the least effort solution
Looks like it's just a fancy Docker container running the Windows RemoteApp implementation, wrapped around some VM management skins?
I normally set this up on Windows boxes directly with https://github.com/kimmknight/remoteapptool and https://github.com/kimmknight/raweb to build a basic "remote Windows apps" box on my network overall -- it's nicer to be able to have one central Windows VM running that I can put the apps wherever I need them across whatever device in my house.
I don't understand what's your suggested setup is, could you expand on that?
So you have a Linux desktop that runs a Windows VM that runs multiple things at once: the app you want to run; an RDP server that is configured via 1 of those 2 tools to stream just the app's window instead of the whole Windows desktop; and on top of it you run the other 1 of those 2 tools you linked to wrap the RDP server's stream into a web server, so that instead of running an RDP client on your Linux host to access the Windows-hosted app you could simply use the browser?
Is that your suggested setup?
If yes - then it won't fit resource-demanding gaming, as for such games you'd need to pass your GPU to the Windows VM and thus your host Linux loses a GPU, so you need a 2-GPU setup for that to work comfortably.
This entire setup (mine and OP) relies on a Windows RDP feature called “RemoteApp” that allows single-application remoting over a transparent RDP session.
RATool lets you configure RemoteApp “apps” on a serving Windows computer, which generates .rdp files which are RemoteApp “application” sessions that can be launched.
RAWeb on top serves those .rdp files in a way that’s compatible with the “remote resource feed” in Remote Desktop/Windows App, which requires hosting it on IIS.
So basically, one Windows VM is sitting on an ESXi server in my house running RAWeb with a bunch of RemoteApp .rdp files I generated with RATool, and all of my RD clients have just a normal list of apps I can launch, as if it was a proper VDI farm.
I’m not doing GPU intensive tasks so this works out fine for me.
You don't need 2 GPUs with vGPU / SR-IOV which you can unlock on some consumer GPUs with a hack.
I know nothing about this project, but this appears to be using a docker image from here "https://github.com/dockur/windows/pkgs/container/windows". Which says "Any product keys found in the code are just generic placeholders provided by Microsoft for trial purposes." This app appears to be using windows with trial keys which goes against their intended usage and would have questionable legality. I would think if you do use this you would need to have a licensed version of windows and alter the docker settings to use your purchased key instead of the included trial keys. Ideally this project would have this detail in big bold letters in it's README.
It's running RDP to a Winboat docker image hosting the app and rendering the container on the desktop. This includes audio forwarding.
So the app you want to run (suppose that's a game) runs in a docker container? Wouldn't this, just like with running the game on a Windows -in-a-VM setup) require an extra GPU (since you want your game to be GPU accelerated, but if you pass the GPU resource to the docker container (does that even work?) - your host machine thus loses the GPU?
I don't think I'd try running anything more than a puzzle game over RDP myself. There are better alternatives for that. As far as GPU sharing, there are patches for many consumer GPUs that will unlock enterprise features like gpu resource splitting/sharing.
How is there an entire page without a single line describing how it works?
One comment and the prerequisites hint at this tool spinning up a docker container which runs a windows VM and pulls the windows out using some remote desktop tool
This appear to use https://github.com/dockur/windows which is a VM inside a Docker container?
Otherwise looking at the code this feels like something that could be a short bash script wrapped in a electron app.
I got a good chuckle from the https://github.com/dockur/windows#how-do-i-select-the-window... table
confirming the adage that all projects expand to fill available ~time~ disk spaceTrue enough... that said, most of the security enhancements came over the Vista/Win7 timeframe. Just be careful with what you run and what apps have internet access... this setup seems to have full access to your home directory, which for most users can be every bit as bad as a root exploit.
wouldn't this require a license? windows is not free in any sense of the word
It appear to download windows on the fly from Microsoft's server and uses trial keys [0]
[0] https://github.com/dockur/windows?tab=readme-ov-file#is-this...
There are a bunch of great forks / integrations of WinApps project (& similar) on GitHub now - I highly recommend LinOffice (https://github.com/eylenburg/linoffice/) for those who need native Office 365 (I needed to reluctantly edit Excel macros, and dual booting from Linux into Windows many times a day wasn't efficient).
It's great to support the team at CrossOver, but if you need a recent version of office or a Windows application that Wine/Proton doesn't support properly, then Docker/Podman running QEMU/KVM in the background is surprisingly performant (which Lin Office orchestrates all for you).
Does this use MS-RemoteApp RDP extension (https://learn.microsoft.com/en-us/openspecs/windows_protocol...) under the hood?
Why does xenapp still exist when windows can just run apps remotely?
Yes, it uses RemoteApps. You can set it up yourself using just a vanilla Windows VM + FreeRDP3, no need for this app and all the complexities (and bugs) they come with it.
I've been down this road so many times with Wine configs and broken prefixes that I have trust issues, lol.
Lately I've been using umu-launcher [1] which is a wrapper and compatibility tool for the proton used by steam and I'm quite satisfied about it. It's shipped with configurations for 3000+ games, might be worth a try if you're having trouble with the configs.
Take it with a grain of salt, I don't have much experience in running windows application on Linux, I just had some problems with wine and I discovered umu to be pretty straightforward and easy to use.
[1] https://github.com/Open-Wine-Components/umu-launcher
Same here. I used to have great success with PlayOnLinux, then it seems worked on it ceased 3-4 years ago? It was very duplicative, making a fresh Wine environment for each application, but for that cost it seemed to be less prone to issues than other approaches in the 2010-2020 era.
This doesn't seem to be using Wine though, as it requires Docker it's likely something lower level than a compatibility layer that translates syscalls.
This looks more like a wrapper over Qemu/KVM
How does this differ from WinApps?
More polished UI, easier to set up (distributed as an AppImage + a Windows Docker image), and it's written in Typescript + Go, whereas WinApps is mostly a collection of Bash scripts that requires you to manually set up your own Windows VM first.
But the core concept is the same, using RDP's RemoteApps feature via FreeRDP for the "seamless" integration.
" Run Any App: If it runs on Windows, it can run on WinBoat. Enjoy the full range of Windows applications as native OS-level windows in your Linux environment"
Bold claim. Lets see it run Fortnite with anti-cheat.
Isn't this similar to WSL-G on Windows to run Linux graphic apps.
Just patiently waiting for a proton for Apple to come around. Seems like it's probably mostly a hardware issue
If you mean 'run macOS apps on Linux', Darling [0] already exists. Running command-line applications is already possible, GUI applications less so.
If you want to run Windows Games on macOS, that is also very much possible. Wine runs on macOS and Apple have themselves developed the 'Game Porting Toolkit' which provides an implementation of D3D12. I understand the best way to use that these days is to use CrossOver [1].
[0] https://www.darlinghq.org/
[1] https://www.codeweavers.com/crossover/#mac
README feels AI.
Anyone tried Adobe products like this? I'm curious to try.
It works, but no GPU acceleration, if you need that. Although there ware ways to achieve that via GPU passthru, it's not for the faint of heart.
So it's just VM?
Does it also run Visual Studio 2022?
It should as it isn't running Windows app through wine but via a dedicated VM (managed by a docker container). Anything that can be ran in a qemu vm, should work fine.
I wonder what is the license of the windows in the dedicated vm?
Seems to be an evaluation license... that said, you can run recent versions of windows unregistered for pretty much as long as you want... they disable some UI enhancements, like changing the desktop, but it tends to function.
Not sure on older versions... MS used to generate new evaluation ISOs every few months with a hard fuse in them... Can't speak for recently since it's been years since I've needed to test for old IE versions. If you choose to customise, I'd suggest going with one of the "lite" modified versions of Windows 10... since this will reduce the default surface a lot without the bridge to some of what Win11 added while jumping the shark.
Forcing people to use a Windows License defeats FOSS projects.
Fairly sure it requires you to have your own copy of Windows; it doesn’t provide one for you. Otherwise it would be a massive licensing violation / piracy. If you look at similar projects like WinApps, that’s how they work.
the requirement to have a windows license would be pretty important and should be mentioned on their GitHub page
What is the difference between me using VirtualBox in Linux for a guest Windows 11, and this dedicated VM?
Hey HN, creator here. (I added my HN profile to GitHub Socials if you'd like to verify)
Honestly, I did not expect WinBoat to blow up as much as it did. I have never released desktop software before that got this large of an audience, I'm equally amazed and humbled by how many people decided to try it and how many different ways there are for things to break. Thanks to each and every one of you who decided to take WinBoat for a spin.
I deliberately did not post on HN, even though I've been recommended to do so. I'm not saying you folks are necessarily mean, but from years of reading I've come to learn that HN has a very critical eye. WinBoat is not feature-complete or an entirely stable experience, so I don't consider it worthy for HN. As such, I'm sorry if I disappointed anyone.
I'll try to answer some of your questions or criticisms honestly without bs.
Q: Why the hype if it's not seamless? A: No software will ever perfect, but almost all programmers dream of people one day trying their software. In my view, you have to convince people to try it, then you have to improve it, and then perhaps you can scrape off the Beta label and hope your code stays 100% true to what was promised. This framework doesn't function without people with different machines and setups trying out your software and giving feedback. Alternatively, you could make your tagline "Run Windows apps on Linux with seamless integration (If Docker, Linux, Windows, X11, XWayland, Wayland, and FreeRDP decide to perfectly work together in harmony)", but who would ever write such a tagline?
Q: What's WinBoat? A: An Electron app, a Windows VM in Docker, FreeRDP (with RemoteApps), and a Golang HTTP server largely running PowerShell scripts mashed together into something that's supposed to make your life using Windows apps on Linux easier. It's supposed to be easy and elegant.
Q: Why not use Wine instead? A: Wine is great, you can and most likely should use Wine for all the apps which it works for. WinBoat is more useful for apps that do not play well with Wine, and there's no shortage of such apps.
Q: Why not use WinApps instead? (Directly from winboat.app) A: With WinApps you do the bulk of the setup manually, and there's no cohesive interface to bring it all together. There's a basic TUI, a taskbar widget, and some CLI commands for you to play with. WinBoat does all the setup once you have the pre-requisites installed, displays everything worth seeing in a neat interface for you, and acts like a complete experience. No need to mess with configuration files, no need to memorize a dozen CLI commands, it just works.
Q: Why not contribute to WinApps instead to make it better? A: Their methodology is different. Not worse, just different. They have individual bash scripts that do certain things and leave the rest to the end user. They most definitely don't want Electron, and I don't want a collection of bash scripts the user has to tangle with. We have shared ideals, just go about achieving them differently. That doesn't mean one is better or worse than the other.
Q: Is the text written by AI? A: No, I suspect emojis have something to do with folks saying that it's AI, but it's not. In my opinion emojis just provide a nice visual distinction and make the text a bit more colorful. But I also realize in hindsight that AI-s also write in this style sometimes.
Q: Is WinBoat some vibecoded slop? A: No, I've poured dozens of hours of my time, knowledge, and passion into it. I don't claim to be the best programmer, or hell, even a good one at that, but I'm pretty sure you can't tell Cursor to make WinBoat from scratch and see a functional app an hour later. Much like anyone else, I use Cursor to get small, targeted tasks done and/or autocomplete where appropiate.
One minor/major though... depending on how much of the UI app is front-end code vs back-end, you might look towards a smaller wrapper like Tauri over Electron... It's rust on the "back end" though, so that may be a no-go for you.. but something that might be worth considering.
That said, when adding a full windows VM/Container, it's probably less of an issue.
Why another WinApps instead of contributing and fix problems there?
Because WinApps is just a collection of Bash scripts, and not everyone might want to work on a project of this scale using Bash. In fact, I was considering a rewrite of WinApps myself, using Rust and egui, but never got around to it...