Will 1.8.6 remain compiled with VC6?
Luis Lavena
Since last year (in July if memory works) there was a discussion about
One-Click-Installer and rely on VC6 builds (the official ones
available at http://www.garbagecollect.jp/ruby/mswin32/en/), use VC8
or switch to MinGW.
I remember the discussion was heated, but no final word on the
platform that OCI will use for future releases. So far, still remains
linked to VC6 ones.
The problem is the whole "how extensions are build, compiled and
packaged with different compilers"...
So far, to link successfully (without tweaks to rbconfig.rb) you still
need VC6, which is currently unavailable.
Now VC8 is released as free package (under Visual Studio Express 2005
or Windows Vista SDK) -- in any case, is more simpler get the
environment right to compile Ruby and the extensions (under the
mswin32_80 platform).
A few days back testing the upcoming RubyGems, found that mswin32 and
mswin32_80 was considered the same platform, and that could raise a
few issues as I pointed in the list:
http://rubyforge.org/pipermail/rubygems-developers/2007-September/003058.html
- Extensions compiled under VC6 build of ruby will link against
msvcrt-ruby18.dll
- Hand-compiled Ruby (with VC8) will link extensions to msvcr80-ruby18.dll
- Installation of extensions pre-built with VC6 under Ruby-VC8 will
not find the ruby library and fail.
- Compile extensions with VC8 for Ruby-VC6 requires tweaks in
rbconfig.rb (a lot of them).
- Side effect: Extensions compiled with VC8 will also load
MSVCR80.DLL, besides the MSVCRT.DLL loaded by the interpreter.
- Ruby-VC6 is slower than VC8 (http://pastie.caboo.se/pastes/95210)
Sine new ruby users and developer would like to create their own
extensions and due the lack of distutils-like functionality for
Ruby...
What is required to finally migrate Ruby builds on Windows to VC8?
I have done some work fulfilling the dependencies of extensions
bundled with ruby:
http://pastie.caboo.se/pastes/100080
To get them work under VC8 (all the dependencies are build from
scratch to link with MSVCR80.DLL).
I don't want to start another flame war, huge debate about this, since
Eric Hodel will provide a workaround for rubygems (Ruby-VC6 will be
x86-mswin32-60 and VC8 build will be x86-mswin32-80).
Thanks in advance for your time (everybody who reach this point and
didn't delete the message) :-)
Regards and good weekend,
--
Luis Lavena
Multimedia systems
-
Leaders are made, they are not born. They are made by hard effort,
which is the price which all of us must pay to achieve any goal that
is worthwhile.
Vince Lombardi
Austin Ziegler
> I remember the discussion was heated, but no final word on the
> platform that OCI will use for future releases. So far, still remains
> linked to VC6 ones.
This isn't really a core Ruby question. This should be asked on
ruby-talk or (if there is one) the One Click Installer mailing list.
> What is required to finally migrate Ruby builds on Windows to VC8?
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.
It is not in the One-Click Installer's mandate to recompile OpenSSL
using VC8 instead of VC6. Or zlib. Or pdcurses. Or ...
VC8 is the best compiler available right now and the only choice for
64-bit Windows. Maybe we can talk to Intel about using the ICC if
they'll be compatible. But Microsoft never responded positively with
any way to work around this given that we don't control the library
chain end-to-end.
It's not a problem for most of Microsoft's customers like my
workplace, where we compile EVERYTHING we need from scratch (except,
of course, Windows) or can demand up-to-date libraries from our tool
vendors (or pay for them...). It is a problem for any open source
project, not just Ruby.
-austin
--
Austin Ziegler * halos...@gmail.com * http://www.halostatue.ca/
* aus...@halostatue.ca * http://www.halostatue.ca/feed/
* aus...@zieglers.ca
Luis Lavena
> On 9/30/07, Luis Lavena <luisl...@gmail.com> wrote:
> > I remember the discussion was heated, but no final word on the
> > platform that OCI will use for future releases. So far, still remains
> > linked to VC6 ones.
>
> This isn't really a core Ruby question. This should be asked on
> ruby-talk or (if there is one) the One Click Installer mailing list.
>
Austin, One-Click-Installer rely on official builds made by Ruby-Core
developers (Nobu is in charge if memory works as expected).
Is not a Ruby-Talk subject, but Ruby-Core one.
> > What is required to finally migrate Ruby builds on Windows to VC8?
>
> 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.
>
I'm aware of that problem, as I listed before just to summarize them.
I'm not blaming anyone, Microsoft, users, whatever.
We should look for a solution instead of starting to point fingers.
> It is not in the One-Click Installer's mandate to recompile OpenSSL
> using VC8 instead of VC6. Or zlib. Or pdcurses. Or ...
>
As I said, is not a OCI question, is for the official builds (on which
OCI relies).
> VC8 is the best compiler available right now and the only choice for
> 64-bit Windows. Maybe we can talk to Intel about using the ICC if
> they'll be compatible. But Microsoft never responded positively with
> any way to work around this given that we don't control the library
> chain end-to-end.
>
Maybe I'm wrong here, but 64-bit computing is useful for large
memory-address (pointers) and not related to the core instructions set
used to get a program working.
There is x64-mingw also, even if not official yet.
On a personal note I'm taking mingw as platform (x64-mingw is there,
just not merged).
> It's not a problem for most of Microsoft's customers like my
> workplace, where we compile EVERYTHING we need from scratch (except,
> of course, Windows) or can demand up-to-date libraries from our tool
> vendors (or pay for them...). It is a problem for any open source
> project, not just Ruby.
>
I was talking about "average Joe", who just started with Ruby and want
to dig into the extension building / using land.
Don't expect all the users that use a language compile everything from
scratch. At some point you didn't...
We should extend the "simple but not simpler" philosophy found across
all Ruby and Ruby libraries to the environment.
Getting it right reduce overhead of support, which turns in less noise
and more happy developers/community.
BTW, wasn't you who migrated to OSX? :-P
M. Edward (Ed) Borasky
Yes, let's take this to Ruby-Talk so we can all participate. Most of the
open source projects I deal with on Windows have gone to || stayed with
MinGW/MSYS and its friends. Ruby seems to be the exception. I remember
the past discussions and my own point of view was that it didn't really
matter to me as long as the gems && other C/C++ libraries were available
in binary form and in source form if their licenses required it. I don't
*need* to build from source on Windows, although I wouldn't refuse the
opportunity to do so.
I am in the process of phasing out Cygwin usage at my day job. I brought
it in as a crutch and it has become a maintenance nightmare. The worst
part of it is that it hoses up file and directory permissions at the NT
level if you aren't careful (and I haven't been). :)
So while I know that VC8 is a "better" compiler than MinGW/MSYS, what
other open source projects, if any, use VC8? How many others use VC6?
What are the licensing gotchas on the Intel compiler? In general, are
open source projects on Windows doomed to be second-class citizens? :(
M. Edward (Ed) Borasky
Yes, let's take this to Ruby-Talk so we can all participate. Most of the
Austin Ziegler
> On 9/30/07, Austin Ziegler <halos...@gmail.com> wrote:
>> On 9/30/07, Luis Lavena <luisl...@gmail.com> wrote:
>>> I remember the discussion was heated, but no final word on the
>>> platform that OCI will use for future releases. So far, still
>>> remains linked to VC6 ones.
>> This isn't really a core Ruby question. This should be asked on
>> ruby-talk or (if there is one) the One Click Installer mailing list.
> Austin, One-Click-Installer rely on official builds made by Ruby-Core
> developers (Nobu is in charge if memory works as expected).
>
> Is not a Ruby-Talk subject, but Ruby-Core one.
I don't actually agree here. Curt goes with the VC 6 build because it's
easier than trying to work with the overall environment himself and
previous incompatibilities.
>>> What is required to finally migrate Ruby builds on Windows to VC8?
>> 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.
> I'm aware of that problem, as I listed before just to summarize them.
> I'm not blaming anyone, Microsoft, users, whatever.
>
> We should look for a solution instead of starting to point fingers.
I've looked for a solution from the people who could give a useful one,
and gotten bupkis.
>> It is not in the One-Click Installer's mandate to recompile OpenSSL
>> using VC8 instead of VC6. Or zlib. Or pdcurses. Or ...
> As I said, is not a OCI question, is for the official builds (on which
> OCI relies).
What I just said about OpenSSL or zlib or pdcurses applies trebly for
Nobu or NaHi (or whomever it is that provides the base builds).
VC8-built Ruby will NOT safely run with any DLL that is built on VC6 or
MinGW. You must have all DLLs in your chain built with the same runtime
for safest execution.
>> VC8 is the best compiler available right now and the only choice for
>> 64-bit Windows. Maybe we can talk to Intel about using the ICC if
>> they'll be compatible. But Microsoft never responded positively with
>> any way to work around this given that we don't control the library
>> chain end-to-end.
> Maybe I'm wrong here, but 64-bit computing is useful for large
> memory-address (pointers) and not related to the core instructions set
> used to get a program working.
Performance. 32-bit code runs a bit slower on x86-64 and Win64 than on
Win32.
>> It's not a problem for most of Microsoft's customers like my
>> workplace, where we compile EVERYTHING we need from scratch (except,
>> of course, Windows) or can demand up-to-date libraries from our tool
>> vendors (or pay for them...). It is a problem for any open source
>> project, not just Ruby.
> I was talking about "average Joe", who just started with Ruby and want
> to dig into the extension building / using land.
> Don't expect all the users that use a language compile everything from
> scratch. At some point you didn't...
> We should extend the "simple but not simpler" philosophy found across
> all Ruby and Ruby libraries to the environment.
> Getting it right reduce overhead of support, which turns in less noise
> and more happy developers/community.
Right. But the amount of overhead to support to get VC8 working is
insane. I tried it, remember?
> BTW, wasn't you who migrated to OSX? :-P
Yeah. I've never been happier than when I no longer had to deal with
Windows at home. I still work with it at work every day, though.
Luis Lavena
> Yes, let's take this to Ruby-Talk so we can all participate. Most of the
> open source projects I deal with on Windows have gone to || stayed with
> MinGW/MSYS and its friends. Ruby seems to be the exception. I remember
> the past discussions and my own point of view was that it didn't really
> matter to me as long as the gems && other C/C++ libraries were available
> in binary form and in source form if their licenses required it. I don't
> *need* to build from source on Windows, although I wouldn't refuse the
> opportunity to do so.
>
Maybe you're right, cross-posting this could get more answers from
actual ruby-mswin32 users.
The concern about gems and other C/C++ libraries in "binary form" is
why I started this.
Trying to get VC8 to compile extensions that where only available to
*nix platforms (Take for example Mongrel).
Ruby-VC6 make this a nightmare. Even VC71.
Lucky me I recovered a lost Visual Studio 97 we had on office and
installed VC6. Now mswin32 users of Mongrel have a binary gem to use
and enjoy.
> So while I know that VC8 is a "better" compiler than MinGW/MSYS, what
> other open source projects, if any, use VC8? How many others use VC6?
I wonder why you quoted 'better' when talking about VC8 :-)
MinGW/MSYS reduces the overwork getting something build/updated on
Windows, take as example Ruby.
I worked almost 3 days in a row to get all the Ruby dependencies (as I
listed that before) compile and properly run with VC8.
That was a huge amount of time "invested" in. On the other side, get
almost every extension bundled with ruby build under MinGW took me
less than a day (Using MinGWports and GnuWin32 source packages).
VC6 is no longer in use for Python or Subversion, both of the bigger
OSS I have seen.
Sometimes a lot of projects (like wxWindows) compiles better with
MinGW, since there is no maintainer for the nmake-compatible makefiles
or the msbuild solution files.
> What are the licensing gotchas on the Intel compiler? In general, are
> open source projects on Windows doomed to be second-class citizens? :(
ICC requires us having a Intel license, from compiling Ruby to
creating extensions.
As I said before, the thing about VC6/VC8 is not about is the right
compiler or faster compiler, but I was considering the problems most
developers face when creating/maintaining extensions for Ruby.
Luis Lavena
>
> I don't actually agree here. Curt goes with the VC 6 build because it's
> easier than trying to work with the overall environment himself and
> previous incompatibilities.
>
That was my point.
Nobu already have the environment in place. I was trying to recreate
it and took me some time get everything build / fixed for VC8.
Use the official build reduce the pain, and making the official build
goes for the VC8 is something outside the power of Curt, and remains
close to the Ruby-Core developers
> I've looked for a solution from the people who could give a useful one,
> and gotten bupkis.
>
If you're talking about MS... they found a workaround: recreate ruby
in the shape of IronRuby.
> What I just said about OpenSSL or zlib or pdcurses applies trebly for
> Nobu or NaHi (or whomever it is that provides the base builds).
> VC8-built Ruby will NOT safely run with any DLL that is built on VC6 or
> MinGW. You must have all DLLs in your chain built with the same runtime
> for safest execution.
>
That was my point... often think my english isn't good and people get
lost on my answer... you prove it.
> Performance. 32-bit code runs a bit slower on x86-64 and Win64 than on
> Win32.
Sometimes maintainability is the best solution versus Performance.
As I said, just for the record, there is some work on x64-pc-mingw64
version of MinGW...
> Right. But the amount of overhead to support to get VC8 working is
> insane. I tried it, remember?
>
Insane? Could be, getting every dependency build right under VC8 took
me a lot of time, but is doable.
Getting it build right under MinGW was easier.
> > BTW, wasn't you who migrated to OSX? :-P
>
> Yeah. I've never been happier than when I no longer had to deal with
> Windows at home. I still work with it at work every day, though.
>
Refresh my memory: wasn't the Ruby bundled with OSX broken? Most of
the post I see on the web states manually compile Ruby and the
extensions for OSX... to get a dev. environment right.
Anyway, the thing is: what will be best for other ruby
developers/users? Creating extensions for Ruby are simple if both Ruby
and the extensions could be built with a compiler available today.
Charlie Savage
> open source projects I deal with on Windows have gone to || stayed with
> MinGW/MSYS and its friends. Ruby seems to be the exception.
Postgresql 8.3 is moving to VC2005. Python also uses VC++ (2003 IIRC).
I use mingw/msys, but its not easy to setup, the tools are unfamiliar to
Windows users, and debugging is well nigh impossible.
Charlie
Luis Lavena
I was working on documenting the whole MinGW/MSYS experience, so far,
not as dificult as get everything compiels with VC8... but still
requires some time to get used.
Debugging is a real problem, but I'm used to commandline debug (gdb)
and Insight is a good front-end for it.
Charlie Savage
> and Insight is a good front-end for it.
Except gdb doesn't work for dlls - making it impossible to debug
extensions which is what I usually need to use it for.
For anyone who uses MingW/msys and want an IDE, then I'd recommend
Eclipse + CDT (Eclipse's c/c++ support).
Charlie
Charlie Savage
> 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
Nobuyoshi Nakada
At Mon, 1 Oct 2007 12:05:55 +0900,
Charlie Savage wrote in [ruby-core:12317]:
> Except gdb doesn't work for dlls - making it impossible to debug
> extensions which is what I usually need to use it for.
Of course it does work. If you were correct, how could I debug
ruby.exe and msvcrt-ruby.dll?
--
Nobu Nakada
Charlie Savage
>> extensions which is what I usually need to use it for.
>
> Of course it does work. If you were correct, how could I debug
> ruby.exe and msvcrt-ruby.dll?
>
Really? You're the first person I've heard of having success with this
on Windows.
Just to be clear:
1. You can take an extension, say ruby-prof.
2. Compile with debug information
3. Tell gdb the host executable is ruby.exe (stock version)
4. Tell gdb to set a breakpoint in ruby-prof (the dll)
5. Run some ruby program that triggers the breakpoint
5. And it works?
I've never had any luck with it...
Charlie
Jack Christensen
downloaded beta 2 and they have made a number of improvements for native
apps. In particular, you no longer have to download the platform sdk and
edit config files to compile to native code. It works out of the box. I
don't know what problems there may be recompiling the different
extensions, but ruby and zlib compiled perfectly without jumping through
any hoops.
Jack
Nobuyoshi Nakada
At Mon, 1 Oct 2007 12:42:04 +0900,
Charlie Savage wrote in [ruby-core:12320]:
> Really? You're the first person I've heard of having success with this
> on Windows.
>
> Just to be clear:
>
> 1. You can take an extension, say ruby-prof.
Though I haven't debugged ruby-prof, I've used many other
bundled extensions, stringio, iconv, socket, and so on.
> 2. Compile with debug information
> 3. Tell gdb the host executable is ruby.exe (stock version)
> 4. Tell gdb to set a breakpoint in ruby-prof (the dll)
gdb asks the breakpoint isn't found and if it will be loaded
later.
> 5. Run some ruby program that triggers the breakpoint
> 5. And it works?
Yes. No problem at all.
--
Nobu Nakada
Curt (Work) Hibbs
because readers of this thread are most likely to be interested...
I'm looking for someone to take over the One-Click Ruby Installer
project. I haven't done any Ruby programming for more than 1.5 years,
and I don't that changing for at least another year. This means that I
don't have the time or up-to-date skills to be effective.
For example, I am working on an updated release for 1.8.6p110 but its
taking far too long because I don't have much time to spend on it and
when I run into problems, I no longer have the ready skills to solve
it quickly enough.
I can help out whoever takes over for the foreseeable future, I just
shouldn't be the one in charge anymore. If anyone is interested,
please let me know.
Curt
On 9/30/07, Luis Lavena <luisl...@gmail.com> wrote:
Arlen Christian Mart Cuss
On Wed, 2007-10-03 at 01:05 +0900, Curt (Work) Hibbs wrote:
> I'm looking for someone to take over the One-Click Ruby Installer
> project. I haven't done any Ruby programming for more than 1.5 years,
> and I don't that changing for at least another year. This means that I
> don't have the time or up-to-date skills to be effective.
I sent you some mail off-list regarding this. I realise you'll probably
receive it, but I'm eager, so I'm ensuring it'll make it past your junk
filters by alerting you here.
Cheers,
Arlen
Luis Lavena
> I know this not the right place to post this, but I'll start here
> because readers of this thread are most likely to be interested...
>
> I'm looking for someone to take over the One-Click Ruby Installer
> project. I haven't done any Ruby programming for more than 1.5 years,
> and I don't that changing for at least another year. This means that I
> don't have the time or up-to-date skills to be effective.
>
> For example, I am working on an updated release for 1.8.6p110 but its
> taking far too long because I don't have much time to spend on it and
> when I run into problems, I no longer have the ready skills to solve
> it quickly enough.
>
> I can help out whoever takes over for the foreseeable future, I just
> shouldn't be the one in charge anymore. If anyone is interested,
> please let me know.
>
> Curt
>
Hi Curt.
I mailed you a few months back regarding OCI... guess it get trapped
by some spam filters.
Anyway, I'm looking forward work on this, and maybe improve the
usability factor for the windows users (as some developer stated:
second class citizens).
I'll re-send you a mail off the list for this subject.
Regards and hope job is worth it to be so far from Ruby :-)
Curt (Work) Hibbs
> On 10/2/07, Curt (Work) Hibbs <ml.c...@gmail.com> wrote:
> > I know this not the right place to post this, but I'll start here
> > because readers of this thread are most likely to be interested...
> >
> > I'm looking for someone to take over the One-Click Ruby Installer
> > project. I haven't done any Ruby programming for more than 1.5 years,
> > and I don't that changing for at least another year. This means that I
> > don't have the time or up-to-date skills to be effective.
> >
> > For example, I am working on an updated release for 1.8.6p110 but its
> > taking far too long because I don't have much time to spend on it and
> > when I run into problems, I no longer have the ready skills to solve
> > it quickly enough.
> >
> > I can help out whoever takes over for the foreseeable future, I just
> > shouldn't be the one in charge anymore. If anyone is interested,
> > please let me know.
> >
> > Curt
> >
>
> Hi Curt.
>
> I mailed you a few months back regarding OCI... guess it get trapped
> by some spam filters.
Maybe. :-(
> Anyway, I'm looking forward work on this, and maybe improve the
> usability factor for the windows users (as some developer stated:
> second class citizens).
>
> I'll re-send you a mail off the list for this subject.
Please do -- email me here: curt at hibbs dot com
> Regards and hope job is worth it to be so far from Ruby :-)
Its a mixed bag, I'll tell you more offline.
Curt
Michal Suchanek
>
> 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.
>
What's the problem here? The whole point here is that you do want to
distribute dlls. Just pack in one or two more. And if the oci is built
using the new compiler it would have the dlls already so there is no
problem at all.
Thanks
Michal
Austin Ziegler
The CRT 8 files (VS2005) are SxS assemblies, intended to be installed
on the system. It takes some extra workarounds to put them only in the
source directory.
(Just to be clear: this affects Windows because it's the only common
system that includes more than one C runtime. Linux can and often
does, but linking is much tighter against the C runtimes and is only
used when you have a program that requires that older C runtime, but
most other Unixes handle this much better than even Linux.)
Luis Lavena
> distribute dlls. Just pack in one or two more. And if the oci is built
> using the new compiler it would have the dlls already so there is no
> problem at all.
>
I see there is no problem using the C/C++ Runtime 2005 redistributable
merge for this case, after all, OCI stand for "One-Click-Installer"...
The dependencies and updates should be handled automatically for you.
Michal Suchanek
> On 10/3/07, Michal Suchanek <hram...@centrum.cz> wrote:
> > On 01/10/2007, Charlie Savage <cf...@savagexi.com> wrote:
> > > 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.
> > What's the problem here? The whole point here is that you do want to
> > distribute dlls. Just pack in one or two more. And if the oci is built
> > using the new compiler it would have the dlls already so there is no
> > problem at all.
>
> The CRT 8 files (VS2005) are SxS assemblies, intended to be installed
> on the system. It takes some extra workarounds to put them only in the
> source directory.
>
If the above is supposed to mean that vc8 runtime libraries cannot be
just downloaded and dropped to the same directory as the executable
that uses them then I would avoid them like plague.
For vc7 runtime it works. But then who knows what new entertainments
has Microsoft prepared for the users of their newer software.
Thanks
Michal
Luis Lavena
We could go with the MinGW path, which is compatible with msvcrt (and
as result, uses the buggy, not safe msvcrt used by vc6).
The whole assemblies enchilada is part of the holy solution to the dll
hell... which still sucks.
But, VC8 and VC9 (beta) are 64bits ready, meanwhile MinGW need a lot
more of work to get integrated, alpha, candiate and stable 64bits
support... 2 years maybe? :-P
Charlie Savage
>> The CRT 8 files (VS2005) are SxS assemblies, intended to be installed
>> on the system. It takes some extra workarounds to put them only in the
>> source directory.
Yup.
> If the above is supposed to mean that vc8 runtime libraries cannot be
> just downloaded and dropped to the same directory as the executable
> that uses them then I would avoid them like plague.
>
> For vc7 runtime it works. But then who knows what new entertainments
> has Microsoft prepared for the users of their newer software.
Hmm...this sometimes doesn't work for me :( Thus my worries about it.
Charlie
Curt (Work) Hibbs
The problem is that you can't safely mix a Ruby built with
VC2003/VC2005 with other binaries (gems, OpenSSL, ImageMagick, etc.)
that were built with older compilers.
Curt
Charlie Savage
> The problem is that you can't safely mix a Ruby built with
> VC2003/VC2005 with other binaries (gems, OpenSSL, ImageMagick, etc.)
> that were built with older compilers.
By binaries I assume you mean dlls.
If you are careful about memory management, file handles, etc it should
work, no? I take it you have run into problems though?
Charlie
Austin Ziegler
> On 03/10/2007, Austin Ziegler <halos...@gmail.com> wrote:
> > On 10/3/07, Michal Suchanek <hram...@centrum.cz> wrote:
> > > On 01/10/2007, Charlie Savage <cf...@savagexi.com> wrote:
> > > > 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.
> > > What's the problem here? The whole point here is that you do want to
> > > distribute dlls. Just pack in one or two more. And if the oci is built
> > > using the new compiler it would have the dlls already so there is no
> > > problem at all.
> > The CRT 8 files (VS2005) are SxS assemblies, intended to be installed
> > on the system. It takes some extra workarounds to put them only in the
> > source directory.
> If the above is supposed to mean that vc8 runtime libraries cannot be
> just downloaded and dropped to the same directory as the executable
> that uses them then I would avoid them like plague.
The above means that it's difficult enough that some OSS applications
that have switched to VS2005 have not done the drop-in version, but
rather the SxS version. Which requires administrative permissions to
install.
> For vc7 runtime it works. But then who knows what new entertainments
> has Microsoft prepared for the users of their newer software.
Not much fun, to be honest.
Austin Ziegler
I haven't, personally. But for it to WORK, you have to 100% all the time
ensure that memory and other handles (files, etc.) are deallocated in
the same place that they're allocated.
An example of the problem for clarity. Let's say I've got a library I
want to interface with Ruby, called Fonz (it goes "ayyyy" better than a
native Ruby implementation...). Fonz has an API like this:
/* Allocates a Fonzarelli on the heap and returns a pointer to it.
* Remember to free() it when you're done.
*/
Fonzarelli* load_fonz();
So, I make a wrapper, RFonz (rfonz.so, which depends on fonz.dll) and
during the initialization phase, I call load_fonz(). And I set
everything up to call free() on my Fonzarelli pointer.
Under Solaris, AIX, and most other Unixes this won't ever be a problem.
There's only one C runtime installed. Under Linux, it COULD be a problem
if I try to link an older libfonz.so that was built under an earlier
version of the C runtime than the default for my distribution. In
practice, though, the older C runtimes are there for statically linked
programs that just have to be run on a system for compatibility
purposes.
On Windows, though, we have a problem. It is common to have multiple C
runtimes installed (at a minimum MSVCRT, which is VC6, and more likely
than not MSCRT7 and MSCRT71 as well, with MSCRT8 and MSCRT9 as high
likelihoods in the present to near future). For commercial developers,
it's common to build everything you need yourself (we build OpenSSL for
32 and 64 bit ourselves to include with our software package).
You're probably not going to run into THAT many problems where this
hurts. But in Ruby, we might see:
fonz.dll (equivalent of libfonz.so) - VC6 (MSVCRT)
ruby.exe, ruby18.dll - VC8 (MSCRT8)
rfonz.so - VC8 (MSCRT8)
Everything's fine and dandy until you call free() in rfonz.so on
Windows. MSCRT8 doesn't know anything about your Fonz object on the
heap. It doesn't have a handle for it. MSVCRT has your Fonz object
handle. Boom goes your program.
This could be fixed if the Fonz library also had:
/* Free your inner Fonz. */
free_fonz(Fonzarelli* fonz);
If you have that, it's, well, Happy Days.
Otherwise, you've jumped the shark.
Charlie Savage
> ensure that memory and other handles (files, etc.) are deallocated in
> the same place that they're allocated.
Which is good practice anyway.
>
> An example of the problem for clarity...
> This could be fixed if the Fonz library also had:
>
> /* Free your inner Fonz. */
> free_fonz(Fonzarelli* fonz);
>
> If you have that, it's, well, Happy Days.
Yup.
So is this a real problem? Is there an example in all the Ruby code
base and the various libraries where a dll provides an api to allocate
memory or handles but does not provide one to free them?
And even if there is, when creating the one click installer for Windows,
is everything compiled including dependencies like OpenSSH, ZLib, etc?
If yes, then there is no problem since they all share the same runtime
library.
Of course extension writers must follow the rules - if you use ALLOC use
xfree. If you provide an API to create Ruby objects in the dll you
must provide an api to free them. But you have to do that anyway to fit
in with the garbage collector.
My guess is with a bit of care, this issue can be worked around and
mixing match VC++ versions is workable.
Anyway, VC6 is such a lousy compiler compared to VS2005 I can't see why
anyone would want to use it except for a) this runtime library issue and
b) not having to deal with manifests and system assemblies.
Charlie
Austin Ziegler
> > I haven't, personally. But for it to WORK, you have to 100% all the time
> > ensure that memory and other handles (files, etc.) are deallocated in
> > the same place that they're allocated.
> Which is good practice anyway.
Absolutely. I have seen libraries that do what I talked about with libFonz...
> > An example of the problem for clarity...
> > This could be fixed if the Fonz library also had:
> >
> > /* Free your inner Fonz. */
> > free_fonz(Fonzarelli* fonz);
> >
> > If you have that, it's, well, Happy Days.
>
> Yup.
>
> So is this a real problem? Is there an example in all the Ruby code
> base and the various libraries where a dll provides an api to allocate
> memory or handles but does not provide one to free them?
...but I can't say if I've seen it in stuff that's commonly provided
by Ruby. That's not to say that it doesn't exist (there are tales of
incompatibilities and difficulties from the days of 1.8.2 which was
built with VS2003.NET [7.1]). Like I said, the problem essentially
doesn't exist in most Unixes, because you can only ever have one C
runtime installed. It's possible in Linux, but it's very uncommon and
would take some effort to even make a program that worked that way.
On Windows, it's very easy to call libraries that are linked to their
own C runtime.
> And even if there is, when creating the one click installer for Windows,
> is everything compiled including dependencies like OpenSSH, ZLib, etc?
> If yes, then there is no problem since they all share the same runtime
> library.
The answer is no. The standard zlib is explicitly only built with
MSVCRT (VC6) because it's the last version that can guarantee being
installed on every copy of Windows, ever. OpenSSL is similar. Back at
the end of '05, I went through a whole bunch of the effort to try to
use Visual Studio 2005 Express to build Ruby with all of its
extensions. The idea was to provide a different set of building
instructions for a Ruby OCI on Windows.
I gave up some time after I had to edit pdcurses to compile in Visual
Studio 2005 and realized that my new libraries weren't being seen by
Ruby for compiling the extensions anyway.
> Of course extension writers must follow the rules - if you use ALLOC use
> xfree. If you provide an API to create Ruby objects in the dll you
> must provide an api to free them. But you have to do that anyway to fit
> in with the garbage collector.
But it's not the extension writer that matters here -- it's the base
code that the extension is based on. If ZLib allocates ANY handle in
its MSVCRT space but doesn't provide a corresponding de-allocation
method, you're toast, because the extension writer can't work around
that unless they're using the exact same compiler.
> My guess is with a bit of care, this issue can be worked around and
> mixing match VC++ versions is workable.
To a degree, the answer is yes. But it's a lot of care that you don't
have to give for any other platform. There may be an alternate answer
(aside from the one that MS *should* be giving, which is essentially
shimming over older C runtimes to force them to use the new runtime
that has a compatibility mode; you know, like the quality Unix
vendors). If someone were to provide a series of libraries
vc6clean.dll, vc7clean.dll, vc71clean.dll, etc. that implements unique
calls like vc6_free(void*) or vc6_close(FILE*) that could be used when
you know that linkage, great. But if the linkage ever changes, you're
back to a problem. (It might be possible to detect some of that at
runtime, but you'd have to probably work with explicit DLL handles.)
> Anyway, VC6 is such a lousy compiler compared to VS2005 I can't see why
> anyone would want to use it except for a) this runtime library issue and
> b) not having to deal with manifests and system assemblies.
B is much less of a problem (at least the manifests) than A. The
system assemblies are a different problem, but again just needs to be
solved once. The runtime library issue is a stumper.
Charlie Savage
> MSVCRT (VC6) because it's the last version that can guarantee being
> installed on every copy of Windows, ever.
You mean msvcrt.lib is the only runtime library that is guaranteed on
each windows platform.
But is one click installer recompiling these libraries, or using their
pre-built binaries?
> I gave up some time after I had to edit pdcurses to compile in Visual
> Studio 2005 and realized that my new libraries weren't being seen by
> Ruby for compiling the extensions anyway.
What do you mean?
> But it's not the extension writer that matters here -- it's the base
> code that the extension is based on. If ZLib allocates ANY handle in
> its MSVCRT space but doesn't provide a corresponding de-allocation
> method, you're toast, because the extension writer can't work around
> that unless they're using the exact same compiler.
True.
> To a degree, the answer is yes. But it's a lot of care that you don't
> have to give for any other platform. There may be an alternate answer
> (aside from the one that MS *should* be giving, which is essentially
> shimming over older C runtimes to force them to use the new runtime
> that has a compatibility mode; you know, like the quality Unix
> vendors). If someone were to provide a series of libraries
> vc6clean.dll, vc7clean.dll, vc71clean.dll, etc. that implements unique
> calls like vc6_free(void*) or vc6_close(FILE*) that could be used when
> you know that linkage, great. But if the linkage ever changes, you're
> back to a problem. (It might be possible to detect some of that at
> runtime, but you'd have to probably work with explicit DLL handles.)
Yes - this system sucks. But its what Microsoft has done, I'm sure
partly to avoid DLL hell. Not sure the solution is better than the
problem though.
Anyway, Python uses VC2003 so it is doable....
Charlie
Austin Ziegler
>> MSVCRT (VC6) because it's the last version that can guarantee being
>> installed on every copy of Windows, ever.
> You mean msvcrt.lib is the only runtime library that is guaranteed on
> each windows platform.
MSVCRT is the last version of the runtime library that was distributed
with the operating system by default, and is on every version from
Windows 98 on. Everything else is ... uncertain.
That's why, in part, mingw relies on MSVCRT rather than anything later.
(There were some basic performance tests that showed that mingw Ruby is
about 10% faster than VC6 Ruby, but VC8 Ruby is about 25% or more faster
than VC6 Ruby.)
You can see a little more about that with the zlib distributable.
> But is one click installer recompiling these libraries, or using their
> pre-built binaries?
Using pre-built binaries in all cases. Sometimes, such as with the
Oracle libraries, it's the only choice. (But the Oracle libraries are
also a no-brainer to use because they do the right things.)
>> I gave up some time after I had to edit pdcurses to compile in Visual
>> Studio 2005 and realized that my new libraries weren't being seen by
>> Ruby for compiling the extensions anyway.
> What do you mean?
I mean that in late '05 and early '06, I was going through and setting
up a comprehensive build environment that would build all of the
dependent libraries (that we could) as well as the Ruby extensions and
Ruby, using Visual Studio 2005 Express. This was mostly done through
patches to code, unless the upstream provider could be found and
encouraged to accept a patch to fix the problems. I did this for about
four libraries and then got pissed off (not just at these libraries, but
at how Ruby is built on Windows -- and I'm not blaming the Ruby
developers, to be honest) and gave up.
That's part of the reason I've been involved in so many discussions in
the past. I've tried to have a clean environment and it was much more
work than I wanted to do. If I wanted to be involved in making a damned
OS distribution, I'd get involved with Debian. (And people know what I
think of doing that ;)
...
>> To a degree, the answer is yes. But it's a lot of care that you don't
>> have to give for any other platform. There may be an alternate answer
>> (aside from the one that MS *should* be giving, which is essentially
>> shimming over older C runtimes to force them to use the new runtime
>> that has a compatibility mode; you know, like the quality Unix
>> vendors). If someone were to provide a series of libraries
>> vc6clean.dll, vc7clean.dll, vc71clean.dll, etc. that implements unique
>> calls like vc6_free(void*) or vc6_close(FILE*) that could be used when
>> you know that linkage, great. But if the linkage ever changes, you're
>> back to a problem. (It might be possible to detect some of that at
>> runtime, but you'd have to probably work with explicit DLL handles.)
> Yes - this system sucks. But its what Microsoft has done, I'm sure
> partly to avoid DLL hell. Not sure the solution is better than the
> problem though.
It isn't. I like what Sun has done with its C runtime; somehow they're
able to have multiple versions of a function body in the runtime library
that are resolved by some link labels at compile time. That way, if I
compile something with Forte 6 on Solaris 7, it'll still work on Solaris
10 but not try to use any of the new features that Forte 6 and Solaris 7
don't know about.
I think that IBM has done something similar on AIX.
Linux (well, the GNU project more than anything, since it's based on
glibc or whatever it's called these days) actually takes a more Windows-
like approach that's only mitigated by
> Anyway, Python uses VC2003 so it is doable....
They have their problems, too. Also, check distutils (for which we don't
have an equivalent in Ruby right now). BTW, Nobu or NaHi posted
something a couple of years ago that shows that it's possible to make a
Windows DLL that's runtime independent.
A quick search found this article from 2003:
<http://www.ddj.com/windows/184416623>
Linking dynamically can cause dependency problems (including
version incompatibilities and distribution problems) in addition
to increases in load times. Because the CRT DLL is not part of
the Win32 system libraries, it is even possible to encounter older
systems in which it is not installed. (Windows 95 OSR1 does not
ship with MSVCRT.dll as part of the operating system distribution.)
Furthermore, Microsoft has encountered program-breaking incompat-
ibilities between versions of MSVCRT.dll ("Bug++ of the Month," WDJ,
May 1999), which is also something we developers are very keen to
avoid. Finally, since the DLL version is only available in multi-
threaded form, it can also lead to subtle, but significant, per-
formance costs.
The solution, of course, isn't trivial...and doesn't help unless your
upstream DLL source uses it.
Luis Lavena
> On 10/4/07, Charlie Savage <cf...@savagexi.com> wrote:
> >> The answer is no. The standard zlib is explicitly only built with
> >> MSVCRT (VC6) because it's the last version that can guarantee being
> >> installed on every copy of Windows, ever.
> > You mean msvcrt.lib is the only runtime library that is guaranteed on
> > each windows platform.
>
> MSVCRT is the last version of the runtime library that was distributed
> with the operating system by default, and is on every version from
> Windows 98 on. Everything else is ... uncertain.
>
What means Installer after all? We could ship the Runtime dependencies
and bundle what version of dlls we want. is a Installer, remember?
> That's why, in part, mingw relies on MSVCRT rather than anything later.
> (There were some basic performance tests that showed that mingw Ruby is
> about 10% faster than VC6 Ruby, but VC8 Ruby is about 25% or more faster
> than VC6 Ruby.)
>
Mmm, I don't know from which place you collected that "statistical"
information. This is mine:
http://pastie.caboo.se/pastes/95210
> You can see a little more about that with the zlib distributable.
>
> > But is one click installer recompiling these libraries, or using their
> > pre-built binaries?
>
> Using pre-built binaries in all cases. Sometimes, such as with the
> Oracle libraries, it's the only choice. (But the Oracle libraries are
> also a no-brainer to use because they do the right things.)
>
For the VC8, Vc9 or even VC71 (2003) we require compile everything.
> >> I gave up some time after I had to edit pdcurses to compile in Visual
> >> Studio 2005 and realized that my new libraries weren't being seen by
> >> Ruby for compiling the extensions anyway.
> > What do you mean?
>
> I mean that in late '05 and early '06, I was going through and setting
> up a comprehensive build environment that would build all of the
> dependent libraries (that we could) as well as the Ruby extensions and
> Ruby, using Visual Studio 2005 Express. This was mostly done through
> patches to code, unless the upstream provider could be found and
> encouraged to accept a patch to fix the problems. I did this for about
> four libraries and then got pissed off (not just at these libraries, but
> at how Ruby is built on Windows -- and I'm not blaming the Ruby
> developers, to be honest) and gave up.
>
Good to know, you gave up... nice rant :-)
> That's part of the reason I've been involved in so many discussions in
> the past. I've tried to have a clean environment and it was much more
> work than I wanted to do. If I wanted to be involved in making a damned
> OS distribution, I'd get involved with Debian. (And people know what I
> think of doing that ;)
>
Oh, another rant, nice...
> > Anyway, Python uses VC2003 so it is doable....
>
> They have their problems, too. Also, check distutils (for which we don't
> have an equivalent in Ruby right now). BTW, Nobu or NaHi posted
> something a couple of years ago that shows that it's possible to make a
> Windows DLL that's runtime independent.
>
distutils was their solution to the current compiler-problem we are
facing with Ruby right now.
For the record, There is a strong, finnacially-backed version of
Python (ActiveState) -- Most of the win32 enhancements came from
there.
> A quick search found this article from 2003:
> <http://www.ddj.com/windows/184416623>
>
> Linking dynamically can cause dependency problems (including
> version incompatibilities and distribution problems) in addition
> to increases in load times. Because the CRT DLL is not part of
> the Win32 system libraries, it is even possible to encounter older
> systems in which it is not installed. (Windows 95 OSR1 does not
> ship with MSVCRT.dll as part of the operating system distribution.)
> Furthermore, Microsoft has encountered program-breaking incompat-
> ibilities between versions of MSVCRT.dll ("Bug++ of the Month," WDJ,
> May 1999), which is also something we developers are very keen to
> avoid. Finally, since the DLL version is only available in multi-
> threaded form, it can also lead to subtle, but significant, per-
> formance costs.
>
> The solution, of course, isn't trivial...and doesn't help unless your
> upstream DLL source uses it.
>
Windows 9x series shouldn't be a issue right now. If want run ruby
over these OS, stick to older Ruby.
Alex Young
> For the record, There is a strong, finnacially-backed version of
> Python (ActiveState) -- Most of the win32 enhancements came from
> there.
distro? It's right up their alley...
--
Alex
M. Edward (Ed) Borasky
with Komodo and OpenKomodo, which is their browser-side open source
project. But they do have some job openings, and perhaps they're looking
for just the right person to do ActiveRuby and the Ruby Development Kit.
And they're located in one of the most beautiful parts of the world. If
I liked Windows development, etc. ... ;)
They've definitely committed to making Komodo the IDE of choice for web
applications, including Rails. I think they have a pretty good shot at
it from what I've seen.
Austin Ziegler
> On 10/4/07, Austin Ziegler <halos...@gmail.com> wrote:
>> On 10/4/07, Charlie Savage <cf...@savagexi.com> wrote:
>>>> The answer is no. The standard zlib is explicitly only built with
>>>> MSVCRT (VC6) because it's the last version that can guarantee being
>>>> installed on every copy of Windows, ever.
>>> You mean msvcrt.lib is the only runtime library that is guaranteed
>>> on each windows platform.
>> MSVCRT is the last version of the runtime library that was
>> distributed with the operating system by default, and is on every
>> version from Windows 98 on. Everything else is ... uncertain.
> What means Installer after all? We could ship the Runtime dependencies
> and bundle what version of dlls we want. is a Installer, remember?
I think you're sort of missing the point of what I'm saying; I'll
address it clearer momentarily.
>> That's why, in part, mingw relies on MSVCRT rather than anything
>> later. (There were some basic performance tests that showed that
>> mingw Ruby is about 10% faster than VC6 Ruby, but VC8 Ruby is about
>> 25% or more faster than VC6 Ruby.)
> Mmm, I don't know from which place you collected that "statistical"
> information. This is mine:
>
> http://pastie.caboo.se/pastes/95210
Fair enough. I was going on memory from over a year ago.
>>> But is one click installer recompiling these libraries, or using
>>> their pre-built binaries?
>> Using pre-built binaries in all cases. Sometimes, such as with the
>> Oracle libraries, it's the only choice. (But the Oracle libraries are
>> also a no-brainer to use because they do the right things.)
> For the VC8, Vc9 or even VC71 (2003) we require compile everything.
If you want to do that -- which means patching upstream code sometimes
-- you're more than welcome to. I, for one, am not interested in doing
that, having tried it once. I suspect that unless there's a strong
distributed volunteer effort (fat chance of that) or financial backing
(unlikely), the interest in doing that will fade quickly.
I can predict with some certainty that you won't be able to convince
some of these upstream sources to switch to VS2005 or later, so it's
going to be entirely up to you; some of them don't even appear to be
around anymore (or paying attention to patches) so you can't even submit
patches meaningfully. (I'm on the zlib-devel list, in part because of
changes that I provided that made it possible to compile zlib on VS2005
at all due to the manifest changes. zlib 1.2.4 has been in process for
the better part of a year. It's also worth noting that if you compile
zlib with anything but VC6/mingw on Windows, you shouldn't call it
zlib1.dll, per the zlib documentation.)
>>>> I gave up some time after I had to edit pdcurses to compile in
>>>> Visual Studio 2005 and realized that my new libraries weren't being
>>>> seen by Ruby for compiling the extensions anyway.
>>> What do you mean?
>> I mean that in late '05 and early '06, I was going through and
>> setting up a comprehensive build environment that would build all of
>> the dependent libraries (that we could) as well as the Ruby
>> extensions and Ruby, using Visual Studio 2005 Express. This was
>> mostly done through patches to code, unless the upstream provider
>> could be found and encouraged to accept a patch to fix the problems.
>> I did this for about four libraries and then got pissed off (not just
>> at these libraries, but at how Ruby is built on Windows -- and I'm
>> not blaming the Ruby developers, to be honest) and gave up.
> Good to know, you gave up... nice rant :-)
I gave up because it was a lot more work than it should have been. Don't
get me wrong: I'm not trying to hold Ruby back from a better compiler on
Windows. But it's a harder problem than people think it is.
>>> Anyway, Python uses VC2003 so it is doable....
>> They have their problems, too. Also, check distutils (for which we
>> don't have an equivalent in Ruby right now). BTW, Nobu or NaHi posted
>> something a couple of years ago that shows that it's possible to make
>> a Windows DLL that's runtime independent.
> distutils was their solution to the current compiler-problem we are
> facing with Ruby right now.
>
> For the record, There is a strong, finnacially-backed version of
> Python (ActiveState) -- Most of the win32 enhancements came from
> there.
Yeah. I've talked with someone at ActiveState, too, about their
problems. It's not entirely a satisfactory situation for the same
reasons.
>> A quick search found this article from 2003:
>> <http://www.ddj.com/windows/184416623>
>>
>> Linking dynamically can cause dependency problems (including
>> version incompatibilities and distribution problems) in addition
>> to increases in load times. Because the CRT DLL is not part of
>> the Win32 system libraries, it is even possible to encounter older
>> systems in which it is not installed. (Windows 95 OSR1 does not
>> ship with MSVCRT.dll as part of the operating system distribution.)
>> Furthermore, Microsoft has encountered program-breaking incompat-
>> ibilities between versions of MSVCRT.dll ("Bug++ of the Month," WDJ,
>> May 1999), which is also something we developers are very keen to
>> avoid. Finally, since the DLL version is only available in multi-
>> threaded form, it can also lead to subtle, but significant, per-
>> formance costs.
>>
>> The solution, of course, isn't trivial...and doesn't help unless your
>> upstream DLL source uses it.
> Windows 9x series shouldn't be a issue right now. If want run ruby
> over these OS, stick to older Ruby.
On that, I can't agree. Win9x may not be an issue, but what about
Win2000, which is still in pretty heavy use?
There is another set of problems to be considered, though. config.rb has
less-than-optimal information for Windows compiles (and always has)
since it contains information about specifically where so-and-so
compiled it from, which may not match where you compile from.
Additionally, since Windows doesn't have a useful set of command-line
build tools (mingw shell notwithstanding), a whole bunch of things still
won't work right without a lot of extra work.
Anyway, if you or someone else wants to pick up the effort to patch all
these upstream sources and compile them for a one-click installer with
VS2005, be my guest and I eagerly await the results of what you produce,
because I do need a reliable Ruby at work.
I just wanted to make sure that people understood the issues involved
and that some of the ground has been tread before.
M. Edward (Ed) Borasky
>> Windows 9x series shouldn't be a issue right now. If want run ruby
>> over these OS, stick to older Ruby.
>
> On that, I can't agree. Win9x may not be an issue, but what about
> Win2000, which is still in pretty heavy use?
Win2000 (and SQL Server 2000) may be in "heavy use", but they are both
maintenance nightmares all on their own, without any complications
introduced by maintenance nightmares from Ruby. :) My advice is to not
waste time on anything older than Windows 2003 Server (latest version,
whatever it's called), Windows XP *Professional* SP2 and Windows Vista.
For that matter, I don't know why anyone bothers compiling for chips
older than a P3 either. :)
> I just wanted to make sure that people understood the issues involved
> and that some of the ground has been tread before.
The issues are largely those of people who don't want to work without
getting paid, and I can't say I blame them. People like me who both work
for a living and do hobby/volunteer/open source work with computers may
be common in places like Ruby-Core and Ruby-Talk, but we *aren't* all
that common elsewhere and never have been.
Curt (Work) Hibbs
>
> The issues are largely those of people who don't want to work without
> getting paid, and I can't say I blame them. People like me who both work
> for a living and do hobby/volunteer/open source work with computers may
> be common in places like Ruby-Core and Ruby-Talk, but we *aren't* all
> that common elsewhere and never have been.
And even those of us who do work without getting paid, and like to do
so, are often over committed as well (if someone could tell me how to
get by without sleep, I'd love to gain an extra 6 hours a day!).
Curt
Austin Ziegler
> > I just wanted to make sure that people understood the issues involved
> > and that some of the ground has been tread before.
> The issues are largely those of people who don't want to work without
> getting paid, and I can't say I blame them. People like me who both work
> for a living and do hobby/volunteer/open source work with computers may
> be common in places like Ruby-Core and Ruby-Talk, but we *aren't* all
> that common elsewhere and never have been.
I'm not sure that's a 100% fair assessment. All of my work with Ruby
has been on a volunteer basis in the years I've been involved. Even
with my time at the near-zero that it is (remember, I'm still trying
to find a new person to take over PDF::Writer and other libraries),
I'd be glad to help out with the Windows build stuff … except that I
don't want to fix other peoples' problems (e.g., the upstream stuff).
If it were a pure Ruby issue, I'd be all over it. As it is, I've
already spent a lot of time trying to get people who are more
qualified than I (e.g., the people at Microsoft) to help us find a
positive resolution that doesn't require us to rebuild everyone else's
code. It's quite depressing.
Michal Suchanek
> Austin Ziegler wrote:
> >> Windows 9x series shouldn't be a issue right now. If want run ruby
> >> over these OS, stick to older Ruby.
Hmm, these are unfortunately still used. But that's a problem in
itself, the fact that ruby might need a few more libraries on these
wouldn't hurt much. Pretty much anything does.
> >
> > On that, I can't agree. Win9x may not be an issue, but what about
> > Win2000, which is still in pretty heavy use?
>
> Win2000 (and SQL Server 2000) may be in "heavy use", but they are both
> maintenance nightmares all on their own, without any complications
> introduced by maintenance nightmares from Ruby. :) My advice is to not
> waste time on anything older than Windows 2003 Server (latest version,
> whatever it's called), Windows XP *Professional* SP2 and Windows Vista.
I do not see that much difference between Win2k and WinXP. Maybe you
meant NT4 or something?
And if you call Win2k a nightmare I do not have words for Windows Vista ...
Thanks
Michal
_why
> The problem is the whole "how extensions are build, compiled and
> packaged with different compilers"...
>
> So far, to link successfully (without tweaks to rbconfig.rb) you still
> need VC6, which is currently unavailable.
>
> Now VC8 is released as free package (under Visual Studio Express 2005
> or Windows Vista SDK) -- in any case, is more simpler get the
> environment right to compile Ruby and the extensions (under the
> mswin32_80 platform).
Since part of this discussion revolves around getting an available
compiler from Microsoft, I thought I'd mention that we've been using
the Windows 2003 DDK to build Shoes. I'd cite this as another easy
way to get an environment going, though it's distributed as an ISO.
https://code.whytheluckystiff.net/shoes/wiki/BuildingShoesWithWindowsDdk
I think I got the idea from the Tcl wiki.
_why
Luis Lavena
> On Mon, Oct 01, 2007 at 01:25:52AM +0900, Luis Lavena wrote:
> > The problem is the whole "how extensions are build, compiled and
> > packaged with different compilers"...
> >
> > So far, to link successfully (without tweaks to rbconfig.rb) you still
> > need VC6, which is currently unavailable.
> >
> > Now VC8 is released as free package (under Visual Studio Express 2005
> > or Windows Vista SDK) -- in any case, is more simpler get the
> > environment right to compile Ruby and the extensions (under the
> > mswin32_80 platform).
>
> Since part of this discussion revolves around getting an available
> compiler from Microsoft, I thought I'd mention that we've been using
> the Windows 2003 DDK to build Shoes. I'd cite this as another easy
> way to get an environment going, though it's distributed as an ISO.
>
Thank you _why for the information. that is true. everything is around
what compiler we should use.
2003 DDK is VC 7.1 (the VC2003 free compiler), which, as far I have
used for some testing scenarios, works and compiles everything inside
Ruby just like VC6 (and even stick to MSVCRT instead their own MSVCR71
Runtime).
> https://code.whytheluckystiff.net/shoes/wiki/BuildingShoesWithWindowsDdk
>
> I think I got the idea from the Tcl wiki.
>
So, to summarize we have a few paths:
- Keep using VC6 and find workarounds to compile extensions with other
compilers (maybe with better documentation for this topic).
Pro: we are already there, Con: bad performance and issues with the compiler-
- Implement some sort of distutils for ruby
Pro: will be good for ruby at the end. Con: will take time and much
more to be integrated as part of ruby-core.
- Switch to VC8/9.
Pro: better performance, compiler freely available (in the shape of
Visual Studio Express or Windows SDK).
Known x64 support availability, for future developments/switch to
64bits OS -- There is a Ruby 1.9 build against VC8_x64.
Con: requires hacking and fixing of upstream libraries (dependencies)
which aren't prepared for it (gnu tools like readline, iconv, gettext,
and so on as example).
- Switch to MinGW
Pro: will ease the path of getting dependencies build (like the ones
cited before). It also link against already known runtime library
(msvcrt.dll) which is available in every stable OS since Windows 2000
-- AFAIK.
Con: This will also require maintain builds of upstream libraries,
even are more simpler to them build.
The support for x64 platforms is still under development -- is not
part of stable either candidates of current MinGW releases... which is
a problem (is another branch of project looking to get integrated).
Ok, these are the scenarios, and their good and bad points.
for those who every time just reply that "we should stick to MS
compilers" in the field I haven't found (excluding the 64bits part) no
differences from using MinGW. On the contrary, and thankfuly to the
"simple installer" get the correct dev environment more easily than
Microsoft tools.
Regards everyone and good weekend
daz (c)
If the ".iso" distribution is a problem for anyone ...
http://www.softwarepatch.com/windows/xpvirtualcd.html
(Also, http://weblogs.asp.net/pleloup/archive/2004/01/15/58918.aspx)
... these links describe (MS) Virtual CD-ROM Control Panel
The downloaded ".exe" is a self-extracting ZIP archive.
I just tried it - and was amused. :)
Didn't need a re-boot ... just worked.
daz
M. Edward (Ed) Borasky
>> Win2000 (and SQL Server 2000) may be in "heavy use", but they are both
>> maintenance nightmares all on their own, without any complications
>> introduced by maintenance nightmares from Ruby. :) My advice is to not
>> waste time on anything older than Windows 2003 Server (latest version,
>> whatever it's called), Windows XP *Professional* SP2 and Windows Vista.
>
> I do not see that much difference between Win2k and WinXP. Maybe you
> meant NT4 or something?
>
> And if you call Win2k a nightmare I do not have words for Windows Vista ...
Which is why I said *older* than Windows 2003 Server or XP SP2.
And I probably should not have been so kind to the Pentium 3 either. :)
M. Edward (Ed) Borasky
> On 10/5/07, M. Edward (Ed) Borasky <zn...@cesmail.net> wrote:
>> Austin Ziegler wrote:
>>> I just wanted to make sure that people understood the issues involved
>>> and that some of the ground has been tread before.
>> The issues are largely those of people who don't want to work without
>> getting paid, and I can't say I blame them. People like me who both work
>> for a living and do hobby/volunteer/open source work with computers may
>> be common in places like Ruby-Core and Ruby-Talk, but we *aren't* all
>> that common elsewhere and never have been.
>
> I'm not sure that's a 100% fair assessment. All of my work with Ruby
> has been on a volunteer basis in the years I've been involved. Even
> with my time at the near-zero that it is (remember, I'm still trying
> to find a new person to take over PDF::Writer and other libraries),
> I'd be glad to help out with the Windows build stuff … except that I
> don't want to fix other peoples' problems (e.g., the upstream stuff).
>
> If it were a pure Ruby issue, I'd be all over it. As it is, I've
> already spent a lot of time trying to get people who are more
> qualified than I (e.g., the people at Microsoft) to help us find a
> positive resolution that doesn't require us to rebuild everyone else's
> code. It's quite depressing.
What's in it for Microsoft? They'll have IronRuby, and I'm sure they're
quite capable of making sure things with underlying C code can be
integrated with it.
>
> -austin
Austin Ziegler
At the time the discussions were being held (June '06), John Lam
wasn't an employee of Microsoft and they were just getting onto the
Ruby bandwagon. Shortly after the discussions, I think that John was
approached. I could be wrong on the timeline (since the negotiations
were obviously private and he didn't announce anything until it was a
done deal), but the timing seems about right.
IronRuby is essentially a 2007 initiative (IIRC, John wasn't being
hired to implement an IronRuby, but to look at overall dynamic
language support).
Martin Duerst
>Alex Young wrote:
>> That's a point... Have ActiveState shown any interest in making a ruby distro? It's right up their alley...
>>
>That's a very good question. My guess is that they have their hands full with Komodo and OpenKomodo,
I tried that once, but it was dead slow (about three seconds
per keystroke for updating the screen, or something in that ballpark).
Is that only for high-end developpment workstations, or what did I do wrong?
(I just have a small notebook with an Intel Pentium M, 1.30GHz.)
Regards, Martin.
#-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-# http://www.sw.it.aoyama.ac.jp mailto:due...@it.aoyama.ac.jp
M. Edward (Ed) Borasky
Well ... I run it on a 1.3 GHz Athlon T-bird, so it must be something in
your configuration. Questions:
1. How long ago? They've made lots of improvements over the years and
are currently shipping 4.2.
2. Windows or Linux? I run it on Linux, so I can't say how well it works
on Windows.
3. How much RAM? I'm guessing your processor is fine, but you might not
have enough RAM, especially if you've got lots of other stuff going on.
On Linux, watch out for Thunderbird and even Firefox. Komodo shares some
Mozilla code with them. And Thunderbird can be a real memory hog -- I've
had to shut it down at times even in a GB of RAM.
4. If all else fails, install the latest trial version and post your
issues on the forum. Unless you just need to de-frag your disk or buy
more RAM, you'll probably either get some diagnostic help or find a bug
for them. :)