[Rubyinstaller-devel] Moving Ruby 1.9.1 forward on Windows

Roger Pack rogerdpack at gmail.com
Wed Mar 18 09:54:09 EDT 2009

So perhaps somebody could answer some questions for me I'm a little confused.
I hear things like "you can compile against any version of msvcrt.dll you want"
and then...the question is
you don't actually need to have that specific version of msvcrt.dll
installed in the system, by default it will just "use" the version
that's contained in msvcrt-ruby....dll
Is that right?
does "msvcrt-ruby...dll" contain a copy of msvcrt.dll within itself?

Also, was there any concensus on whether errno differences were fatal?

Sorry to bore Luis with this stuff :)
And in the end I don't care what happens.

I'd be happy to spearhead any devkit gem, as well.


On Mon, Mar 16, 2009 at 1:10 PM, Luis Lavena <luislavena at gmail.com> wrote:
> 2009/3/16 William Green <will at hotgazpacho.org>:
>> Michael,
>> VC6 runtime may be on "all Windows", or available for download from
>> Microsoft, but the VC6 development tools (specifically, the compiler and
>> linker) are not available any longer, and I highly doubt they would even run
>> on Vista. So, unless you already have a copy of the VC6 dev tools, you
>> cannot obtain one now.
> To put this in better words:
> MSVCRT, Microsoft Visual C Runtime library is available in all the
> Windows versions (since 95 AFAIK).
> MSVCRT.dll, often defined as version 6.0 has been available since NT4
> The real thing is that MSVCRT cannot be updated with new API since
> breaking that library will break all the programs that link to it.
> Anyhow, MS managed to make 7.0 version of that DLL in XP Service Pack
> 2 (7.0.2600.2180), so is not out dated as someone pointed before.
> The new development and new features cannot happen in that version,
> that's why MS built MSVCR80 and MSVCR90.
>> This, I believe, is the reason for the MingW32 build in the first place; all
>> the build tools are available, and not controlled by Microsoft.
> Yes, MinGW is a freely available alternative that links to the same C
> Runtime library.
> Even more, the advantage has been proven building gems for Windows
> from Linux or OSX.
> And ignore for a second the speed stuff.
>> Luis, am I totally off-base here, am I missing something?
> However, the problem with that is not the compiler, but Ruby. Ruby
> uses "mingw32" and "mswin32" to identify the platform used to build
> the interpreter, so that defeats every attempt to interchange the
> compilers.
> Even more, it prepends the runtime used "msvcrt" to the dll of ruby:
> msvcrt-ruby18.dll for both mingw and mswin32, and "msvcr90" for ruby
> build with VC2008.
> I'm kind of getting bored by this whole discussion, since I already
> had this like 3 years ago, and the year after, and last year.
> It doesn't matter if we do MinGW/GCC or VC2008 or VC3000, changes will
> need to happen in both the development of Ruby and the gems being
> created by others, so, what will be the less painful process for
> everybody?
> --
> Luis Lavena
> AREA 17
> -
> Perfection in design is achieved not when there is nothing more to add,
> but rather when there is nothing more to take away.
> Antoine de Saint-Exupéry
> _______________________________________________
> Rubyinstaller-devel mailing list
> Rubyinstaller-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rubyinstaller-devel

More information about the Rubyinstaller-devel mailing list