Windows support

ruby-talk
1

Hello,

Suppose I write a Ruby module with some C code in it. This is no problem
under Unix, Linux and Mac, but it makes things harder under Windows. What
is the best way to support Windows?

On a related note:

  1. Does Microsoft’s Visual C++ provide a ‘make’ program?
    If not, how can I get Ruby to compile C code automatically?

  2. Does Cygwin or MinGW provide a ‘make’ and gcc that can be used like the
    Linux ones?
    What’s the difference between Cygwin and MinGW? I ask because I could
    have a note on the project website saying

“If you are running Windows you’ll need to download …”

Something like that would fix the Windows support problem.

  1. What other C compilers should I support?

Thanks for the help.

···

–
Daniel Carrera
Graduate Teaching Assistant. Math Dept.
University of Maryland. (301) 405-5137

2

Daniel Carrera wrote:

Hello,

Suppose I write a Ruby module with some C code in it. This is no problem
under Unix, Linux and Mac, but it makes things harder under Windows. 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++.

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

  1. Does Cygwin or MinGW provide a ‘make’ and gcc that can be used like the
    Linux ones?

If you build a windows app using cygwin, any machines that you want to run
your code on will also require cygwin. It’s not an ideal solution.

  1. 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, although I wouldn’t use anything
other than VC++ for Windows, and gcc for *nix. The only other compiler
you’ll generally hear of people using is Sun’s C compiler, but it ain’t free.

Hope that helps.

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*”)

3

Daniel Carrera wrote:

Suppose I write a Ruby module with some C code in it. This is no problem
under Unix, Linux and Mac, but it makes things harder under Windows. What
is the best way to support Windows?

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

On a related note:

  1. Does Microsoft’s Visual C++ provide a ‘make’ program?

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.

  1. Does Cygwin or MinGW provide a ‘make’ and gcc that can be used like the Linux ones?

Yes, both the Cygwin project and MinGW provide ports of GNU make.

What’s the difference between Cygwin and MinGW?

For a brief description of MinGW, see:

 http://www.rubygarden.org/ruby?MinGW

and of course the MinGW home page (http://www.mingw.org).

  1. What other C compilers should I support?

For Windows? Seems like those three should cover it.

4

Hi,

  1. Does Microsoft’s Visual C++ provide a ‘make’ program?
    If not, how can I get Ruby to compile C code automatically?

Half yes.

I call it Not-MAKE or Nasty-MAKE.

In 1.8, extension of mingw and mswin are binary compatible, so
you don’t have to use VC++. In the fact, they are installed to
same directory.

  1. What other C compilers should I support?

Borland’s complier is supported in 1.8 now. Take a glance at
lib/mkmf.rb.

···

At Thu, 13 Feb 2003 05:40:35 +0900, Daniel Carrera wrote:

–
Nobu Nakada

5

Look into MinGW. I don’t use it at the moment myself, but I
understand that the binary objects that it produces are compatible
with the pragprog Windows Ruby distribution.

MinGW feels like Unix (gcc/make), so it should work as is for your
code. It’s free, obviously, which is one big advantage over VC++.

Packaging-wise, look at the Wiki for a QuickGuideToPackaging. There
should be a standard way to bundle the C code and have it built with
the correct tools on the target platform, without you needing to even
write a Makefile.

Gavin

···

On Thursday, February 13, 2003, 7:40:35 AM, Daniel wrote:

Hello,

Suppose I write a Ruby module with some C code in it. This is no
problem under Unix, Linux and Mac, but it makes things harder under
Windows. What is the best way to support Windows?

6

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

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?

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

Thanks for your help.

···

On Thu, Feb 13, 2003 at 06:02:05AM +0900, Daniel Berger wrote:

–
Daniel Carrera
Graduate Teaching Assistant. Math Dept.
University of Maryland. (301) 405-5137

7

I’m responding to both Daniel’s and Lyle’s responses here…

Daniel Carrera 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).

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

···

On Thu, Feb 13, 2003 at 06:02:05AM +0900, Daniel Berger wrote:

–
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*”)

8

I’m very confused. How could you ever guarantee that your code works
on Windows if you never test it ON Windows?

