InfoQ talked to Luis Lavena to learn more on this, apparently urgently needed, new Windows installer for Ruby 1.8.6 and 1.9.

Although very useful for the Ruby community, there must be more exciting things to do than writing an installer?

Yes, indeed there are more funny things to do than building and rebuilding Ruby and it's dependencies until you get it right. The motivation behind it was always to scratch my own itch.

Personally, I've used Ruby on Windows as glue and scripting for my development dealing with C, C++ and even Assembler, Ruby helped me stay on focus and automate several tasks.

I thought it was valuable to share my knowledge and experience gained over the years with the community, which was very receptive and open.

How does this new installer differ from the old one?

The new installer focuses on getting Ruby right, and get it to integrate more properly and easily on Windows.

The second big point of it is to lower the barrier between Linux and Windows users with regards to the tools available. Most of the Windows users that lack the knowledge to build stuff on Windows need to wait for gem authors or other contributors to release native gems for them.

It became a huge deal since the way Ruby builds extensions and how it integrates with the compiler forced the usage of a 12 years old compiler (Visual C 6.0). That compiler not being available on the net made things more difficult to maintain.

This new installer, instead of being based on binary releases provided by some Ruby-core developers, builds completely from scratch, that gave us the opportunity to further tweak configuration options, versions of extensions bundled, etc.

Not only that, but we substituted certain dependencies like GNU Readline with a pure-ruby version called rb-readline.

Aiming to accelerate release cycles, this new installer does not include 3rd party libraries, which consume a huge amount of time to verify and maintain into the installers.

Users are going to get a minimal installer that includes Ruby, RubyGems and documentation, and from there they will be able to install needed gems without to worry about bloated downloads.

Why is creating a new installer such a big deal, can't you just recompile Ruby and be done with it?

While may sound simple, is not just packaging Ruby and shipping it.

Ruby depends on several packages like ZLib, OpenSSL, Readline and many others that require external libraries. Some of those externals libraries are hard to find pre-compiled for Windows.

When those binaries are not present, we need to fall back and build ourselves. One example is that we use a not-so-old version of OpenSSL since they lack up to date binaries and building from source is a very complex task.

Sometimes it is more than just Ruby but the whole ecosystem around it that needs to be updated and tweaked.

If we have a new Ruby binary for Windows, what does this mean for Gems with native extensions? Can I use Gems with native extensions built for the 'old' Ruby use with RubyInstaller's version?

While you can do it, sometimes forcing a gem to work on this version of Ruby would not work. This is one of the reasons RubyInstaller has been in development for the past year.

For those who are familiar with C, the language Ruby is written in, they will know that when compiling C programs they link to a library called CRT for C Runtime library, that offers several low level services like memory allocation, string processing, IO, etc.

Now, when compiling Ruby, it stores inside and in some configuration files the compiler and flags used to built it, so when building with VC6, it defines the RUBY_PLATFORM as "mswin32", and when used GCC it defines it as "mingw32"

In theory, both are binary compatible, but now is up to the Ruby code for some libraries how is going to interact with that.

Some developers include platform specific code in their libraries, and to determine if the library is working on Windows, they check RUBY_PLATFORM and look for "mswin", "mswin32" or sometimes "win"

VC2008 has PGO but VC2008 Express doesn't.I just config(ure) and (n)make as readme told, not using extra options.Maybe gcc's PGO is more powerful but there's no significance performance difference between my native compiled ruby1.9.1mingw and the one from rubyinstaller.

Is your profile up-to-date? Please take a moment to review and update.

Email Address

Note: If updating/changing your email, a validation request will be sent

Company name:

Keep current company name

Update Company name to:

Company role:

Keep current company role

Update company role to:

Company size:

Keep current company Size

Update company size to:

Country/Zone:

Keep current country/zone

Update country/zone to:

State/Province/Region:

Keep current state/province/region

Update state/province/region to:

Subscribe to our newsletter?

Subscribe to our architect newsletter?

Subscribe to our industry email notices?

You will be sent an email to validate the new email address. This pop-up will close itself in a few moments.

We notice you're using an ad blocker

We understand why you use ad blockers. However to keep InfoQ free we need your support. InfoQ will not provide your data to third parties without individual opt-in consent. We only work with advertisers relevant to our readers. Please consider whitelisting us.