On Jan 2, 2008 12:02 PM, Gary Wright <gwtmp01 / mac.com> wrote:
> On Jan 2, 2008, at 10:55 AM, M. Edward (Ed) Borasky wrote:
> > Thufir wrote:
> >> Completely off topic, but what's the equivalent for Linux?
> >>
> > There is a compiler, usually gcc but others exist. It translates the C
> > code to an object file. Then there is a linker which collects all
> > of the
> > object files and translates them to a "shared library", which usually
> > has a name ending in ".so". At run time, the shared library is brought
> > into working memory the first time a Ruby program references it, and
> > other Ruby programs can then reference it without having to load
> > another
> > copy.
> I could be wrong, but I sense a deeper question in Thurfir's message.
>
>    What is it about Linux (or *BSD or Mac OS X) that avoids all
>    the compilation problems that arise in the Windows environment?
>
> Can a Windows expert confirm my understanding that:
>
> Unlink Linux (and *BSD, Mac OS X...), Windows does not come packaged
> with a development environment and in fact there are multiple
> mutually-incompatible development environments (Cygwin, MinGW, VC6,
> VC8). For the most part you can not mix-and-match object code (dlls)
> created by these different environments with the biggest problem
> being that there is no common memory allocation library.

Not quite (close, though). Cygwin is and always will be incompatible
with real Windows software because of its dependence on cygwin1.dll.
MinGW uses the VC6 runtime libraries, but the compilers (gcc vs. VC6)
define things slightly differently. With care, you *can* mix and match
VC6 and MinGW builds.

It's where things differ with the version of the runtime libraries
that things get hairy. MSVCRT and its upversions (MSVCRT7, MSVCRT71,
MSVCRT8) are all the equivalent of libc (the C runtime). Each has its
own implementation of malloc (with its own heap table), its own file
handle table, etc.

Linux and Unixes don't run into this problem because they don't
typically have more than one version of the C runtime installed at one
time. When (and if) they do, it's Very Difficult to get software that
you build yourself to use a different C runtime than the default C
runtime. It's important to note that Solaris and AIX, at least, will
*never* run into this problem. Their C runtimes are©‘pecial. I'm more
familiar with the Solaris approach which provides a C runtime that
seems to have multiple implementations baked in marked with version
tags. I'm not sure how they do it, or if my understanding is right,
but that's what it seemed to me. OS X probably does something similar.

> I assume this is why some Windows software comes distributed with its
> own collection of 'standard' dlls compiled in the same development
> environment as the underlying application.

Again, not quite. That's laziness as much as anything, but it's also
because Microsoft only guarantees that VC6 DLLs are installed. After
that, if you wanted them installed in "standard" locations, you had to
install the software as an Administrator so it could put the runtime
in the right place. It's often easier to just pack the C runtime with
your software than to worry about crap like that.

> I also gather that each of those environments has very different
> build utilities (the Windows equivalent of make, config, autoconf,
> and so on). For an extension writer, the problem is that they can't
> really know what the build process is going to look like on an
> arbitrary Windows system making it very difficult to even distribute
> source packages.

That's close. The average Windows system won't have anything like
autoconf, though, and Ruby doesn't offer anything to help with that.
(That, and autoconf doesn't know how to deal with non-gcc on Windows,
it seems.)

-austin
-- 
Austin Ziegler * halostatue / gmail.com * http://www.halostatue.ca/
               * austin / halostatue.ca * http://www.halostatue.ca/feed/
               * austin / zieglers.ca