In general Object Rexx interpreters execute Classic Rexx code, our leading OS/2 heritage, too. So wanting to use Classic Rexx is not a reason to not use an Object Rexx interpreter. Using Object Rexx code is optional, and using object-oriented code is more likely if there's no history and you'd want to make a blue Microsoft Excel cell blink.

IIRC additional DrDialog files are the earlier DRDLGFIX.ZIP, there's a PDF version of the reference, and the documented third-party files DRCTL014.DLL upto and including DRCTL017.DLL are required by some DrDialog-based apps.

how do you see the possibility to replace OS/2 REXX library included in eCS-Warp4.52 with the open source Regina REXX

Finally a lack of relevant reactions implies that (1) you'll have to use the open source code to create an own embedded release for OS/2, and (2) you'll have to apply/document a few OS/2-specific changes (including but not limited to dealing with tokenized code, the //T argument, online help, and so on) to release a reasonably seamless version.

The existing open source code can be compiled, unlike OORexx', but it's not as easy as changing the target to a DLL. Step 2 is the hardest one. Without this step, it will not (always) work as expected. If it doesn't work as expected, then experienced users may as well skip step 1, use the existing Regina.EXE for OS/2 instead of one of IBM's REXX.DLLs, and remember the differences.

Hi all. I am working on Regina REXX integration for OS/2 in osFree project. Indeed, the REXX.DLL and REXXAPI.DLL were existed in Regina code, but they were incomplete. Also, we in osFree had our own DLL's as forwarders to REGINA.DLL, so that, you can load REXX.DLL (the interpreter itself) and use it without specifying REGINA.EXE before each script. -- You just run .cmd file and CMD.EXE passes it to REXX interpreter. But there is a problem: CMD.EXE is a 16-bit program, so it uses 16-bit REXX functions in REXX.DLL and REXXAPI.DLL, instead of 32-bit ones. But 16-bit functions were missing, as Regina is a pure 32-bit program. But, using Regina via REXX.DLL/REXXAPI.DLL is working with 32-bit shells like 4OS2. So that, Regina REXX is working with 32-bit programs, but does not work with 16-bit programs. Most notable 16-bit ones are CMD.EXE and WPS (yes, it is, for some reason, using 16-bit functions, not the 32-bit ones). So, if you install our REXX and REXXAPI, WPS won't work too and OS/2 will not start. We extended REXX.DLL and REXXAPI.DLL with some 16-bit functions as wrappers around 32-bit Regina functions, and 32-bit wrappers for CMD.EXE 16-bit subcommand handlers. So, some 16-bit programs began to work. For example, rexxtry.cmd when run in cmd.exe, and executing "CLS" command of CMD.EXE (a 16-bit subcommand handler). But another problem exists. Usually, REXX.DLL is loaded by REXXINIT.DLL, which is, in turn, loaded by PM, and keeps it loaded. REXXINIT.DLL starts thread, which listens a message queue, and serializes access from applications to REXX.DLL. So, there's another problem: Regina for now works with only one application at one time. So, we can start only one Regina client at one time. So, we need somehow serialize access to regina.dll in rexx.dll. This has to be done, too.

Also, i should note that switchrx.cmd works by swapping different versions of REXX.DLL (the interpreter) and REXXAPI.DLL (the API for extending other programs by REXX). Other DLL's are mostly usable for different interpreters. For example, REXXUTIL from Object REXX can be used with Classic REXX without problems. It has more functions implemented. Also, except for IBM's versions of REXXUTIL, exists WINDOWS version of REXXUTIL (it seems, it is called REGUTIL and is used by Regina too). But we also have two other native OS/2 REXXUTIL versions, with source code available, the one written by Mike Greene and the one supplied with eComstation.

Actually, for switching different REXX interpreters, we can suggest to rename other REXX/REXXAPI versions to CREXX/CREXXAPI and OREXX/OREXXAPI, and RREXX/RREXXAPI and make a wrapper REXX/REXXAPI with a config file, which will specify, which pair of REXX DLL's to use. I also plan to implement this in the future. This will allow to switch different interpreters without a reboot.

Making more 16-bit wrappers for regina.dll entry points will make CMD.EXE and WPS work with Regina. So, we need to finish it too.

And yes, to test our Regina REXX version, You'll need to start runworkplace=d:\os2\cmd.exe instead of d:\os2\pmshell.exe in config.sys. This will start cmd.exe instead of WPS. As we know, WPS requires more 16-bit API's implemented, and may use REXX/REXXAPI from multiple threads. So, WPS needs to be disabled. Then you can run a REXX program in cmd.exe. (This is needed temporarily, because many features are unimplemented)

Most notable 16-bit ones are CMD.EXE and WPS (yes, it is, for some reason, using 16-bit functions, not the 32-bit ones). So, if you install our REXX and REXXAPI, WPS won't work too and OS/2 will not start.

I wonder if there can be more details of where exactly is the WPS limitation, or which 16-bit functions it is using (which may be hard to find) that does not allow it to run over Regina. Is it a WPS limitation only or PM and SOM are also involved on this limitation?

The listed INF documentation is important too indeed, because a package like VX-REXX may use the INF file as "the" Rexx reference. All SWITCHRX.CMD-related files will be somehow relevant.

As mentioned earlier, PM versions like PMREGINA.EXE may have to return PMREXX with Address(). PMREXX itself is broken since a Warp 3 FP, and returns a different string. With CMD.EXE Regina's Address() doesn't return CMD.

I haven't verified the way Regina works, but it may be a new feature to disable syntax checking with an environment variable too. This would allow you to run broken (packed or tokenized) scripts, without having to patch unpatchable (packed or tokenized) scripts. SWITCHRX and Rexx SAA are an alternative for such a feature, but having to use Rexx SAA won't be a goal of a new Rexx interpreter.

Check, I don't have a Regina available at the moment: does RxMessageBox() always work, and without having to RxFuncAdd() it?

A more structured approach will be better For now it was a way to point out why having a working binary is important, an advantage compared with Open Object Rexx for Windows/Linus, but it's not as easy as just appending a REGINA.DLL to SWITCHRX.CMD. Files will be missing, results will be unexpected, and Rexx apps will stop working properly.

At the moment Regina is probably the best cross-platform interpreter of Classic Rexx, so you'ld probably use it as-is in an environment with more than one platform. Then one doesn't need a fully and perfectly embedded Rexx interpreter.