On 10/21/2025 3:38 AM, Rony G. Flatscher wrote:
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 do not recall the history, it was before my time 🙂. But, in thinking
about it, I suspect it may be related to the Windows support for
file/path names containing blanks. The shell program, CMD.EXE, does
some not-so-simple things with the command line when it contains
double-quotes. In some cases they are removed and in other cases they
aren't 🙁.
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.
Some early thoughts (before I have had time to actually try them) for
tests: double-quotes around the program name (e.g. rexx "my pgm.rex") w/
and w/o arguments; rexx "c:\program files\oorexx\rexxtry.rex"; rexx -e
"say hi!";
other tests with quoted filenames as arguments. These are obviously
Windows tests. Hopefully, I will have time later to test these tests
(!) later and post the results.
---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
--
Gil Barmwater
_______________________________________________
Oorexx-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
