Menu
▾
▴
#696 Backwards compatibility problems with rexx.h
I downloaded ooRexx 4.0.0 build 4702 and attempted to build THE with it on ubuntu 8.10.
What follows are presumably some of the errors in the old, SAA API header file, rexx.h.
Presumably, because I've only spent about 10 minutes looking at the ooRexx 4.0.0 rexx.h,
and compared it to the ooRexx 3.2.0 rexx.h (for Linux), and the Regina and Rexx/Trans
equivalent rexxsaa.h.
1) All the tyedefs for types such as LONG, ULONG, CHAR, PSZ etc have been removed. This breaks any
Rexx application that uses these typedefs to ensure that the types in the user program are the
same as in the API.
2) The typedefs for RexxFunctionHandler, RexxSubcomHandler, RexxExitHandler have also been removed.
See comment in point 1.
3) The REXXDATETIME structure is missing the item; "valid", the last item in the structure that
was present in the 3.2.0 rexx.h. This will cause binary incompatibility under 32bit platforms
if a Rexx application or external function package uses Rexx/Trans to provide interpreter
independence.
4) There is inconsistency in the way the type of fields in some structures has been converted:
(Please note that this has not been tested or confirmed, but certainly appears to be the case)
eg. in SHVBLOCK, the shvnamelen was a ULONG (unsigned long) in 3.2.0. In 4.0.0 it is now a size_t.
in REXXDATETIME, the microseconds field was ULONG (unsigned long) in 3.2.0 and it is now unint32_t.
This means that on the 64bit platform, one of the ULONGs in 64bit, and the other ULONG is 32bit.
Due to this the 64bit version of ooRexx will not be binary compatible with other Rexx interpreters,
principally Regina on 64bit platforms which will not allow users to use Rexx/Trans on 64bit platforms.
I can see the desire to remove the old OS/2 typedefs from the new ooRexx 4.0.0 API files, but the point of
retaining the old, SAA API is to provide backwards compatibilty. This has not been achieved in build 4702
of ooRexx 4.0.0.
Cheers, Mark
Related
Discussion
Anonymous
The only portion of this getting fixed is the definition for RexxFunctionHandler, which had been inadvertently renamed to RexxRoutineHandler for consistency with other usage. Both names are now being supported.
1) The old OS/2 types were highly problematical to continue supporting because they do not behave consistently when making the transition from 32-bit to 64-bit on all platforms. On Windows, ULONGs remain 32-bit, but in many of the locations where ULONGS are currently used the values need to expand to 64-bit. On Unix systems, these values expand the way we wished.
To correct this problem, the APIs have been fixed up to use the ANSI defined portable types and the mappings were made based on what the requirements for the fields were on a case-by-case basis. Thus all lengths became size_t, while the time fields were fixed at the 32-bit level.
2) RexxFunctionHandler has been inadvertently rename to RexxRoutiineHandler. The others are still in the new include file.
3) The REXXDATETIME structure was already inherently non-portable, since the Windows version did not use that structure, but rather a platform-specific structure. The valid field actually had no meaning in that structure and inappropriately exposed internal implementation details in the API. The new structure is more appropriate for API uses.
4) The new types were chosen with values that 1) maintained binary compatibility with existing ooRexx programs on 32-bit systems (the only ones supported), and 2) were appropriate for the usage.
The result of the changes to the old SAA API force the developer to make changes to their code, to support ooRexx 4.0.0 and makes it difficult to support multiple interpreters. Personally I consider this breakage and certainly does not encourage me to support ooRexx 4.0.0 for the products that currently use it. I also consider it contrary to the stated Mission; (number 3) of the ooRexx project.
On 64bit platforms a developer will also be forced to provide support for Regina or ooRexx at build time rather than at runtime as could be the case if they chose to use Rexx/Trans. This removes choice for users of Rexx on 64bit platforms.
If I understand correctly, and this means that add-ons that require RexxTrans would no longer be supportable this would prevent me migrating to 4.0.
I am thinking particularly of Rexx\SQL which is at the heart of most of my applications.
Jon
The fix for this item was in the 4.0.0 release.