Winboat: Run Windows Apps on Linux with Seamless Integration
Posted4 months agoActive4 months ago
github.comTechstoryHigh profile
skepticalmixed
Debate
70/100
Windows on LinuxVirtualizationRemote Desktop
Key topics
Windows on Linux
Virtualization
Remote Desktop
WinBoat is a new project that allows running Windows apps on Linux with seamless integration, but the community is questioning its novelty, technical details, and claims.
Snapshot generated from the HN discussion
Discussion Activity
Very active discussionFirst comment
2h
Peak period
70
Day 1
Avg / period
13.3
Comment distribution80 data points
Loading chart...
Based on 80 loaded comments
Key moments
- 01Story posted
Sep 2, 2025 at 12:24 AM EDT
4 months ago
Step 01 - 02First comment
Sep 2, 2025 at 2:10 AM EDT
2h after posting
Step 02 - 03Peak activity
70 comments in Day 1
Hottest window of the conversation
Step 03 - 04Latest activity
Sep 15, 2025 at 12:32 AM EDT
4 months ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
ID: 45099124Type: storyLast synced: 11/20/2025, 5:42:25 PM
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
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.
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
But the core concept is the same, using RDP's RemoteApps feature via FreeRDP for the "seamless" integration.
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
Very handy on the steam deck for some programs
It costs a little bit of money, but it comes with support and directly finds the WINE project (CodeWeavers is a major contributor.)
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.
A different selection of words wouldn't have lead to this debate, which I think is the point being made.
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...
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.
> 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.
Otherwise looking at the code this feels like something that could be a short bash script wrapped in a electron app.
[0] https://github.com/dockur/windows?tab=readme-ov-file#is-this...
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.
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.
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.
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.
That said, when adding a full windows VM/Container, it's probably less of an issue.
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
Bold claim. Lets see it run Fortnite with anti-cheat.
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).