Rubyinstaller devel - Mar 2009 - Moving Ruby 1.9.1 forward on Windows

Perhaps we should [regardless of whether naming changes are approved
or not] by default link against msvcr90 [from the mingw builds], and
also include the VC2008 runtimes.  That blesses the lives of the
VC2008 people, since they don''t have to worry quite as much about
differing runtime library incompats.  And it probably wouldn''t be too
hard to link against it from mingw.  Is it possible using the cross
compiler tho?
Thoughts?
-=r

On Sat, Mar 14, 2009 at 1:47 PM, Charlie Savage <cfis at savagexi.com>
wrote:
>
>
> Roger Pack wrote:
>>
>> http://www.gamedev.net/community/forums/topic.asp?topic_id=482230
>> that type of thing won''t be a problem, right? or is that the
same
>> problem as described in your previous link to
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36834
>
> That''s a good question. ?Seems like it could the same issue since
they
> mention stack corruption. ?If they had posted all the source code we might
> be able to tell - I''m not sure there is enough info there to tell.
>
> Charlie
>
>

On Sun, Mar 15, 2009 at 12:56 AM, Roger Pack <rogerdpack at gmail.com>
wrote:
> Perhaps we should [regardless of whether naming changes are approved
> or not] by default link against msvcr90 [from the mingw builds], and
> also include the VC2008 runtimes. ?That blesses the lives of the
> VC2008 people, since they don''t have to worry quite as much about
> differing runtime library incompats. ?And it probably wouldn''t be
too
> hard to link against it from mingw. ?Is it possible using the cross
> compiler tho?
> Thoughts?
> -=r
>
AFAIK, none of the mingw32 packages for the different linux
distributions bundle msvcr90 libraries.

Without those, after installing (macport or apt-get package) manually
find/build/install the msvcr90 libraries to properly link to the
specified runtime.

After that, if the user wanted to execute using Wine (to run
specs/test and verify the build doesn''t segfault) they will need to
follow the winetricks:

http://wiki.winehq.org/FAQ#head-a0aa6667e9ba22fad996f7f0d51dc7d161087611

Another issue I see with this, I tell ruby configure about it, but
there is a MSVCRT chooser script that can fake/hide the trick for us.

I''m starting to think that is we are letting MSVCR90 be the default
runtime, why I should bother with MinGW at all.

I should be building Ruby with VC2008 instead...

-- 
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

On Sun, Mar 15, 2009 at 12:40 PM, Luis Lavena <luislavena at gmail.com>
wrote:
> On Sun, Mar 15, 2009 at 12:56 AM, Roger Pack <rogerdpack at
gmail.com> wrote:
>> Perhaps we should [regardless of whether naming changes are approved
>> or not] by default link against msvcr90 [from the mingw builds], and
>> also include the VC2008 runtimes. ?That blesses the lives of the
>> VC2008 people, since they don''t have to worry quite as much
about
>> differing runtime library incompats. ?And it probably wouldn''t
be too
>> hard to link against it from mingw. ?Is it possible using the cross
>> compiler tho?
>> Thoughts?
>> -=r
>>
>
> AFAIK, none of the mingw32 packages for the different linux
> distributions bundle msvcr90 libraries.
>
> Without those, after installing (macport or apt-get package) manually
> find/build/install the msvcr90 libraries to properly link to the
> specified runtime.
>
> After that, if the user wanted to execute using Wine (to run
> specs/test and verify the build doesn''t segfault) they will need
to
> follow the winetricks:
>
> http://wiki.winehq.org/FAQ#head-a0aa6667e9ba22fad996f7f0d51dc7d161087611
>
> Another issue I see with this, I tell ruby configure about it, but
> there is a MSVCRT chooser script that can fake/hide the trick for us.
>
> I''m starting to think that is we are letting MSVCR90 be the
default
> runtime, why I should bother with MinGW at all.
>
> I should be building Ruby with VC2008 instead...
That seems like quite a lot of work for the linux cross compiling
crowd.  Of course, Charlie would probably say they don''t need to link
against msvcr90 they can just link against msvcrt6 and it should work
:)

My concern with it is would we have to be distributing tons of
diferent msvcrt runtimes [like v 7.1 for the 2005 folks, etc.], if
they link against those?  Is there any benefit with trying to not use
msvcrt6 from VC6?  I hear rumors that it isn''t as thread safe? Is it
slower do we know?

I suppose the reality is that most ruby programmers [and extension
developers] at on Linux or OS X, so perhaps we should cater to them by
making msvcrt.dll 6 the default?
I prefer mingw because of the speed, but that''s just my personal
opinion.  The cross compile stuff is nice, too.  I''m ok with sticking
with msvcrt6.
Thoughts?
-=r

