The first official update for 2025 -- 7.0.1768.0 -- includes a couple of potential compatibility complications that, although discussed previously here (Wrapper functions, :outputonly) and here (DYNSTRUCT issue), are summarized here for the benefit of those updating...

1.The first issue concerns function parameters declared as :outputonly which also have default values. Way back in 6.5.1610 (compiler 829, July 2017), a change was made to the way these were compiled in order to allow for a roundabout programmer technique to be employed to determine whether an outputonly parameter was actually specified in the call to the function. The change effectively ignored the :outputonly attribute when there was a default value, effectively downgrading the meaning of the :outputonly suffix to the status of programmer documentation rather than compiler/runtime instruction. (The motivation was to avoid costly calculations within the function that only mattered if the caller was going to receive the updated parameter back, which it couldn't do if it didn't pass it in the first place. By setting the default value to something unusual, like -1, the function could use the runtime initial value as a proxy for whether the caller passed the parameter.)

Seven years on from that ill-considered decision, the downsides had become intolerable. The main downside being that programmers would take :outputonly at face value, leading to difficult-to-detect (and completely unexpected) bugs. For example, it would be reasonable to assume that the following code...
... would output the number 1 five times. But in fact it would output 1, 2, 3, 4, 5, since the return value overriding the default value on the subsequent call. (However, if the =0 was removed from the arg1 from the function parameter declaration, then it would work as expected.)

This was obviously a disaster waiting to happen, and 7.0.1768.0 (compiler 1057) fixes the problem by making :outputonly go back to living up to its name. The only reason to consider it a possible compatibility problem is if you were taking advantage of the prior behavior, either knowingly or unknowingly. If you prefer to keep things the way they've been since 6.5.1610, you can add the new ++PRAGMA OVERRIDE_OUTPUTONLY to your source code (either globally via a common include, like ashell.def, or in individual include files where you think it might be an issue). We did not add a switch to COMPIL.LIT (it seems excessively abstruse), but if anyone really wants that, we would be happy to oblige.

For those who were deliberately taking advantage of this dubious feature to test if a parameter was actually passed, you can now do that using a new function .ARG_PASSED(argno) or .ARG_PASSED(@arg). For example, we could modify the function above as follows...

Note that this issue is purely compiler related, not run-time related. So to get the benefit of the bug fix, you must recompile your code, after which it will run without any particular dependency on the run time version. Also note that when run under earlier versions, the .ARG_PASSED() function reverts to testing the inverse of the parameter's readonly status. (If readonly, then there's no point in passing a value back to it.)

2. The DYNSTRUCT issue affects only programs that use dynamic structures. Within that set of programs it only affects those with embedded defstructs. If you don't use embedded defstructs, then this won't affect you.

If you're not sure whether you're using any dynamic structures, you can search your source code (preferably via the LSX files to make sure you're getting all the relevant includes) for "DYNSTRUCT". (Like all ASB keywords, it is case INsensitive.) If you have some instances of DYNSTRUCT but aren't sure if you're using embedded defstructs, you can use VERSYS on any suspected RUN programs; the presence of embedded defstructs will appear under the Auxiliary Blocks section. For example:

The actual issue was the discovery that the embedded defstruct format with RUN programs was not completely compatible between 32 and 64 bit environments. As long as programs were compiled and run in the same environment (32 vs 64 bit), there was no problem. But a program compiled under 32 bit would abort when trying to do dynamic binding in a 64 bit environment, and vice versa. Because the 32 bit environment is still dominant (all of A-Shell/Windows and most of the A-Shell/Linux world), and because we felt that complete RUN compatibility across platforms was important enough, we decided to adjust the compiler to always generate 32 bit-compatible embedded defstructs, and the run-time system to always expect them in that format. But, since it's impossible to know whether a program compiled under 32 bit might be then distributed to a 64 bit system, or vice versa, we decided to have the latest compiler mark any program containing embedded defstructs as requiring version 1767 or higher. (That detail is also displayed by VERSYS, and is checked whenever a program is RUN.)

This will create problems for you if you start compiling programs containing embedded defstructs under the new version and distribute them to sites running an earlier version. To avoid that problem, here are two options:

• Recompile, and distribute the updated RUNs to any site previously on an older version, at the same time you update them to 7.0.1768 or higher.
• If all your sites are in the 32 bit world, since the new embedded defstruct format is the same as the old 32 bit format, existing RUN files will run under the new A-Shell without recompilation. However, recompiling will, by default, set the minimum compatible runtime version in the RUN file to 1767, making them incompatible with earlier A-Shell versions. If you want to compile under the new version but distribute the updated RUN files to sites on an older version, you'll need to prevent the compiler from marking any affected newly compiled programs as requiring 1767+. You can do that by defining a special symbol _NO_MIN_1767=1 in any affected programs, either by inserting a DEFINE in your source code, or adding the definition to your compiler command line, e.g. COMPIL MYPROG/X:2/M/PX/L/C:_NO_MIN_1767=1