Re: Windows support

I'm responding to both Daniel's and Lyle's responses here...

Daniel Carrera wrote:

> On Thu, Feb 13, 2003 at 06:02:05AM +0900, Daniel Berger wrote:
> [snip]
> > > What is the best way to support Windows?
> >
> > Buy  VC++ 6.0 or later.  Share .so files for folks who don't have (or can't
> > afford) VC++.
>
> Well.  I'm not going to go out and buy Windows and then buy VC++ just for
> this.  I have no interest in using Windows.  I just want to suppor it.

I'm very confused.  How could you ever guarantee that your code works on Windows
if you never test it ON Windows?  The instant you #include a header file, you risk
portability issues, even between different flavors of *nix.  Add the funky Windows
API peculiarities and it becomes almost impossible to write "one piece of code to
bind them all".  There are things you can do within mkmf, or #ifdefs within your C
code, but the actual *behavior* of identical C functions can vary wildly from
platform to platform.

> > > On a related note:
> > >
> > > 1) Does Microsoft's Visual C++ provide a 'make' program?
> >
> > Yes, it's called nmake, and you can get it for free off the internet.  It
> > also comes with VC++.
>
> Thanks.  Does nmake come with a C compiler too?

No.

Lyle Johnson wrote:

>Yes, but it's called "nmake". There are also some differences between
>GNU make's Makefile format (rules, etc.) and Microsoft's -- not sure if
>those differences are documented anywhere, though.

There are issues with the nmake that came with VC++ 5.0 and earlier (and problems
with VC++ 5.0 itself), which is why I recommended VC++ 6.0 or later.  I haven't
had any problems with it (yet).  They are documented....somewhere (can't remember
where now).

> > > 3) What other C compilers should I support?
> >
> > You shouldn't need to worry about supporting specific compilers.  Your C code
> > should compile irregardless of compiler,
>
> That's not what I meant by my question.  I will defintelly write my code
> in ANSI C.  I am talking about getting my Ruby installer to call the right
> program.
>
> So, in my installer I would test to see if either "make" or "nmake" is
> installed, and then I'd call the one available.  Is that about it?  Does
> nmake also come with a compiler?

You shouldn't need to test it yourself.  *nix users know to use 'make', Windows
users know to use 'nmake'.  Or at least, they *will* know because you'll tell them
in your INSTALL file, right?  Or, if you really want to build programatically,
test using RUBY_PLATFORM.

However, you probably DON'T want to do build programatically, because then you
prevent folks from passing any options to (n)make (-B, -C, etc).

Lyle Johnson wrote:

>I think the number one recommendation is to rovide precompiled binaries
>for your Windows users, preferably in a standard Windows installer
>executable.

For extensions Lyle?  Heck, I don't know how to support Install Shield, but even
if I did I would only use it for large packages and/or standalone apps, not small
extensions.

Providing individual .so files is easy enough, though I think you will need help
from the community to do this, unless you happen to have 95, 98, ME, 2000 and XP
all installed somewhere.  Generally speaking, I'd worry about the NT side of
things first (NT 4, 2000, XP Pro), 98 second, 95 third and ME last.

Regards,

Dan

--
a = [74, 117, 115, 116, 32, 65, 110, 111, 116, 104, 101, 114, 32, 82, 117, 98]
a.push(121, 32, 72, 97, 99, 107, 101, 114)
puts a.pack("C*")