In May, John Lam (behind Ruby CLR) put me in touch with the Visual Studio team at Microsoft. They were very concerned that the Ruby interpreter was being built on an obsolescent version of the Visual C++ compiler and were wondering what might be able to be done toward getting Ruby built with Visual Studio 2005. On June 26th, I had a conference call with the team and pointed out issues that I had experienced in the past and where I had stumbled currently. I posted a message (
[ruby-talk:199211]) immediately after seeking specific issues to deal with. So here I am, seeking even more than I’ve gotten already.
They asked for as much information as I can gather on this matter. If you have had problems trying to get Ruby or an extension compiled or running on Windows for any reason, but especially because of Microsoft runtime DLL differences, please provide me as much information as possible so that I can pass it on to the VS team at Microsoft.
I’ve already heard complaints about compile-time compiler options and general annoyance at incompatible ABIs between runtimes, and suggestions on how to reduce the dependency of an extension on any given Windows runtime. It doesn’t solve the fundamental issue of memory management (and general resource management) between an extension, Ruby, and the library that the extension is written for possibly being tied to three different runtimes.
For what it’s worth, I have Ruby itself compiled with VS 2005, although some of the extensions are not being built automatically, from what I can tell. That may be a build script problem. However, based on earlier reports of runtime version incompatibilities, it was looking like I was going to have to recompile a *lot* of code. The discussion today suggested that as long as function accesses are used and not variable accesses, things will be okay (e.g., GetError() in Windows, not errno). The problem, as I pointed out to them, is that *most* Unix developers only ever have to worry about a single C runtime being on their system and therefore don’t need to worry about errno being in a different runtime DLL. Ideally, they would be able to give us an external way of getting at the errno from a specific
runtime that may not be “our” runtime (e.g., the runtime with which we were linked).
So, I ask you: What other problems have people had and what can you provide me as evidence? Also, can I give them your name and email for direct contact? I will be headed to Europe soon and won’t be able to respond quickly.
[Update 2006.09.11: I am closing this entry’s comments as several spam attempts have been made. If you have issues to report, please report them on comp.lang.ruby and I’ll see them on ruby-talk.]