bun
bun copied to clipboard
oven-sh
Windows Support
The README and releases tab implies that Windows is not supported for this project. Is this due to WebKit (JavaScriptCore) being exclusive to *nix platforms (Linux, macOS)? Are there any plans to support Windows?
The project works great on linux btw 😀🚀
JavaScriptCore does run on Windows, but it’s less well supported than Unix
The main issue honestly is how bun does I/O. A lot of bun's code makes assumptions that I/O is fast and that reading/writing a file won’t block for long. This is true on Unix, but on Windows, antivirus and locking behavior is different. This means even if bun did compile successfully on Windows, it probably would freeze a lot. This is already kind of a problem in WSL when you access windows files over the network mounted fs. I’m not sure how to fix this yet, but honestly I haven’t put a lot of thought into it
I tried spinning up a Bun Development Container on a Windows 10 with WSL 2 and did not come across any issues. Of course, I just tried the quick-start code snippet only. Still, no hiccups when setting up and getting started so I am happy for now!
In response to the windows filesystem and bun locking thing, I think at least a half decent workaround would be to use non-blocking fs (once it is implemented)
For Windows I/O, it may be possible to leverage the MFT for some operations, namely file enumeration. It is significantly faster than the default provided APIs.
Downsides are that administrator privileges are required to read the MFT, and it's only for the NTFS filesystem. So it has some fairly big disadvantages, but I felt it was worth mentioning.
Otherwise, depending on the amount of files, it might be necessary to open file handles on initialisation and keep them open for files that will be used a lot to avoid third-party AVs from constantly rescanning when the handle is opened/closed.
Possibly out of scope, but it is possible to get all registered security products for a Windows install in user space, it could be used for a warning message to the user that performance may be impacted if third-party AVs are detected.
I tried spinning up a Bun Development Container on a Windows 10 with WSL 2
Just so that its completely clear, WSL is not native Windows. WSL is essentially a Linux emulator inside Windows. Its about the worst case scenario of "this works on Windows" that you can get. Most Windows devs probably wouldn't even consider a project to support Windows, unless it can do so outside the context of WSL.
Just so that its completely clear, WSL is not native Windows. WSL is essentially a Linux emulator inside Windows. Its about the worst case scenario of "this works on Windows" that you can get. Most Windows devs probably wouldn't even consider a project to support Windows, unless it can do so outside the context of WSL.
WSL2 is not a "a Linux emulator inside Windows" but a compatibility layer using a highly optimized subset of Hyper-V that enables running ELF64 Linux binaries natively on Windows. It has magnitudes less overhead compared to emulation or other virtualization technologies such as VirtualBox or VMWare. Sure, there is an overhead of using WSL but most of it is in higher memory usage and not so much in CPU or I/O. Phoronix test suite using WSL on Windows 10 shows you get around 87% overall performance (with WSL2) compared to bare metal and that should have improved with Windows 11.
Not saying we don't need native Windows support without WSL in Bun, but for development WSL2 should be just fine. As long as you don't plan on running Bun in production on a Windows Machine ;)
WSL2 is not a "a Linux emulator inside Windows" but a compatibility layer using a highly optimized subset of Hyper-V that enables running ELF64 Linux binaries natively on Windows. It has magnitudes less overhead compared to emulation or other virtualization technologies such as VirtualBox or VMWare. Sure, there is an overhead of using WSL but most of it is in higher memory usage and not so much in CPU or I/O.
You can use all the downvotes and bold text you want, but it doesn't detract from the simple fact that its not running a Windows native program, its running a Linux program on Windows using an emulator. Use whatever term you feel is correct, but that's ultimately whats happening. Otherwise you wouldn't say "it runs on Windows using WSL", you would just say "it runs on Windows", or "it runs on Windows natively". I notice you didn't mention Cygwin or MSYS2 either, which are also quite slow compared to native solutions.
WSL isn't, and never will be at the level of native Windows programs. I have been developing for Windows for many years, including professionally. WSL is at least an order of magnitude slower than native options. So yes, while it might be a good stopgap, its not a good longterm solution.
For me the main concern with WSL as a substitute for native Windows support isn't performance. It is that WSL adds a layer of complexity to getting any editor tooling working with Bun. Yes, there are ways for editors running natively on Windows to communicate with and run binaries in a WSL environment, but the last time I tried (about a year ago with Crystal), those solutions were quite fiddly and unreliable compared to programming languages with native Windows support.
I can share a bit of different use case: I need the capability to manage npm packages and bundle code not for tooling, but on the user end of a Tauri app (similar to Electron, web apps on desktop). The end user's device could be Windows/Mac/Linux. Right now I use a combination of npm and esbuild for this. Bun would simplify this to a single dependency and improve performance on package management massively. It quite simply doesn't work with WSL since I'd need to ask the user to set up WSL.
This is just to say there are (admittedly, weird) use cases where "WSL" vs. "native" makes a difference, regardless of the technical distinction. So I appreciate this kind of Windows support is being worked on!
I also find the proposed timeframe reasonable. If you need to get it done faster, I assume you can help out, it's open source afterall. ;)
Hi folks, just want to give assurance that we know the lack of Windows support is painful. Our goal is to have an official build for Windows before the 1.0 release of Bun, though we want to get it done much earlier than that.
We are already starting to experiment with JavaScriptCore on Windows, which is the first big step.
For Windows I/O, it may be possible to leverage the MFT for some operations, namely file enumeration. It is significantly faster than the default provided APIs.
Downsides are that administrator privileges are required to read the MFT, and it's only for the NTFS filesystem. So it has some fairly big disadvantages, but I felt it was worth mentioning.
Otherwise, depending on the amount of files, it might be necessary to open file handles on initialisation and keep them open for files that will be used a lot to avoid third-party AVs from constantly rescanning when the handle is opened/closed.
Possibly out of scope, but it is possible to get all registered security products for a Windows install in user space, it could be used for a warning message to the user that performance may be impacted if third-party AVs are detected.
Detecting AVs are a great way to set off the AVs alarm
So to add my 2 cents. Glad that it's on the roadmap & planned although I maybe don't have the same emphasis on performance. While I agree that a performant windows version of bun is extremely valuable and should probably be included before 1.0, I don't care if it's slower as long as it works. I feel like a use case that is being ignored here is simply the fact that a lot of development happens on windows even if that code runs on linux servers. So for me, it's worth having it running on windows no matter how slow because when it runs on the server in production it will be fast & efficient.
Other than that just +1 for adding windows support
Hi. I understand that this is under work, but is there any work item tracking all the pieces that need to come together for this? That way it will be easier for people to contribute. Also, is there a dev branch to keep track of for this?
I myself don't need networking right now, but the ffi and typescript engine only.
We expect to have a bun install-only version for Windows initially, and then a more complete version following that.
We expect to have a bun install-only version for Windows initially, and then a more complete version following that.
how much time it will take?
There has been some progress on Bun on windows, but it has been slow. The build last time I checked was able to compile, but it doesn't yet function enough to be usable in any context. https://twitter.com/jarredsumner/status/1649193297758556161
It will be something we get done before 1.0
I really want to give it a try :)
Could try it on WSL for now (at least that's what I did)
The main issue honestly is how bun does I/O. A lot of bun's code makes assumptions that I/O is fast and that reading/writing a file won’t block for long. This is true on Unix, but on Windows, antivirus and locking behavior is different.
There's a newer API for I/O on Windows called IoRing, it's a completion-based API modelled after io_uring.
- https://windows-internals.com/ioring-vs-io_uring-a-comparison-of-windows-and-linux-implementations/
- https://windows-internals.com/i-o-rings-when-one-i-o-operation-is-not-enough/
👇 CLICK TO VIEW IMAGE
When I was looking at how to do cross-platform, nonblocking I/O for databases, I found someone had wrapped Windows IoRing in an io_uring API:
- https://github.com/CarterLi/libwinring/tree/master
Maybe something like this could be useful for Bun, since it relies heavily on io_uring for I/O and scheduling already?
Jarred Sumner @jarredsumner whenever something is blocking you from using Bun, please say on GitHub or anywhere and don’t feel bad writing comments like “any updates?” if it’s a blocker
any updates?
Our goal is to have an official build for Windows before the 1.0 release of Bun, though we want to get it done much earlier than that.
Not much time left for 1.0...
Team is working hard on Windows support and I'm sure they will deliver it before 1.0 as expected. No need to post "any updates?" because when they are, they will notice us.
Jarred Sumner @jarredsumner whenever something is blocking you from using Bun, please say on GitHub or anywhere and don’t feel bad writing comments like “any updates?” if it’s a blocker
any updates?
@dylan-conway got our build of JavaScriptCore to compile & run on Windows yesterday. We bought a a Windows laptop for the office. But no big update yet other than we are working on it
Hi folks, just want to give assurance that we know the lack of Windows support is painful. Our goal is to have an official build for Windows before the 1.0 release of Bun, though we want to get it done much earlier than that.
We are already starting to experiment with JavaScriptCore on Windows, which is the first big step.
@Jarred-Sumner @dylan-conway is Windows still planned to be supported when Bun 1.0 gets released on Sept. 7? or will that be coming later in a feature version? I'm asking because September is not that far away... 😉
@Jarred-Sumner @dylan-conway is Windows still planned to be supported when Bun 1.0 gets released on Sept. 7? or will that be coming later in a feature version? I'm asking because September is not that far away... 😉
I think one of the Bun 1.0 goal are windows support. We have some blocks from WebKit, but we're working on it. 😃