Windows Support

[philippdormann]

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 😀🚀

[Jarred-Sumner]

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

[kosperera]

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!

[meadowsys]

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)

[xhyrom]

[ldsenow]

Haha. I like how you urge the importance of having a Windows version.

[Unnoen]

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.

[kpldvnpne]

Is there any way I can contribute to help speed up windows support?

[mekwall]

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 ;)

[FeldrinH]

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.

[salmenf]

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. ;)

[Electroid]

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.

[mollthecoder]

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

[CEbbinghaus]

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

[rishavs]

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.

[umararshad4]

when will window support available??????

[RinMinase]

Is this feature perhaps removed from the priority list? 🤔

[Jarred-Sumner]

We expect to have a bun install-only version for Windows initially, and then a more complete version following that.

[umararshad4]

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?

[liudonghua123]

any updates?

[paperdave]

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

[LouieMartin]

This issue is nearing on one year any updates for support in Windows?

[Master-Y0da]

I really want to give it a try :)

[sharunkumar]

I really want to give it a try :)

Could try it on WSL for now (at least that's what I did)

[GavinRay97]

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?

[ultimateerror]

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?

[Van-Dame]

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...

[xhyrom]

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]

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

[ghiscoding]

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... 😉

[xhyrom]

@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. 😃

[xhyrom]

According to what dave (core team member) said on 21/07 on bun discord unfortunately Windows support might not come to 1.0 release 😕🙁 It's not certain though, so anything can still happen.

I just know that they managed to print the help menu and run WebKit (JavaScriptCore)

[xhyrom]

I don't have any news but look at https://github.com/oven-sh/bun/tree/jarred/kernel32 :smiley: Jarred is focused on kernel32 (windows)...

[xhyrom]

message link: https://discord.com/channels/876711213126520882/876711213126520885/1145716670657220718

[regent-x]

fingers crossed for the initial release. I really want to try out bun on a windows machine

[mollthecoder]

fingers crossed for the initial release. I really want to try out bun on a windows machine

If possible you can try it in WSL at the moment

[xhyrom]

There is an experimental build for Windows.

Related PR that must be merged to have it on stable version: https://github.com/oven-sh/bun/pull/4410

[mentamarindos]

[Drag13]

Spotting two issues right now with Bun and Windows

Pure Windows 10:

• Not possible to install from npm using npm i -g bun (I believe this is already known issue)

WSL 2

• bunx is not available after the bun install
• Bun hangs when dealing with the selects Checked with bun x create-next-app and bun x create-vite my-app

This hangs forever

[sbscan]

Spotting two issues right now with Bun and Windows

Pure Windows 10:

• Not possible to install from npm using npm i -g bun (I believe this is already known issue)

WSL 2

• bunx is not available after the bun install
• Bun stacks when dealing with the selects Checked with bun x create-next-app and bun x create-vite my-app

This hangs forever

WSL 2 and 1 same, hangs forever

[AlemTuzlak]

Bun install on windows took around 7 minutes

[BenjaBobs]

Any chance of Bun getting on https://github.com/microsoft/winget-cli?

[Gabbydamian]

Spotting two issues right now with Bun and Windows

Pure Windows 10:

• Not possible to install from npm using npm i -g bun (I believe this is already known issue)

WSL 2

• bunx is not available after the bun install
• Bun hangs when dealing with the selects Checked with bun x create-next-app and bun x create-vite my-app

This hangs forever

I'm extremely new to contributing, so forgive me.

But isn't the usage for bunx bunx ... as opposed to bun x?

Or was it a typo?

Thank you.

[Drag13]

Spotting two issues right now with Bun and Windows

Pure Windows 10:

• Not possible to install from npm using npm i -g bun (I believe this is already known issue)

WSL 2

• bunx is not available after the bun install
• Bun hangs when dealing with the selects Checked with bun x create-next-app and bun x create-vite my-app

This hangs forever

I'm extremely new to contributing, so forgive me.

But isn't the usage for bunx bunx ... as opposed to bun x?

Or was it a typo?

Thank you.

bunx is not working on WSL 2 for some reason, but bun x does. There was an issue regarding it

[xhyrom]

I'm extremely new to contributing, so forgive me.

But isn't the usage for bunx bunx ... as opposed to bun x?

Or was it a typo?

Thank you.

bunx is just link to bun x

[Gabbydamian]

I'm extremely new to contributing, so forgive me.

But isn't the usage for bunx bunx ... as opposed to bun x?

Or was it a typo?

Thank you.

bunx is just link to bun x

Okay. Thank you so much for clarifying.

[robisadev]

bunx is not working on WSL 2 for some reason, but bun x does. There was an issue regarding it

Use bun completions /path/to/folder to fix, afterwards bunx should work.

[Rednas83]

Just tried it but I get some errors with bun install and with setRawMode in the wsl terminal

[AlemTuzlak]

I wrote down all the painpoints I experienced with Bun on Windows in a blog post, you can check it out here: https://alemtuzlak.hashnode.dev/why-i-cant-love-bun Edit: People have pointed out that I need to use VM's linux filesystem and I updated the article to use that, I also added a new section as to why I think Windows adoption needs to be easier than this

[benmerckx]

I wrote down all the painpoints I experienced with Bun on Windows in a blog post, you can check it out here: https://alemtuzlak.hashnode.dev/why-i-cant-love-bun

You're running into limitations of using the mounted Windows filesystem in WSL2, this is not really Bun related. Try using Bun in the VM's linux filesystem.

[Seblor]

I wrote down all the painpoints I experienced with Bun on Windows in a blog post, you can check it out here: https://alemtuzlak.hashnode.dev/why-i-cant-love-bun

I see in your screenshots that you are working with WSL in the Window's file system. This is not recommended, and you even get a warning from VSCode if you open a folder outside of WSL's environment. (More details here: https://learn.microsoft.com/windows/wsl/setup/environment#file-storage)