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 Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel