WinBoat: Run Windows apps on Linux with seamless integration
86 points - today at 4:24 AM
SourceSomething 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.
Turskarama
today at 8:01 AM
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.
gchamonlive
today at 11:05 AM
> 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...
"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.
globnomulous
today at 10:52 AM
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.
akimbostrawman
today at 7:53 AM
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.
prmoustache
today at 7:50 AM
I don't think one should ever expect a "true seamless integration" from this kind of project.
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.
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?
nemomarx
today at 12:07 PM
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
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.
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.
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.
SillyUsername
today at 7:50 AM
It's running RDP to a Winboat docker image hosting the app and rendering the container on the desktop. This includes audio forwarding.
How is there an entire page without a single line describing how it works?
burgerone
today at 8:11 AM
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.
dinkblam
today at 11:06 AM
wouldn't this require a license? windows is not free in any sense of the word
I've been down this road so many times with Wine configs and broken prefixes that I have trust issues, lol.
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.
deathlock
today at 7:13 AM
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
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.
SirGiggles
today at 7:39 AM
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.
worldsavior
today at 10:36 AM
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.
orionblastar
today at 6:10 AM
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?
cyanmagenta
today at 11:20 AM
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.
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...