My personal Crystal on Windows expectations

Spin off from my comment to @straight-shoota from this thread:

Once upon a time…

For a long time I developed and released RubyInstaller, a Ruby for Windows distribution that aimed to ease new developers install and use Ruby on Windows OS, something that was really complicated and made life of many newcomers complicated.

In order to facilitate that, learnt the need to leverage on MinGW (and mingw64 later in the process) instead of Visual Studio/C installer to build and support the project.

  1. Leverage on a GCC-like compiler made it easy to non-Windows developers to understand what was going on the build process for their libraries/applications
  2. Thanks to development of tooling like rake-compiler, it made it easy for those non-Windows developers to cross-compile from the confort of their Linux/macOS setup without having to worry about a Windows license or a VM to test things out.
  3. RubyInstaller’s “DevKit” allowed non-fuss distribution of a ready-to-use compiler and libraries necessary to install those Ruby gems that didn’t had binaries for Windows, or be able to install the required dependencies for those to successfully compile.

This was an uphill battle: the official Windows binary for Ruby was still compiled with VC6, too old MSVCRT (the C library used by Windows) with no inclusion of binaries for the extensions that were compiled.

Getting Ruby to compile with MinGW was not magic, took years but helped move around these limitations, specially free the users from having to obtain an old compiler, a license or figure out a free version to download.

Things have improved since then, usage of MinGW and MinGW-w64 has grown and today is more easy to cross-compile and support windows than it was 15 years ago, when I started.

Enough nostalgia Luis, get to the point

There has been a massive effort by Crystal developers to get Windows support in, so it becomes one of the supported platforms, and that is monumental for Crystal to succeed as a viable platform. While not there yet, I do believe it will eventually do it, and it will be done with the high level of care shown by all the developers and contributors of the language.

So, to answer the original question, my expectations align more on:

  • For a Crystal developer on either Linux or macOS to easily target compilation of their applications to Windows platform, without having figure out Windows VMs and complex incantations to get Visual C compiler or support libraries
  • Not assume that a Windows developer will be familiar with Visual C (or have it installed) or all the complexities involved on getting things compiled on Windows natively.

This means something that works across these walled worlds, without too much need for translation.

I know some of these things are beyond the realm of Crystal itself, but could be considered when guiding the future decisions of the project.

If you reached this point, thank you for standing up with my mumblings :sweat_smile:

Cheers.

3 Likes

If the Crystal GUI installer offers to install a modern MSVC toolchain and the Windows SDK on behalf of the user, is it any different from RubyInstaller offering to install MSYS2?

Yes, the libraries, linker and related processes will be different. Someone trying to cross-compile an application for Windows will need to use a Windows VM, get Crystal Installer on it and develop on an environment they are not familiar with in order to deliver their applications.

To avoid that they might try to get the libraries and attempt to cross-compile from Linux/macOS, or decide to give up because is too complicated to support it.

Note that RubyInstaller+DevKit ships with MSYS2 to ease dependency installation (pacman), but packages are MinGW ones and could be downloaded, extracted and used (linked) with a GCC/Clang cross compiler.

I’m not sure how much this helps on the Windows side of things but I created Crimson not too long ago and have used it ever since for all of my Crystal projects, the majority of which have to work across platforms. It doesn’t do much on the building side of things but definitely simplifies installations and version management, I can confidently say that it’s much easier to use than the current methods for installing Crystal and its dependencies on Windows.

1 Like

I just tried CRIMSON on MacOS and found out that it is not yet supported. I would like to try it on Windows, Linux, and other operating systems later.

1 Like

Thank you for sharing, didn’t know about Crimson and looks interesting as version manager for Crystal.

I was not able to find in the README anything that covers the points I was sharing, like cross-compilation, to allow a Linux user of Crystal to generate executables for Windows, or vice versa.

It seems it does install the dependencies natively for each OS (each Env install_dependencies section), it depends on that specific platform to execute, so you cannot get all the necessary Windows dependencies and be able to generate executables from your Linux installation.

While you can generate MSVC object files to link to, the dependencies and the necessary .lib files might not be accessible or installable from a non-Windows environment.

Ideally having support for *-windows-gnu as platform could help with that.

Cheers,

1 Like

No worries :sweat_smile: I have thought about supporting the points you’ve made, but probably as a separate tool given that Crimson’s primary focus is version management. Maybe a tool that operates off its underlying structure? But that’s for another post.

That is precisely what I’m trying to build, and I’m blogging about it:

See Works, but it could be better at the bottom of Part 2 :wink:

Cheers.

1 Like