I’m just implementing simple math algorithms. The only thing I am likely
to include is “ruby.h”. It really should compile anywhere.

Ofcourse, I would test on Windows before I claim that it runs on
Windows. I’d probably send it to my brother in Canada to try it out. But
that would be a last step.

90% of my code is Ruby. I just want to use C to speed up a method here
and there.

The instant you #include a header file, you risk portability issues,
even between different flavors of *nix.

For what I’m doing, Mac OS X, Linux and all Unix should be trivally
supported. Windows presents the only possible difficulty.

Add the funky Windows API peculiarities and it becomes almost
impossible to write “one piece of code to bind them all”.

I will stay away from any Windows-specific API.
If I write ANSI C and don’t include anything, everything “should” be fine.
Right?

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?

I was thinking that it would be neat to have a single “install.rb” which
would do everything. I’m trying to comeup with an easy-and-reliable
installer.

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

What do those options do?
Would it be ok to just grab Ruby’s ARGV and pass it to (n)make?

···

On Thu, Feb 13, 2003 at 07:23:21AM +0900, Daniel Berger wrote:

–
Daniel Carrera
Graduate Teaching Assistant. Math Dept.
University of Maryland. (301) 405-5137

9

Responding to Daniel Berger’s response to my response :wink:

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

I didn’t mean to suggest that ‘nmake’ is broken or anything, just that
it has some different stuff that GNU make. Or, put another way, if you
take a Makefile that works with GNU make it may not work with nmake
without some tweaking. I now wish I could remember something more
specific; but since I can’t, I’ll just drop that issue :wink:

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.

OK, I’ll agree with that (that doing a full-blown installer is overkill
for small extensions) :wink:

10

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*”)

Daniel,

YACS - Yet Another Cool Sig.

What do you think of this one?

str = “aa tut Rnrehoec Jykusbrh”; srand 0
0.upto(999) {|i| x = rand(23); str[x,2] = str[x,2].reverse! }; puts str

Hal

···

----- Original Message -----
From: “Daniel Berger” djberge@qwest.com
To: “ruby-talk ML” ruby-talk@ruby-lang.org
Sent: Wednesday, February 12, 2003 4:23 PM
Subject: Re: Windows support

11

What do you think of this one?

str = “aa tut Rnrehoec Jykusbrh”; srand 0
0.upto(999) {|i| x = rand(23); str[x,2] = str[x,2].reverse! }; puts str

LOL… :slight_smile: Were you joking, Hal? Or is my 1.6.6 mswin32 possibly
using a different algorothm for rand than your version? I couldn’t
understand the result… :frowning:

Regards,

Bill

=155813688791654835066064433267;while(>0);p(((((y=%28)>1)?63:32)+y).chr);/=28;end

···

From: “Hal E. Fulton” hal9000@hypermetrics.com

12

From: “Hal E. Fulton” hal9000@hypermetrics.com

What do you think of this one?

str = “aa tut Rnrehoec Jykusbrh”; srand 0
0.upto(999) {|i| x = rand(23); str[x,2] = str[x,2].reverse! }; puts
str

LOL… :slight_smile: Were you joking, Hal? Or is my 1.6.6 mswin32 possibly
using a different algorothm for rand than your version? I couldn’t
understand the result… :frowning:

That’s very interesting.

You didn’t omit the srand, did you?

For me, it prints “Just another Ruby hacker” –
and the srand is supposed to make the randomizing
deterministic or predictable.

Maybe that’s only true within versions and/or
platforms.

Hal

···

----- Original Message -----
From: “Bill Kelly” billk@cts.com
To: “ruby-talk ML” ruby-talk@ruby-lang.org
Sent: Wednesday, February 12, 2003 7:03 PM
Subject: Re: .sig - was Re: Windows support

13

str = “aa tut Rnrehoec Jykusbrh”; srand 0
0.upto(999) {|i| x = rand(23); str[x,2] = str[x,2].reverse! }; puts str

LOL… :slight_smile: Were you joking, Hal? Or is my 1.6.6 mswin32 possibly
using a different algorothm for rand than your version? I couldn’t
understand the result… :frowning:

That’s very interesting.

You didn’t omit the srand, did you?

