Ruby on Windows (1)

Index

How to make mswin32 version Ruby

A version for mswin32 is distributed in source code format, so you have to compile it on yourself(Sept. 07, 1999). This section describes how to compile it with Visual C++ 5.0.

Other than Visual C++, you will need byacc and sed.

Sept. 12, 1999 added
Now, byacc and sed are no longer needed. They were needed for generating parse.c from parse.y, however, parse.c comes with Ruby package. (I haven't noticed that it changed a while ago.)

  1. Down load source code package.
  2. Unpack the package.
  3. Run/Open MS-DOS prompt.
  4. Under the bin directory that you installed Visual C++, run vcvars32.bat to allow compilation at DOS Prompt.
  5. Run ntsetup.bat in the win32 directory where you unpacked Ruby package.
  6. Run nmake.

If every thing went fine, you find ruby.exe and rubymw.dll.
However, you might get some errors if you are using beta version of Ruby. If so, ask at Ruby Mailing list, ruby-talk. (in case you need to ask in the ML, you better write exact error messages as shown.) Somebody will help you, I believe.

Three Rubies

There are three version of ruby which runs on Windows 95:
djgpp version of Ruby, cygwin32 version of Ruby, and mswin32 of Ruby.

djgpp version of Ruby

This runs under the MS-DOS's DOS-Extender environment. It runs fine under Windows 95's DOS prompt. I stop using djgpp version of Ruby because it lacks socket extension module.

cygwin32 version of Ruby

This runs under Gnu-Win32 environment. You'll need cygwin19.dll in order to run it. Extension modules runs fine, and it comes as binary format. This version is the best for ordinary uses.

mswin32 version of Ruby

It only comes in source code format. This version runs without cygwin19.dll. With my old pc, Pentium 90MHz, it runs better than cygwin32 version of it with stdout.

As you see now, I use cygwin32 version of Ruby and mswin32 version of Ruby.

Difference between cygwin32 version and mswin32 version

Written Oct. 31, 1999
You can check which version of ruby you are using if you run: 

ruby -v

The result should be 

ruby 1.4.2 (1999-09-18) [i386-cygwin]

or 

ruby 1.4.2 (1999-09-18) [i386-mswin32]

The former case, ([i386-cygwin]), indicates cygwin32 version,
the latter case, ([i386-mswin32]) indicates mswin32 version.

How to keep cygwin32 and mswin32 versions of Ruby

In order to keep two version of Rubies, I rename

cygwin32 version of Ruby's ruby.exe to rbgw.exe
mswin32 version of Ruby's ruby.exe to rbmw.exe

(I used to use as is, before.)

I keep all of Ruby's libraries in one directory with following lines in autoexec.bat.

set RUBYLIB=c:/ruby/lib

What I should do is that

but, I'm not doing it

Note on using libraries:
You can not share same xxx.dll files with cygwin32 and mswin32 version of Ruby.
e.g. If you can use Win32API.dll with cygwin32 version of Ruby, then you can't use the same Win32API.dll file with mswin32 version of Ruby.

In order to use Win32API with mswin32 version, I make all modules of mswin32 version statically linked.
Statically linked modules has priority over dll, so those two version can co-exist on one system.

Actually, if you compile straight forward, it generate statically linked binaries. To tell you the truth, I've never tried to make DLL's ;p

Aug. 21, 1999 added
From version 1.4.0 of Ruby, DLL generation got easier.
All you have to do is comment out the module list in Setup.nt. (If you uncomment, it generates statically linked binaries.)

Now two versions' modules need to find a way to co-exist. You should put

There should be no problem with this setup.

Basically, you can find out where the modules should be with following command: 

ruby -e 'puts $:'

With Ruby 1.4.0,

cygwin32 version's output should be

/usr/local/lib/ruby/1.4/site_ruby/i386-cygwin
/usr/local/lib/ruby/1.4/site_ruby
/usr/local/lib/ruby/1.4/i386-cygwin
/cygdrive/d/lib
/usr/local/lib/ruby/1.4

so, just put cygwin32 version of Ruby extension DLL in 

\usr\local\lib\ruby\1.4\i386-cygwin

with mswin32 version, you'll see

/usr/local/lib/site_ruby
/usr/local/lib/ruby/1.4/i386-mswin32
D:/lib
/usr/local/lib/ruby/1.4

so, put modules in 

\usr\local\lib\ruby\1.4\i386-mswin32

rubyw.exe

In cygwin32 version of Ruby, you'll find rubyw.exe other than ruby.exe. You can use it when you want to run with double click in Explorer.

Associate files with extension ".rb" to rubyw.exe. This allows you to run your scripts without DOS prompt when double clicked. It's good idea to do so when you don't need DOS prompt, such as when you are using Tk extension. ( Do NOT try with any script that needs DOS prompt ）

There are good chance that your scripts need DOS prompt, so it better to change the no-prompt-need-scripts' extension to ".wrb" and associate them to rubyw.exe. Others can just use ruby.exe with .rb extension.

I don't usually use rubyw.exe, so that's all I need/tried.

Win32OLE tips

Excel's VBA runs faster with less '.'s. That's true for Ruby's win32ole. For example, writing 


application = WIN32OLE.new('Excel.Application')
application.visible = TRUE
workbook = application.Workbooks.Add()
worksheet = workbook.Worksheets(1)
worksheet.Range("A1").value = 1
worksheet.Range("A2").value = 2
worksheet.Range("A3").value = 4
worksheet.Range("A4").value = 8

is better than writing 


application = WIN32OLE.new('Excel.Application')
application.visible = TRUE
workbook = application.Workbooks.Add()
workbook.Worksheets(1).Range("A1").value = 1
workbook.Worksheets(1).Range("A2").value = 2
workbook.Worksheets(1).Range("A3").value = 4
workbook.Worksheets(1).Range("A4").value = 8

The former runs faster.

workbook.Worksheets(1) in 

workbook.Worksheets(1).Range("A1").value = 1

workbook object's method, Worksheets, is invoked. At the time, inside of win32ole,

  1. The function GetIDsOfNames is called to look up ID from the name 'Worksheets'.
  2. The method identified by the ID is invoked.

Every time workbook.Worksheets(1) is called, these two functions are also invoked. So, reducing the number of '.' makes script runs faster with out those overhead.

I'm thinking about implementing a way to use hash after the initial invocation. That is,

First time the workbook.Worksheets(1) is called, use GetIDsOfNames function to get ID, and keep the ID with the name 'Worksheets' inside of a hash. After the first call, use the hash instead of using GetIDsOfNames.

It seems faster, but I haven't implemented, yet.

Ruby itself does not use such function. It has some trick to make scripts runs faster. So, if you are not using win32ole, speed should not be a problem.

Summary: reducing the use of '.' makes VBA and/or Ruby runs faster.

Index