Apparently 22H2 replaced the JScript engine with a new version that has a few differences from the previous one.
(I haven't found any official Microsoft documentation of this, which isn't surprising, but this thread has some details: Windows 11 22H2 has a different way of using the JS engine? - Microsoft Q&A)
I'm not sure if or how much any of these changes will affect Opus.
Clearly Microsoft are still making changes, since 24H2 introduced a problem that stopped multiple include files working (we have a workaround that for the next release).
Basically, keep an eye out for weird differences with JScript on Windows 11. There's probably not much that can be done about some of them since Microsoft are not especially responsive to bug reports, but at least we'll be aware of the issue.
Indeed, JScript (COM Classic) 5.8 has apparently been replaced by a version of Chakra reworked to be compatible with Active Scripting hosts.
Unfortunately, it is not fully compatible. For example, the new engine does not support conditional compilation, and does not support setting an object to a global object property. (when a named object from the host is added as
SCRIPTITEM_GLOBALMEMBERSand one of its property supportspropputrefto assign an object as its value.I suspect the idea is to take advantage of Chakra to improve the security of the JScript COM Classic engine, and while that is much better news than dropping JScript like VBScript, a bit more work is needed to ensure full compatibility with the previous engine.
Another compatibility bug found in the new JScript legacy engine:
The original JScript (COM Classic) engine supported calling
newon an object, it would invokeDISPID_VALUEthrough itsIDispatchEx::InvokeExmethod with theDISPATCH_CONSTRUCTflag.The new engine fails with a
0x800A01C0"Named argument not found" error.
And another compatibility bug in the new JScript legacy engine:
VT_I8 and VT_UI8 (64-bit signed and unsigned integers) were kept as it in JScript, handled as opaque "unknown" types that could be passed around between COM objects.
In the new engine, those values are automatically coerced into Numbers (VT_R8), and lose their precision.For example, an object could return a VT_I8, you could store it in a JScript variable, and pass it to another object's method, keeping the 64-bit integer precision.
Now, they will be converted to VT_R8 (Number/Double/binary64) when received by JScript, and will therefore lose precision (as the mantissa is only 53 bits, not 64).This makes it impossible to reliably pass around 64-bit integers when using JScript as a glue language between COM objects.