MSVC6 is no longer available from Microsoft (I''ve even checked my
Enterprisey MSDN Account... it is simply not available). This severely
limits the number of people who can build Ruby on Windows, if the dependency
is kept. I''m pretty sure this is why Luis embarked on the mingw32 build
in
the first place.
If we MUST be dependent on an MS-provided C library, why not make it one of
the ones that they distribute freely (with an IDE): 2005 or 2008.

Question is, though, is this truly a dependency?

On Mon, Mar 16, 2009 at 7:40 AM, Roger Pack <rogerdpack at gmail.com>
wrote:
> On Sun, Mar 15, 2009 at 12:40 PM, Luis Lavena <luislavena at
gmail.com>
> wrote:
> > On Sun, Mar 15, 2009 at 12:56 AM, Roger Pack <rogerdpack at
gmail.com>
> wrote:
> >> Perhaps we should [regardless of whether naming changes are
approved
> >> or not] by default link against msvcr90 [from the mingw builds],
and
> >> also include the VC2008 runtimes.  That blesses the lives of the
> >> VC2008 people, since they don''t have to worry quite as
much about
> >> differing runtime library incompats.  And it probably
wouldn''t be too
> >> hard to link against it from mingw.  Is it possible using the
cross
> >> compiler tho?
> >> Thoughts?
> >> -=r
> >>
> >
> > AFAIK, none of the mingw32 packages for the different linux
> > distributions bundle msvcr90 libraries.
> >
> > Without those, after installing (macport or apt-get package) manually
> > find/build/install the msvcr90 libraries to properly link to the
> > specified runtime.
> >
> > After that, if the user wanted to execute using Wine (to run
> > specs/test and verify the build doesn''t segfault) they will
need to
> > follow the winetricks:
> >
> >
http://wiki.winehq.org/FAQ#head-a0aa6667e9ba22fad996f7f0d51dc7d161087611
> >
> > Another issue I see with this, I tell ruby configure about it, but
> > there is a MSVCRT chooser script that can fake/hide the trick for us.
> >
> > I''m starting to think that is we are letting MSVCR90 be the
default
> > runtime, why I should bother with MinGW at all.
> >
> > I should be building Ruby with VC2008 instead...
>
> That seems like quite a lot of work for the linux cross compiling
> crowd.  Of course, Charlie would probably say they don''t need to
link
> against msvcr90 they can just link against msvcrt6 and it should work
> :)
>
> My concern with it is would we have to be distributing tons of
> diferent msvcrt runtimes [like v 7.1 for the 2005 folks, etc.], if
> they link against those?  Is there any benefit with trying to not use
> msvcrt6 from VC6?  I hear rumors that it isn''t as thread safe? Is
it
> slower do we know?
>
> I suppose the reality is that most ruby programmers [and extension
> developers] at on Linux or OS X, so perhaps we should cater to them by
> making msvcrt.dll 6 the default?
> I prefer mingw because of the speed, but that''s just my personal
> opinion.  The cross compile stuff is nice, too.  I''m ok with
sticking
> with msvcrt6.
> Thoughts?
> -=r
> _______________________________________________
> Rubyinstaller-devel mailing list
> Rubyinstaller-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rubyinstaller-devel
>


-- 
--
Will Green
http://willgreen.mp/
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/rubyinstaller-devel/attachments/20090316/c5725189/attachment.html>

2009/3/16 William Green <will at hotgazpacho.org>:
> MSVC6 is no longer available from Microsoft (I''ve even checked my
> Enterprisey MSDN Account... it is simply not available). This severely
> limits the number of people who can build Ruby on Windows, if the
dependency
> is kept. I''m pretty sure this is why Luis embarked on the mingw32
build in
> the first place.
> If we MUST be?dependent?on an MS-provided C library, why not make it one of
> the ones that they distribute freely (with an IDE): 2005 or 2008.
> Question is, though, is this truly a dependency?
Yes, it is. These are not installed in Windows (nor Wine) by default
and you have to distribute them with Ruby for it to work. And they are
some special beast so just downloading the dll and dropping it into
the ruby directory is not enough if you forget to bundle it.

On the other hand, the VC6 runtime is in all Windows so it is not a dependency.

Thanks

Michal

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.
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.

Luis, am I totally off-base here, am I missing something?