For me, it prints “Just another Ruby hacker” –
and the srand is supposed to make the randomizing
deterministic or predictable.

Maybe that’s only true within versions and/or
platforms.

I definitely included the srand… Haven’t checked the Ruby src;
but maybe it calls a platform-specifc rand?

Regards,

Bill

P.S. what it yields on 1.6.6/mswin32 for me is, “aeoneR t rurhachJtykubs” :slight_smile:

···

From: “Hal E. Fulton” hal9000@hypermetrics.com

14

From: “Hal E. Fulton” hal9000@hypermetrics.com

str = “aa tut Rnrehoec Jykusbrh”; srand 0
0.upto(999) {|i| x = rand(23); str[x,2] = str[x,2].reverse! };
puts str

LOL… :slight_smile: Were you joking, Hal? Or is my 1.6.6 mswin32 possibly
using a different algorothm for rand than your version? I couldn’t
understand the result… :frowning:

That’s very interesting.

You didn’t omit the srand, did you?

For me, it prints “Just another Ruby hacker” –
and the srand is supposed to make the randomizing
deterministic or predictable.

Maybe that’s only true within versions and/or
platforms.

I definitely included the srand… Haven’t checked the Ruby src;
but maybe it calls a platform-specifc rand?

Regards,

Bill

P.S. what it yields on 1.6.6/mswin32 for me is, “aeoneR t rurhachJtykubs”
:slight_smile:

Well, I don’t think it’s platform-specific, as I’m
also on Windows:

ruby 1.7.3 (2002-11-17) [i386-mswin32]

Maybe version-specific? That’s a tiny bit disturbing
if so…

Hal

···

----- Original Message -----
From: “Bill Kelly” billk@cts.com
To: “ruby-talk ML” ruby-talk@ruby-lang.org
Sent: Wednesday, February 12, 2003 7:32 PM
Subject: Re: .sig - was Re: Windows support

15

rand() is probably implemented in terms of rand(3). On FreeBSD, 4 and 5
will have different versions of rand(), so this didn’t work at all for
me.

···

Hal E. Fulton (hal9000@hypermetrics.com) wrote:

Well, I don’t think it’s platform-specific, as I’m
also on Windows:

ruby 1.7.3 (2002-11-17) [i386-mswin32]

Maybe version-specific? That’s a tiny bit disturbing
if so…

–
Eric Hodel - drbrain@segment7.net - http://segment7.net
All messages signed with fingerprint:
FEC2 57F1 D465 EB15 5D6E 7C11 332A 551C 796C 9F04

16

Maybe version-specific? That's a tiny bit disturbing
if so...

1.8 use Mersenne Twister, which is not the case for 1.6

Guy Decoux

17

Well, I don’t think it’s platform-specific, as I’m
also on Windows:

ruby 1.7.3 (2002-11-17) [i386-mswin32]

Maybe version-specific? That’s a tiny bit disturbing
if so…

Yes, as it has changed…

rand() is probably implemented in terms of rand(3). On FreeBSD, 4 and 5

It is not. As of 1.7.3, it is using the Mersenne Twister.

    * random.c: replace with Mersenne Twister RNG.

The 1.6 branch uses the system’s rand() or random(), so results would
depend on the platform. The change must have occurred between 1.7.2 and
1.7.3 since I’m getting the same results with 1.7.2 and 1.6.8.

···

On Thu, Feb 13, 2003 at 11:53:06AM +0900, Eric Hodel wrote:

Hal E. Fulton (hal9000@hypermetrics.com) wrote:
Fri Jul 26 14:31:06 2002 Yukihiro Matsumoto matz@ruby-lang.org

will have different versions of rand(), so this didn’t work at all for
me.

–
_ _

__ __ | | ___ _ __ ___ __ _ _ __
'_ \ / | __/ __| '_ _ \ / ` | ’ \
) | (| | |__ \ | | | | | (| | | | |
.__/ _,|_|/| || ||_,|| |_|
Running Debian GNU/Linux Sid (unstable)
batsman dot geo at yahoo dot com

…[Linux’s] capacity to talk via any medium except smoke signals.
– Dr. Greg Wettstein, Roger Maris Cancer Center