Binaries, forks, and FFI
There has been some concern from the community about having another fork of Ruby will be "bad" for the community. This notion is patently false. There are already many forks of Ruby, and none of them have harmed the overall Ruby ecosystem. We have MRI (Matz Ruby Implementation), JRuby (Ruby on the JVM), Rubinius (Ruby in Ruby via C++), Maglev (Ruby on Smalltalk), MacRuby (Ruby in Objective C) and recently RubyMotion (Ruby for iOS). The RubyInstaller folks even have project called "Fenix", described as a "rebirth and renewal of Ruby", not a full fork, but a series of improvements for Windows. (There was also IronRuby, a Microsoft funded effort to reimplement Ruby in C#, though it is now defunct.)
Each of these bring something interesting to the table, and are "good" for the Ruby ecosystem in that they provide users (or vendors, or managers, or whoever) a choice of implementations that best suit their business needs. JRuby in particular, with its ability to interface with Java libraries and work in the Google App Engine, is definitely the most popular alternative to MRI. And so, I can say with confidence that WinRuby will not harm the Ruby ecosystem any more than any other fork of Ruby. WinRuby will simply be another choice for Windows that vendors can choose from if they feel it best fits their business needs.
Another concern that has been brought up is that gem authors "will have to work twice as hard to target both RubyInstaller and WinRuby binary installations". Here's the thing. They shouldn't have to. First, let's distinguish between the two types of binaries we have to deal with.
The first is Ruby gems themselves, i.e. Ruby extensions written in C and precompiled so that you don't have to compile code yourself. A binary created using the RubyInstaller DevKit will (probably) not work with a Ruby built with Visual Studio because they have different runtimes (i.e. they aren't compatible). The concern is that gem authors will have to ship multiple binaries to make sure they work with both the RubyInstaller and WinRuby.
The first solution here is simple: let users build from source. Shipping binaries is fine, but you should ALWAYS give users the chance to build from source. In fact, this is what I do with my win32-api gem. If you're using the RubyInstaller and you type "gem install win32-api", you'll get a precompiled binary. If you're using the Microsoft toolchain, it builds from source. Either way it Just Works (TM). This is how all Windows gems should be pushed.
If you're a Windows developer, then I assume that you have access to development tools, i.e. the Microsoft toolchain. There's even a free version of Visual Studio available. Building from source against 3rd party libraries does, of course, mean that you'll need those header files to build against. This is standard operating procedure on Linux or OSX. It will be no different for Windows users. At worst, you'll have a build farm out there somewhere that does it for you, and you'll need to distribute compiled builds out from there but it's still possible.
The second solution is better: use FFI, the foreign function interface for Ruby. It let's you interface with C libraries using pure Ruby code. No extension or compilation required. Until recently this would not have been an option because FFI only worked with the GNU (i.e. DevKit) toolchain. However, some fantastic work by Park Heesob has made using FFI with the Microsoft toolchain now possible. That means that no matter which toolchain you've chosen, any code you write using FFI will again Just Work. You no longer have to worry about runtime compatibility, C99 compatibility issues, and so on.
Another huge advantage to using FFI is that your code will not only work with either WinRuby or the RubyInstaller, it will work with JRuby, too! So, if your shop has already settled on JRuby as its implementation of choice, you'll be providing them with more options in terms of library availability.
In fact, that's one of the goals of the WinRuby project - to convert a large number of Ruby libraries from either win32-api or plain C to use FFI! It's not a small effort, and that's part what the funding would be used for.
The second kind of binary we'll have to deal with are 3rd party libraries. Stuff like zlib, openssl, sqlite, and so on. With mingw (and a bash shell) you simply run the standard "configure; make; make install". With the standard Microsoft toolchain, however, that simply isn't an option.
Here is where my consulting can help you. I can show you how to build those libraries using Visual Studio, and how you can then build the related Ruby libraries.
seconds to go
Pledge $10 or moreYou selected
4 backers Limited (996 left of 1000)
Receive a hand written thank you note for sponsoring this project.Estimated delivery:
Pledge $25 or moreYou selected
5 backers Limited (995 left of 1000)
Previous rewards plus a custom backer sticker!Estimated delivery:
Pledge $100 or moreYou selected
Previous rewards plus a free code review and test run of one Ruby library of your choice.Estimated delivery:
Pledge $250 or moreYou selected
Previous rewards plus 1 year of free continuous integration on Windows for one Ruby library of your choice.Estimated delivery:
Pledge $1,000 or moreYou selected
Previous rewards plus personal recognition on the website as a backer. If this price is too steep for you personally, this is a good opportunity to ask your company to contribute.Estimated delivery:
Pledge $5,000 or moreYou selected
Previous rewards, plus corporate recognition on the website as a backer.Estimated delivery:
Pledge $10,000 or moreYou selected
Previous rewards, plus corporate recognition on the website as a backer with front page presence, plus 1 year of free continuous integration on Windows for one Ruby application of your choice.Estimated delivery:
- (30 days)