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.

---rony

P.S.: If possible for the developers, maybe you could remove patch
<https://sourceforge.net/p/oorexx/patches/209/> 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: <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

Reply via email to