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
handled.)
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).
---rony
[1] Patch # 209: <https://sourceforge.net/p/oorexx/patches/209/>; there is an
accompanying ooRexx
script that carries out the base64 encoding (and allows for inspecting rexxc
compiled scripts).
_______________________________________________
Oorexx-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