On Mon, Mar 16, 2009 at 11:44 AM, Michal Suchanek <hramrach at
centrum.cz>wrote:
> 2009/3/16 William Green <will at hotgazpacho.org>:
> > MSVC6 is no longer available from Microsoft (I''ve even
checked my
> > Enterprisey MSDN Account... it is simply not available). This severely
> > limits the number of people who can build Ruby on Windows, if the
> dependency
> > is kept. I''m pretty sure this is why Luis embarked on the
mingw32 build
> in
> > the first place.
> > If we MUST be dependent on an MS-provided C library, why not make it
one
> of
> > the ones that they distribute freely (with an IDE): 2005 or 2008.
> > Question is, though, is this truly a dependency?
>
> Yes, it is. These are not installed in Windows (nor Wine) by default
> and you have to distribute them with Ruby for it to work. And they are
> some special beast so just downloading the dll and dropping it into
> the ruby directory is not enough if you forget to bundle it.
>
> On the other hand, the VC6 runtime is in all Windows so it is not a
> dependency.
>
> Thanks
>
> Michal
> _______________________________________________
> Rubyinstaller-devel mailing list
> Rubyinstaller-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rubyinstaller-devel
>


-- 
--
Will Green
http://willgreen.mp/
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/rubyinstaller-devel/attachments/20090316/c1148e9d/attachment.html>

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.
> 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.
> Luis, am I totally off-base here, am I missing something?
Yes, that''s the reason for building with MinGW32. However, the
compiler normally links with the VC6 runtime and there were
suggestions to link with later runtime instead. This would make the
process of building and distributing Ruby more troublesome in my view
which is what the migw build process was supposed to avoid.

Unlike the VC6 runtime which really is in all windows even the
possibility to download the runtime from Microsoft is not of much use
for the VC2008 runtime. You might be able to install the runtime
system-wide if you are the administrator but just downloading it does
not help you.

Thanks

Michal

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

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.

Thanks!
-=r

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
>

On Wed, Mar 18, 2009 at 10:54 AM, Roger Pack <rogerdpack at gmail.com>
wrote:
>
> 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?
>
msvcrt-ruby18.dll or msvcrt-ruby19.dll are not statically linked to
MSVCRT, they are dynamically.

Is not the linking what is the problem, but the proper memory
management and the convention used by the share ruby library.
> Also, was there any concensus on whether errno differences were fatal?
I didn''t remember about errno until Ruby-core guys pointed that again,
bad memory from me, once more.
> Sorry to bore Luis with this stuff :)
Sorry to take me so long to get back to you, overwhelmed by work for
the past weeks, trying to catch up with everything.
> And in the end I don''t care what happens.
He, well, this whole stuff is to complicated and tiring.
> I''d be happy to spearhead any devkit gem, as well.
devkit gem will a wrapper around the mssy/gcc rake tasks of
rubyinstaller compiler, with the only difference that they will set
the "sandbox" to a specific folder and put some batch wrapper in your
ruby/bin folder.
> Thanks!
> -=r
>
Cheers,
-- 
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

On Sat, Mar 21, 2009 at 10:15 AM, Luis Lavena <luislavena at gmail.com>
wrote:
> On Wed, Mar 18, 2009 at 10:54 AM, Roger Pack <rogerdpack at
gmail.com> wrote:
>>
>> 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?
>>
>
> msvcrt-ruby18.dll or msvcrt-ruby19.dll are not statically linked to
> MSVCRT, they are dynamically.
>
> Is not the linking what is the problem, but the proper memory
> management and the convention used by the share ruby library.
Ok so what I''m hearing is that say you install mingw ruby
then you install
gem install mysql --platform=mswin32
which we''ll pretend was built using VC2008
it will by "use" msvcrt 6 dll for it [hence it needs to be careful
with frees and such]?  There is no need for the system to have
msvcr9.dll on it at all?


>> I''d be happy to spearhead any devkit gem, as well.
>
> devkit gem will a wrapper around the mssy/gcc rake tasks of
> rubyinstaller compiler, with the only difference that they will set
> the "sandbox" to a specific folder and put some batch wrapper in
your
> ruby/bin folder.

how can I help?


re: errno
so does this mean that it basically *is* impossible to compile against
other msvcrt.dll''s?  I.e. only one can be "blessed" as a
time?
thanks!
-=r

So if my theory is correct [I don''t have all the information, but
here''s my guess]

1) if you are "careful" then you code, even though it was compiled
against a different version of msvcrt.dll, will run in *any* windows
ruby environment.

I assume being careful means that you avoid the use off errno [and
calling anything that uses errno].  Does anyone know which versions
actually differ in errno numbering?

If that''s the case then we should be able to release the mingw version
and then windows extension developers use VC 2008 and then package up
their stuff "and name it mingw" [similar to currently doing a gem
install --platform=mswin32].

