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.