Re: Will 1.8.6 remain compiled with VC6?

> A recompile of ANY library that an extension depends on, because of
> rampant Microsoft incompatibilities. The problem is that any time you
> have more than one application using more than one C run-time (e.g.,
> MSVCRT.DLL and MSCRT80.DLL), you have different memory allocation
> tables, different file handle tables, etc. Microsoft simply DOES NOT
> CARE about this and won't provide any workarounds to make this clean
> and easy.

So I've modified my thinking on this.  Everything you say above is true 
    - but maybe its not an issue after all.  As long as you make sure 
that each dll that allocates memory, file handles, etc. also frees them 
then you are ok.  (more info see 
http://msdn2.microsoft.com/en-us/library/ms235460(VS.80).aspx).

So - are resources ever allocated by one ruby dll (ie, extension) and 
freed by another ruby dll? Hopefully not.  If you're careful, then 
things seem to work fine.

An example is ruby-prof, which works fine against Ruby 1.8.4 when built 
with VC2005.  A counter example is the libxml bindings which use 
ALLOCATE (so ruby.exe) to get memory but use free (so the dll) to 
deallocate it.  But that is a bug - the libxml bindings should use xfree 
instead (so ruby.exe).

Finding those sorts of bugs is easy - a debug build using VC2005 will 
seg fault with an appropriate error message when it happens.

> 
> It is not in the One-Click Installer's mandate to recompile OpenSSL
> using VC8 instead of VC6. Or zlib. Or pdcurses. Or ...

Sure - and as long as Ruby doesn't free any object allocated by those 
dlls it should all work fine.  Thus I see no reason you can't mix and 
match dlls from VC6, VC2003, VC2005 and mingw/msys.  Just don't mix your 
allocations/deallocations.

Note a big downside of VC2003/VC2005 is having to distribute the various 
required Microsoft CRT dlls - that is a royal PITA.  And that is why 
MingW/msys/VC++6 are so convenient - they use older versions of the CRT 
that are on all Windows machines.


Charlie