Am I off base?
Thanks.
-=r


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.
> 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.
> Luis, am I totally off-base here, am I missing something?
>
> On Mon, Mar 16, 2009 at 11:44 AM, Michal Suchanek <hramrach at
centrum.cz>
> wrote:
>>
>> 2009/3/16 William Green <will at hotgazpacho.org>:
>> > MSVC6 is no longer available from Microsoft (I''ve even
checked my
>> > Enterprisey MSDN Account... it is simply not available). This
severely
>> > limits the number of people who can build Ruby on Windows, if the
>> > dependency
>> > is kept. I''m pretty sure this is why Luis embarked on the
mingw32 build
>> > in
>> > the first place.
>> > If we MUST be?dependent?on an MS-provided C library, why not make
it one
>> > of
>> > the ones that they distribute freely (with an IDE): 2005 or 2008.
>> > Question is, though, is this truly a dependency?
>>
>> Yes, it is. These are not installed in Windows (nor Wine) by default
>> and you have to distribute them with Ruby for it to work. And they are
>> some special beast so just downloading the dll and dropping it into
>> the ruby directory is not enough if you forget to bundle it.
>>
>> On the other hand, the VC6 runtime is in all Windows so it is not a
>> dependency.
>>
>> Thanks
>>
>> Michal
>> _______________________________________________
>> Rubyinstaller-devel mailing list
>> Rubyinstaller-devel at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/rubyinstaller-devel
>
>
> --
> --
> Will Green
> http://willgreen.mp/
>
> _______________________________________________
> Rubyinstaller-devel mailing list
> Rubyinstaller-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rubyinstaller-devel
>

Another thought would be to allow developers to develop in VS 2008.
Just instruct them that "when you want to distribute your code, you
may want to compile it using the mingw stack for highest
compatibility" or what not.

Also a recent note from Visual C++ express edition was "On March 31st
the Microsoft Visual Studio 2005 Express Edition products will be
discontinued and removed from www.microsoft.com/express" so I guess
Microsoft really does discontinue things :)

-=r

On Sat, Mar 28, 2009 at 3:47 PM, Roger Pack <rogerdpack at gmail.com>
wrote:
> So if my theory is correct [I don''t have all the information, but
> here''s my guess]
>
> 1) if you are "careful" then you code, even though it was
compiled
> against a different version of msvcrt.dll, will run in *any* windows
> ruby environment.
>
> I assume being careful means that you avoid the use off errno [and
> calling anything that uses errno]. ?Does anyone know which versions
> actually differ in errno numbering?
>
> If that''s the case then we should be able to release the mingw
version
> and then windows extension developers use VC 2008 and then package up
> their stuff "and name it mingw" [similar to currently doing a gem
> install --platform=mswin32].
>
> Am I off base?
> Thanks.
> -=r
>
>
> 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.
>> 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.
>> Luis, am I totally off-base here, am I missing something?
>>
>> On Mon, Mar 16, 2009 at 11:44 AM, Michal Suchanek <hramrach at
centrum.cz>
>> wrote:
>>>
>>> 2009/3/16 William Green <will at hotgazpacho.org>:
>>> > MSVC6 is no longer available from Microsoft (I''ve
even checked my
>>> > Enterprisey MSDN Account... it is simply not available). This
severely
>>> > limits the number of people who can build Ruby on Windows, if
the
>>> > dependency
>>> > is kept. I''m pretty sure this is why Luis embarked on
the mingw32 build
>>> > in
>>> > the first place.
>>> > If we MUST be?dependent?on an MS-provided C library, why not
make it one
>>> > of
>>> > the ones that they distribute freely (with an IDE): 2005 or
2008.
>>> > Question is, though, is this truly a dependency?
>>>
>>> Yes, it is. These are not installed in Windows (nor Wine) by
default
>>> and you have to distribute them with Ruby for it to work. And they
are
>>> some special beast so just downloading the dll and dropping it into
>>> the ruby directory is not enough if you forget to bundle it.
>>>
>>> On the other hand, the VC6 runtime is in all Windows so it is not a
>>> dependency.
>>>
>>> Thanks
>>>
>>> Michal
>>> _______________________________________________
>>> Rubyinstaller-devel mailing list
>>> Rubyinstaller-devel at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/rubyinstaller-devel
>>
>>
>> --
>> --
>> Will Green
>> http://willgreen.mp/
>>
>> _______________________________________________
>> Rubyinstaller-devel mailing list
>> Rubyinstaller-devel at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/rubyinstaller-devel
>>
>