[ruby-core:23046] Back to ruby19.dll

Hi everyone,

A couple of weeks ago 
(http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/22727) I 
proposed renaming the ruby shared library to ruby19.dll on windows.  Let 
me try again, maybe this time I'll be more convincing :)

Right now ruby includes the c runtime version in the ruby shared library 
name, so msvcrt-ruby19.dll or msvcr90-ruby19.dll.

I think this is a bad idea.  My conclusions are (read below if you want 
the details):

Conclusion #1 - Ruby can be use any c runtime.

Conclusion #2 - In some cases, a extension needs to use the same c 
runtime as the library it wraps.  This can happen with old, outdated 
libraries or unix-centric libraries.

Conclusion #3 - Libraries on windows are linked against a variety of c 
runtimes - pretending that msvcrt.dll is the one true library is fantasy.

Including the c runtime name in the ruby dll solves *no* issues.  But it 
does mean that gem maintainers have to provide multiple binary gems for 
windows depending on how Ruby is built.  And that is a bad idea that 
will impede adoption of ruby 1.9.1 on windows.

And now onto the gory details.


Extensions
=============
A typical ruby extension includes three parts - ruby, the extension and 
the library being wrapped.  Each can use a different version of the 
c-runtime.  As discussed many times before on this list, this leads to 
three potential issues - memory handling, errno handling and files handling.

So where do problems arise?  Let's take a look:

           ruby  <--->  extension  <----->  library
memory                               x
errno                                x
files             x                  x
 

This diagram shows that memory and errno handling is a non-issue between 
ruby and an extension.  This is because Ruby provides the ALLOC/xfree 
api for memory, and as far as I know, Ruby and extensions do not use 
errno to communicate (instead an extension should use rb_raise).

However, passing file handles on windows requires ruby, an extension and 
its library to all use the same c runtime.  Since that's unlikely (see 
below), it should be considered forbidden on windows.

Conclusion #1 - Ruby can use an c runtime version.  Adding the runtime 
library to ruby19.dll is pointless.


Problem Libraries
=================
In contrast, the diagram shows all three issues can arise between an 
extension and a library.  Let's look at two problem libraries:

gdbm - Does not provide an api to free memory that it allocates.  This 
is an old unix library that hasn't been updated since 2002 and I doubt 
is used much on Windows.

iconv - Uses errno to pass error information.  This is a popular library 
that is unix centric.  Looking at the Ruby extension, it could in fact 
get by without using errno, but that would be less satisfactory.

In both these cases, the extension has to use the same c runtime as the 
library itself (once again, it doesn't matter what c runtime ruby uses).

Conclusion #2 - In some cases, a extension needs to use the same c 
runtime as the library it wraps.  This can happen with old, outdated 
libraries or unix-centric libraries.


Modern Libraries
=============
Now let's look at some examples at common libraries and how their 
windows binaries are distributed:

postgreql - mscvr90 (VC 2008)
opensll   - mscvr90 (VC 2008)
freeimage - cleverly does not link against a c runtime (unknown)
libxml - msvcrt (windows xp ddk)
zlib - msvcrt

All of these libraries work fine, even when using a different c runtime 
than ruby or an extensions  In general, I've found that any modern 
library that is used on windows provides a memory management api, 
doesn't use errno and doesn't require passing file handles around.  If 
they did not, then they would not work well on windows (ruby of course 
isn't the only program to have c runtime issues).

Conclusion #3 - No matter what runtime Ruby links against, it will use 
libraries on windows that use a different runtime.

Summary
===========
I realize what I am proposing is controversial.  But if you look at how 
extensions are built, and real-world examples, hopefully it becomes 
clear that adding the c runtime version to the ruby shared library name 
does not solve any technical issues.

But it does put an undue burden on gem maintainers.  The days of 
msvcrt.dll and VC6 are over.  We must expect ruby 1.9.1 will be built 
with a variety of compilers - VC2008, VC2010, mingw and the Windows DDK. 
  Right now, gem maintainers would have to provide three different 
binary gems for windows (msvcrt-ruby19.dll, msvcr90-ruby19.dll, 
msvcr10-ruby19.dll).  That of course will never happen.

So what we should do:

* Rename the ruby shared libary to ruby19.dll
* Package gdbm and iconv with the windows one-click installer to make 
sure the extensions and library use the same c runtime (this already 
happens anyway)
* Clearly document to extension writers how to make their extensions 
windows compatible

Thanks,

Charlie