Windows support

I would like for Crystal to get support on Windows


Coordinate porting to Windows · Issue #5430 · crystal-lang/crystal · GitHub. PRs are welcome :slight_smile:.

1 Like

I would like to know if there is a release date planned for the Windows version of the language.

Also, I would like to know if an application created on Linux currently runs on Windows, without the need for Windows Subsystem for Linux to be installed.


1 Like

Not that I’m aware of. It’ll be when everything in that one issue is checked off.

It is possible to compile things on Windows, but with some limitations, mainly IO and networking. See Running Crystal natively on Windows, building videogame examples - Blog - Oleh Prypin. However even when Windows support is completed it’s not as simple as using a binary compiled for Linux on Windows.

Thank you for answer.

I hope it don’t take a long time to be finished.
I liked the fact of Crystal be statically type checked and as easy as Ruby.
But, like Ruby, there a possibility to compile to a byte code or it is only to an executable?
Is it possible to compile to a module (.dll or .so)?
I was thinking to do a Crystal release of our ReOb framework, but, being a framework, it would be released as a module to be imported by the application (.dll or .so).

Thanks again.

There is no release date for full windows support scheduled. We’re focusing on a stable 1.0 release first. Hopefully we can ship full windows support in one of the next minor releases.
But windows support is already pretty good, you can do a lot of stuff on windows. It’s not production ready, but for many use cases development on windows should work very well.

Crystal’s stdandard library aims to be cross-platform compatible. A program that builds for linux should also build for macos or windows for example.

Of course you won’t need WSL to run a Crystal program on windows. The compiler already builds on windows and we run CI against it. And it’s pretty stable.
You can’t run the exact same executable on windows and linux, but that should be obvious because they have differene executable formats.

Crystal uses LLVM as backend for code generation, so you can technically compile to any format supported by LLVM. For example LLVM bytecode with crystal build --emit llvm-bc. I’m not sure how useful that is for portable executables (I assume that’s what you’re aiming for). Probably not much.
It would require LLVM to run the bytecode and you loose a lot of the benefits of compiling directly to a binary exectuable format.
You can technically build a library from Crystal code. But there are some gotchas concerning the standard library runtime which isn’t expected to be compiled into a binary library.

Crystal libraries are usually distributed as source code and directly compiled into the final executable. This allows the compiler to analyze the entire program and do its magic.



So I understood that:

  1. Crystal compiles directly to binary code (like C, C ++, Pascal) instead of compiling to byte code running on a virtual machine (like C#, Java, Ruby and Python), which means that each supported platform will require us to recompile directly for them.

  2. The shared library (like .dll and .so) appears to be out of the scope of the compiler, at least for now.

For our framework to be called in its compiled version by other applications, it would be necessary to release it as a shared library. Then, this is out of question for now.

Thank you for your attention.

Yes, Crystal is intended for writing applications, not C-compatible libraries.

The main issue is that Crystal’s standard library comes with a rather huge runtime. That’s something you probably don’t want in a library. But the stdlib requires it.

May I ask what exactly is your use case?

If that implies generating a rather huge executable file on windows as the easiest way to support this OS…

You may consider that executable files size on windows are often pretty fat, it doesn’t seem to bother users that much…