Here's a summary of what you need to do to install JR
and translate and execute JR programs
on a Windows system.
These steps are similar to those for UNIX systems
and you can consult
for Downloading and Installing JR
and Instructions for JR
program translation and execution
for more details.
- tested on Windows XP systems and Windows NT systems; not likely
to work on Windows 9x systems.
- You need JR, Java (JDK), and Perl.
(However, if you want to run multi-VM JR programs, you also
need an rsh. You can skip that for now.)
or modify the environment variables that are needed by JR:
- set JR_HOME to the location of the directory in which you
installed JR. E.g., on my Windows system I use
- set Path to incorporate JR_HOME's value. In general, set it to
(the ... represents what Path was previously set to)
but replace JR_HOME with its value. E.g., on my Windows system I
- set CLASSPATH to incorporate JR_HOME's value. In general,
set it to
but replace JR_HOME with its value, e.g., on my Windows system I
.;c:\Program Files\jr\classes\jrt.jar;c:\Program Files\jr\classes\jrx.jar
Be sure to include the initial ".".
- set JRSH to cmd
- set JRSHC to /C
- the DISPLAY environment variable (needed for JR in UNIX)
does not need to be set for
These changes probably will not take effect in your current cmd
windows; you might need to start a new cmd window
or even logout and re-login to get the new values.
- to test that JR is working, use jrv:
- in the JR_HOME directory,
The above will run a few tests and, if all's well, just echo their names as
it runs them. You can run many tests by
That might take over an hour depending on your system. It also
- here's how to set or
modify environment variables:
- Right click on the My Computer icon that should be on the
desktop or in the Start Menu.
- Select Properties from the menu.
- Select the Advanced tab.
- Click the Environment variables button.
- Make the change in either
- System Variables: this requires that you have administrator
rights; the change will apply to all users. Note that multi-VM JR
programs require the use of rsh. The rsh
below (perhaps others too) requires these JR environment variables
to be System Variables; we've observed that the system must be rebooted
before the changes take effect from rsh's perspective.
- User Variables: otherwise (but multi-VM JR programs won't
- In our tests, we used
http://www.denicomp.com/rshdnt.htm. Other RSH products might
work (please let us know). Note this product has a 30-day
evaluation period. The only RSH option we used with this product was
"Attempt Redirection on Every Command".
- Security configuration and warning!
- We just started the RSH daemon before testing and killed it
after testing on an isolated network.
- We've also run the RSH daemon using User Equivalencies on a
non-isolated network. In this mode, we found we needed to use IP
numbers instead of hostnames, so we had equivalencies for, e.g.,
- email@example.com (need this one
- With this rsh, we observed that some programs that use Swing
don't pop up all their windows. E.g., vsuite/dp/dpVis doesn't pop
all client windows; codeextract2.0/gui/BnB doesn't pop up its main
rsh's (under "RSH Options") "Default Window Type ..." to be
seems to fix the problem. (However,
the extra cmd windows are
somewhat annoying.) This problem was
discovered in testing for
2.00003, but previous 2.x versions exhibit this same
behavior on our
Windows test machines.
- known Windows-specific problems:
- 2004-11-30 (although observed earlier).
vsuite/misc/receive_a_proc_op/3 seems to not work correctly sometimes.
- 2003-09-26. An annoying, but not signficant, problem in
running the vsuite. This problem seems to happen repeatedly on
individual systems, but only for some systems. We haven't been
able to find the distinguishing characteristic.
Can't unlink file mypkg.jr: Permission denied at C:......\jrv\jrv line
- Windows and Perl scripts.
- Our original Windows implementation (Summer 2003) used only the
Perl scripts; it did not use .bat files. To allow the user to
type just "X" instead of "perl .....X", we included the .pl suffix in
the PATHEXT environment variable (which specifies the executable
- Our newer Windows implementation (Fall 2003) included both and
the .bat files (which just invoke the Perl scripts) worked fine.
- However, we had noticed a problem
- 2003-09-26: Problems with redirecting the output of jr, jrgo,
and jrgox. The file to which output is redirected is empty.
The programs run fine without redirection. These problems
seem to happen repeatedly on individual systems, but only for some
systems. We haven't been able to find the distinguishing
characteristic. In running the vsuite, these tests will fail as
shown due to this problem
0, got 1 from cmp
got 1 from cmp
- 2003-12-05: We discovered a problem on redirecting input.
Got "handle invalid" from Java, but only when we had .pl before
.bat in PATHEXT. We don't know the exact cause, but we reduced it
to a simpler problem: a 1 line Perl that contains just system("sort");.
When invoked as X < file, it gives "The handle is invalid."
too. It works fine, though, when invoked as perl X < file.
- 2003-12-05: We also discovered that not including .pl in
PATHEXT eliminates the output redirection problem noted earlier too.
- So, since we no longer need the .pl files and apparently
there's a bug in using them, we eliminated them.