As ooRexx has gained this ability (kudos go to Rick, who put implemented a 
complete solution
including a rexxc option), please do not use the mentioned patch # 209 at all!

If you have a need to have the compiled Rexx program encoded, then use the new 
rexxc option "-e"
(trailing switch), tested with the latest version, revision 11896.


P.S.: If possible for the developers, maybe you could remove patch
<> altogether or mark it somehow 
as outdated?

On 05.07.2019 14:05, Rony G. Flatscher wrote:
> 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: <>; 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