Andrey -

Thank you for the response.   I had already tried most of your suggestions in one form or another.    So below is my
latest try (reduced to the essentials) to find what works and what doesn’t.  The essential idea was to take the PATH out
of consideration by reducing it to a minimum in both the CMD and Cygwin environments.   This did not change the result
at all.  This is expected, because Crystal Reports does not itself depend on anything in the PATH.  The user defined
functions are dynamically loaded and installed when run under Cygwin but not when run in a Windows command window.

There are differences in the environments (attached) but I don’t see anything Cygwin has added or changed that would
make a difference.  After all, Crystal Reports knows nothing about Cygwin specific environment variables so anything
added by Cygwin should not affect the behavior.   There are a few things that are different (oddly) , but manually
setting these in either environments is a bit tedious.

Now there are some details about the way user defined functions are installed that are peculiar.  First of all,  the
CLASSPATH settings are obviously read from the registry by Crystal Reports, not from the environment.   This is one of
the nasty manual configuration settings I mentioned below.    It also reads the path to a JVM .dll from a registry
setting and this also has to be set  to get user defined functions working.   When running  the script below in a
Windows CMD window,  Crystal reports loads and runs, but it fails to load the user defined functions.  That works from a
bash prompt.   From experimentation, I know setting this registry value is necessary as running in the Cygwin
environment fails if this is not set.  It is possible, that there is something strange about .dll loading which causes
it to work in Cygwin but not on a CMD Window, but that seems unlikely.

@Echo off

set CR_HOME_DIR=C:\Program Files (x86)\Business Objects\Crystal Reports 11.5

:: Display CLASSPATH
echo CLASSPATH
echo %CLASSPATH%
echo.

:: Set and display JAVA_HOME
set JAVA_HOME=C:\Program Files (x86)\Java\jdk1.6.0_45
echo JAVA_HOME
echo %JAVA_HOME%
echo.

::  Set minimal path and add 32-bit JDK to PATH and display
set PATH=.;%JAVA_HOME%\bin
echo PATH
echo %PATH%
echo.

:: Display environment.  
set
java.exe -version
"%CR_HOME_DIR%"\crw32.exe

I am still very puzzled,

Andy Hall


> Greetings, Andy Hall!
> 
> > This is a puzzle that I have not been able to sort out despite trying all
> > sorts of variations. Basically, I maintain a bunch of Crystal Reports based
> > on Crystal reports XI R2. Sorry, I have no choice there.
> > I have this installed and running on a Widows 10 machine. How I did that is
> > another story.
> > Recently I was asked what it would take to internationalize these reports.
> > Fortunately, CR has a mechanism that allows you to define your own functions
> > that can be used in reports which  allow you to access properties files
> > containing the localized entities just as you would for a
> > normal Java app.   All well and good.
> 
> > So I set about trying to get this to work. The plugin to CR XI R2, is not
> > well integrated with the base system and a bit of not so nice manual
> > configuration is necessary.
> > You have to follow this to the letter, but that is not sufficient.
> > Out of the box I could not get it to work. So to debug what was going on I
> > wrote a simple bash script to try to get it to work.
> > Lo and behold this simple script works:
> 
> > #!/bin/bash
> 
> > echo " "
> > echo "CLASSPATH = $CLASSPATH"
> > echo " "
> > #JAVA_HOME=C":\Program Files (x86)\Java\jdk1.6.0_45"
> > echo "JAVA_HOME = $JAVA_HOME"
> > echo " "
> > echo "PATH = $PATH"
> 
> > cd "/cygdrive/c/Program Files (x86)/Business Objects/Crystal Reports 11.5"
> > java -version
> > crw32.exe
> 
> > Notice that this seem to do nothing but display some key variables and the
> > run CR in its installation directory, just as the normal shortcut does.
> > It launches CR which finds the plugin and loads it.
> 
> > Now I have a need to do the same outside of the Cygwin environment, so I
> > wrote a simple equivalent .cmd file:
> 
> > @Echo off
> 
> > :: Display CLASSPATH
> > set CLASSPATH
> 
> echo %CLASSPATH%
> 
> > :: Set and display JAVA_HOME
> > ::set JAVA_HOME=C:\Program Files (x86)\Java\jdk1.6.0_45
> > set JAVA_HOME
> 
> echo %JAVA_HOME%
> 
> > :: Add 32-bit JDK to PATH and display
> > ::set PATH=%JAVA_HOME%\bin;%PATH%
> > set PATH
> 
> Just start Java from %ProgramData%\Oracle\Java\javapath\java.exe
> In truth, it IS ALREADY in your %PATH%, if you didn't removed it.
> 
> > pushd C:\Program Files (x86)\Business Objects\Crystal Reports 11.5
> 
> CD /D "C:\Program Files (x86)\Business Objects\Crystal Reports 11.5"
> 
> > java.exe -version
> > crw32.exe
> > popd
> 
> > If I run this from a bash command prompt it works as well.  It also works
> > if I launch cmd from bash and then run the cmd
> > file.  That makes sense.
> 
> > But here is the puzzle, If I simply click on the runCR.cmd file, say from
> > the file explorer, CR launches but does not find the plugin.
> > The same happens if I launch a Windows cmd window and run the cmd file outside of Cygwin.
> 
> Then the environment is different.
> "set > file" in both CMD prompts and diff the output.
> 
> > So the question is: “What could possibly be the difference between the
> > Cygwin environment and the Windows cmd environment that makes this work in
> > one and not the other?”
> > I have examined the PATH used in the Cygwin environment and set the PATH in
> > the Windows environment to be identical. No change.
> 
> It may be some other environment variable.
> 
> > I thought it might have to do with whether or not a 32-bit or 64-bit JVM is
> > configured in the path, but that does not seem to make a difference.
> > It fails if the JVM in the path is 32-bit or 64-bit probably because CR
> > really gets its JVM from a registry setting.
> 
> > I am at a loss, Does anybody have an idea?
> 
> > BTW, I would have expected the reverse to be the case:  works in Windows but not Cygwin.
> 
> If I were you, I'd remove all Java versions and then install only one, and see
> if it works or not.
> 
> 
> --
> With best regards,
> Andrey Repin
> Sunday, March 6, 2016 00:31:40
> 
> Sorry for my terrible english...