Hmm, it seems that I have not clearly communicated why the problem cannot be 
solved reliably by
third party libraries.

The problem surfaced first in the Java environment: here the Java scripting 
framework expects
scripts to be stored as text only, such that reading script code automatically 
causes code page
translations to be applied (cannot be inhibited). If a script is a rexxc 
compiled Rexx package, then
the automatic codepage translation destroys the script's code!

A solution would be to encode the rexxc compiled image with base64, which makes 
the text immune to
codepage translations. However, currently a base64 encoded rexxc compiled image 
makes it
incompatible with the ooRexx interpreter causing a Rexx runtime error.

Hence the idea that a library like BSF4ooRexx would need to decode such a 
program before handling it
over to the Rexx interpreter, which appears to be reasonable at first.

However, take a larger ooRexx written application that consists of different 
ooRexx modules,
mod1.rex, mod2.rex, ..., which can run standalone, but also in concert of a 
larger application, that
runs them, calling/requiring mod1.rex, mod2.rex,....

While a third party library could decode mod1.rex, mod2.rex, ..., this is not 
possible if these
modules get called/required by a running Rexx program!

Currently, this situation cannot be handled by third party libraries, only by 
the ooRexx interpreter
(being the ultimate central location for executing code).

So there are are three possibilities:

 1. the interpreter gains the ability to handle base64 encoded compiled Rexx 
programs: any
    combination of executing Rexx code (source code, rexxc compiled code, 
base64 rexxc compiled
    code); codepage translations cannot hamper ooRexx programs (this is what 
patch [1] does),

 2. the interpreter allows for a new hook, where third party libraries can 
inspect the Rexx code to
    be run, and if a base64 encoded rexxc compiled program in hand, it will 
decode the base64
    encoded rexxc program before handing it over to the ooRexx interpreter,

 3. keep the current state: rexxc compiled code cannot be run reliably in 
environments that
    code-page translate the (raw) rexxc compiled Rexx program, thereby 
destroying the code.


I have created and tested a patch in [1] which solves the problem. The patch 
can be applied to
ooRexx on trunk, such that possibility # 1 above gets realized by it.

If there was a hook for possibility # 2, I would take advantage of it and 
implement the patch in
BSF4ooRexx. (In this case the refactoring of RoutineClass.cpp in [1] could 
still be applied to
ooRexx to move all rexxc-related code into ProgramMetaData.{c|h}pp where Rexx 
compiled code gets

If neither possibility # 1 nor possibilty # 2 is made available, then the patch 
may still proof
helpful for companies developing complex ooRexx applications with rexxc 
compiled packages: in this
case any ooRexx application provider could apply the patch to ooRexx and create 
a private version of
ooRexx to be distributed with their ooRexx application.

The preferable solution would be # 1 as it would solve the problem once and 
forever, also for other
libraries (being potentially faced with running under an environment that does 
code page
translations on scripts).


[1] Patch # 209: <>; there is an 
accompanying ooRexx
script that carries out the base64 encoding (and allows for inspecting rexxc 
compiled scripts).

Oorexx-devel mailing list

Reply via email to