Greetings ooRexx team,

Reminder of Rick's prior email...

-------- Begin Forwarded Message --------
Subject:        [Oorexx-devel] I think I've seen the future...
Date:   Sun, 22 Jan 2023 17:10:10 -0500
From:   Rick McGuire <>
Reply-To:       Open Object Rexx Developer Mailing List 
To:     Open Object Rexx Developer Mailing List 

Today in a FaceBook group I'm a member of, someone made a post about a remarkable result obtained from ChatGPT. I decided I would check it out, using a problem that I struggled with for two months, then gave up an implemented a less than optimal solution that fixed the problem but was not exactly secure.

The problem in question was the problem caused when the rexxapi daemon gpt created by a process with elevated privileges, which prevented processes with non-elevated privledges from connecting to the rexxapi daemon via the named pipe. I struggled for several months trying figure out the Windows documentation for the security APIs and a lot of time in StackOverflow trying to find some examples I could adapt. I came up empty and ended up creating the pipe with no security restrictions.

So, today I asked ChatGPT how to create a named pipe that only users of the same process could connect to. It immediately gave me a program that created the named pipe using the same code we were using at first that had the elevated permissions issues. Not what I was looking for, but impressive nonetheless.

I told ChatGPT has issues communicating between processes with elevated permissions. It agreed with me and produced a new program that I *think* might be exactly what is needed to close the security hole. I was truly amazed!

I don't know if I'm interested in fixing this myself, nor if I'll have the 
time. However, I want to post the code suggested by ChatGPT in case anyone else 
wants to adapt it to rexxapi communications.

-------- End Forwarded Message --------

Did that suggested code prototype ever make it into the ooRexx RexxAPI 
communications code base?

I am thankful,

Michael Lueck
Lueck Data Systems

Gilbert Barmwater wrote:
If the consensus is to do this, can we make a concerted effort to get the bugs and RFEs that were in 5.0.0 but were not marked as "pending" - usually as "accepted" - finally to a finished state, namely "pending"?  There has been a good amount of work on this but I'd really want to see ALL of them completed.  Thanks!

On 11/23/2023 3:51 PM, Rony G Flatscher wrote:
Dear P.O.,

fine, around end of January for planning a release of 5.1 would be fine!

Best regards


Rony G. Flatscher (mobil/e)

Am 23.11.2023 um 10:28 schrieb P.O. Jonsson <>:

 Dear Rony,

I have no preferences regarding your proposals, for me you can go ahead and 
implement them.

Regarding a 5.1.0 release I have a tight schedule from now until Christmas so a 
release in 2023 would be very hard for me to cope with. What about aiming for 
end of January?

P.O. Jonsson

Am 20.11.2023 um 11:30 schrieb Rony G. Flatscher <>:

Given some free time I would like to add the following things to ooRexx 5.1:

  * the Windows oleinfo Rexx utilities from the sandbox 
      o planned for being placed as is in a new directory 
ooRexx/samples/ole/oleinfo together with a readme.txt file
      o history: first introduced at the RexxLA symposium in 2004, cf. 
      o reasoning: many times it is very difficult, if not impossible to get at 
the published OLE interfaces of Windows COM/OLE objects including those 
returned by invocations of methods or
        fetching attribute values (they may not be registered in the registry, 
hence not discoverable); it is nice to have e.g. reference like printouts of 
the OLE interfaces (methods, attributes,

  * add the DBus support from the sandbox 
<> to 
ooRexx if the target platform has DBus support available (originally a message
    system on Linux exploited by many distributions)
      o history:
          + Flatscher R.G., "D-Bus Language Bindings for ooRexx", International Rexx 
Symposium 2011: <>
          + Margiol S., "DBusooRexx", International Rexx Symposium 2015: 
          + Flatscher R.G., LinuxCon Europe 2015: "dbusoorexx Bringing the Power of 
D-Bus to Your Fingertips"
          + Flatscher R.G., "The ooRexx DBus Bindings for Linux, MacOSX and Windows", 
International Rexx Symposium 2016: 

  * multithreading trace ("MT trace")
      o history: Jean-Louis has offered a very helpful and interesting means in 
form of a patch, that has not yet been applied; due to some discussions I had 
expected that an alternative means
        becomes available, but this has not materialized; after a couple of 
years it is time to give the ooRexx developers sound means into their hands; as 
designed Jean-Louis' version will have
        to be activated by setting an environment variable before starting the 
MT program, hence it is meant for explicitly debugging (no new MT-related trace 
options would have to be defined at all)
          + one aim when doing so is to come up with a BIF (suggestions?) that 
allows for retrieving the thread number, the activation number, the variable 
pool number and lock status, which the
            documentation of that BIF would explain: this should allow e.g. Gil 
to use this information to experiment with Rick's idea in 
non-explicit-debugging runs
              # this will cause these counters/this information to be always 
maintained, irrespectively whether  MT trace is active or not
      o reasoning: for debugging multithreaded programs it is necessary to get 
at the respective context invocation information, without it certain 
multithreaded problems cannot be analyzed/debugged

  * allow invoking the garbage collector for debugging purposes
      o history and reasoning: for debugging purposes in the context of the 
Java bridge it became necessary to make sure that the Rexx garbage collector 
ran (background: Java changed the
        finalization logics and to debug the new Java implementations for 
releasing cached Rexx objects and to test correct execution of their uninit 
methods); without a means to invoke the ooRexx
        garbage collector this is simply not possible; it is very likely that 
such debugging needs occur in other contexts where native information systems 
interacting with ooRexx (e.g. using
        ooRexx for scripts) need to be able to check/analyze/debug correct 
releases of cached ooRexx objects for debugging purposes; without such a 
function this simply cannot be achieved; as
        running the garbage collector (in every programming language) is a very 
expensive operation this needs appropriate documentation; invoking existing 
garbage collectors is possible in
        popular programming languages such as Java's java.lang.System.gc() (cf. or 
.Net/CLR's System.GC.collect() (cf.,

Any comments?


Also we should plan to release the current 5.1 version of ooRexx as soon as 
possible for at least the following reasons:

  * make the current bug fixes available in the form of an officially released 
package: many companies do not allow beta software to be installed, used, hence 
the need for a officially release if
    we want ooRexx to remain a viable option
  * make new features available like the new UTF-8 support in the 
WindowsClipboard class
  * keep the knowledge about creating releases up-to-date, allow for improving, 
maybe even fully automizing the release steps as much as possible
  * show the public that development has been going on


Oorexx-devel mailing list

Reply via email to