On 21.10.2025 00:18, dominic wise wrote:
I’m not going to lie – the changes to command line processing for REXX.EXE on Windows make me
somewhat nervous given the number of processes I’ve written over the years that are Rexx programs
called in different scenarios including from batch files. I have found subtle oddities from time
to time but have been able to work around them. If there are any changes in behaviour to
command-line processing I fear that things may stop working due to these changes
Does anyone recall the history of this code and why this difference exists between Unix(-like) and
Windows? I can see that GetCommandLine and custom parsing is absolutely required for
REXXHIDE.EXE since this is not a console program so has the WinMain entry point and no argc/argv
pair; likewise for OODIALOG.EXE. Was it included in REXX.EXE for consistency of code (or
behaviour between the REXX/REXXHIDE/OODIALOG triad) or for some other reason ?
Currently I did not touch/change rexxhide/rexxpaws.
What is the level of confidence that there are not going to be regressions,
even subtle ones ?
None, that was the reason why I asked.
Not having received any feedback I thought it is worth a try as it also would simplify things (being
a big fan of the KISS principle) and see how the tests do in the hands of Rexx users using this
version of rexx.exe.
:)
Seeing Jean Louis' and now your postings make me think to let
common\platform\windows\ArgumentParser.h in place.
Furthermore, the question then would be to incorporate Jean Louis' WIP into the loader which would
mean that Rexx would start to do code page translations, which might have also an impact to your
programs (this also would affect ooDialog for which there is a Unicode version by Jean Louis; AFAIK
the current used version of ooDialog got changed quite a bit since the Unicode version, such that I
fear that there would be a lot of work necessary to get the currently distributed version of
ooDialog to full Unicode support, but I may be wrong)? What would be the thoughts for this?
Does the automated test suite have extensive coverage for diverse command line
tests ?
Not that I know of.
Speaking as a concerned *heavy* user of mixed batch / Rexx command processing 😊
Thank you (seriously!) for speaking out!
One principle that is important for ooRexx, I believe, is to keep the language backwardly compatible
as much as possible (that is the reason why 30 or more years old Rexx programs still run unchanged
on ooRexx). Even if this means that one needs to continue to carry around something that may look
like kludge to some, but is not seen by users.
So, may I ask you to check out this version for incompatibilites. Also, if you find any, could you
maybe create test units such that we can test for these automatically for all future versions of
ooRexx? At this point it is not difficult (just a little cumbersome) to return to using
ArgumentParser.h for the Windows version. Again, ooRexx should remain backwardly compatible as much
as possible, so this is well invested time.
---rony
P.S.: Will wait a few days to see further feedback and test results. In the meantime I will try to
complete the documentation (rexxref).
On Mon, 20 Oct 2025, 21:21 Rony G. Flatscher, <[email protected]> wrote:
Bonsoir Jean Louis,
thank you very much for sharing these very interesting pointers and these
valuable insights
with respect to codepage/Unicode handling in Windows and how to allow to
use UTF-8 properly on
Windows!
This also brings up the desire to get full Unicode support into ooRexx for
supporting all the
non-English languages there are in the world!
---rony
P.S.: Ad turning a command line into C-like arrays and vice versa:
* commandline: arguments enquoted in double quotes, even if they contain
whitespace,
constitute a single argument (which needs to have the enclosing double
quotes removed, as
they are not part of the argument value itself),
* C-like array: creating a Rexx command line would blank concatenate all
the arguments; if
an argument includes whitespace it needs to be enquoted in double
quotes for the command line.
On 20.10.2025 17:41, Jean Louis Faucher wrote:
On 10/20/2025 8:08 AM, Rony G. Flatscher wrote:
Would there be anything lost function-wise if I were to change
Windows' rexx.cpp
to match the Unix' rexx.cpp and forgo GetCommandLine() and
ArgumentParser.h
altogether?
I can't answer to your question but it's an opportunity to share an
abandoned WIP.
Abandonned because:
* We recommend enabling UTF-8 beta support in Windows
* Correctly handling console codepage when getting arguments could
introduce regressions
A few weeks ago, I had a look at the management of arguments under
Windows because of that:
CLI arguments under windows
<https://github.com/jlfaucher/executor/blob/73aae6adefc65601a85fb1b8ac8224818a273ef3/sandbox/jlf/_notes.txt#L1886-L1910>
I wrote a test program args-windows.c
<https://github.com/jlfaucher/executor/blob/master/sandbox/jlf/internals/notes/args-windows.c>
to
explore 3 cases:
// 1: similar to rexx
// 2: wmain (new)
// 3: similar to rexxhide (no console)
The selection of the test case is made like that:
#define MAIN 2
Easy to build:
cl args-windows.c Shell32.lib User32.lib
The output shows that it's possible to have a correct support of UTF-8
for the test cases
1 and 2.
*chcp 65001*
*rexx -e "say 'Père Noël **🎅**'"*
P�re No�l ??
*args-windows.exe -e "say 'Père Noël **🎅**'"*
*Test case 1 and 2:*
0 : args-windows.exe
61 72 67 73 2d 77 69 6e 64 6f 77 73 2e 65 78 65
1 : -e
2d 65
2 : say 'Père Noël 🎅'
73 61 79 20 27 50 c3 a8 72 65 20 4e 6f c3 ab 6c 20 f0 9f 8e 85 27
*Test case 3:*
The UTF-8 bytes are not displayed correctly by MessageBox because I use the
"A" version.
If the "W" version was used, and the UTF-8 was converted to UTF-16 then
the display would
be correct (well, not sure for the emoji).
Tested with a modified RxMessageBox that takes an optional code page.
Must be tested with a file, not from the CLI, because of the arguments
conversion problem.
*file.rex* (encoded UTF-8)
*call RxMessageBox 'Père Noël **🎅**', 'Title', /*button*/, /*icon*/,
/*other*/, 65001*
(end of file)
*rexx file.rex*
Don't know why the emoji is like that.
Maybe a font problem, not worth investigating.
Patch not proposed because adding a code page to RxMessageBox seems
like an endless
workaround (already added to clipboard methods).
If 65001 is not provided then it's the current implementation
_______________________________________________
Oorexx-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
