Thank you, that seems to be a reasonable explanation! o)
Kind of wild that there are new things to learn and discover every day and no end in sight! o)
What values does this JSCRIPTVER accept? Does "11" make any sense?
I searched the docs, no appearance of JSCRIPTVER so far.
The DOpus directive seems to accept any values, and since 3 was mentioned in the 13.12 release notes, I thought 11 (corresponding to Windows JScript engine version, not ES*) might make sense, but apparently it does not. Apart from the values 1 & 2 in Jon's screenshot, Windows probabaly treats anything >= 3, like 3, 4, 11, 129... the same (please test).
*: In another thread a poster mentioned Win11 is ES2024-compliant now, which is kinda misleading, but there is another 100% wrong statement in that post: JScript/WSH v5 is not ES v5 aka ES 2009, but demonstrably Microsoft's own version of ES3 (I have posts about this: 1, 2).
In my tests it (e.g. Win11 24H2) simply does not even support ES5, with or without JSCRIPTVER=3, 5, 20, 150.. Again, apart from very few trivial additions in Win11, we're still stuck with ~ES3.
There is, however, a newer JScript engine in Windows, which inded supports at least ES 9/2018, but that the devs probably overlooked it.
I don't think it's an easy task. I wonder if it could be done via a plugin, perhaps?
I mean, is it even technically feasible?
DOpus plugin SDK exposes a lot of low-level API, but it might not be possible to replace the DOpus JScript interface to old JScript engine with another with the SDK. Probably a dead-end there.
There might be other alternatives using a custom plugin which handles a new extension, like .jsx or .djs, and calls DOpus scripting API for anything which isn't standard JScript but afaik there's no SDK method which allows calling DOpus scripting API from such a plugin. So that's a dead-end too.
You can add languages to ActiveScripting, so someone could make an actual JavaScript (as opposed to JScript) language if they wanted to. It's probably a lot of work, although I've never looked into it myself.
Any ActiveScripting language will be available within Opus (as well as within WScript/CScript etc.).
There is a group policy that can be changed on the system which will allow applications to use the old JScript engine and work around this issue.( for me )
- Launch the (Windows) Group Policy Editor application
- Browse to Local Computer Policy > Computer Configuration >Administrative Template > Windows Components > Internet Explorer once the application is launched
- Set the policy Replace JScript by loading JScript9Legacy in place of JScript to Disabled (it is not configured by default, which is the equivalent of Enabled)
- Apply and close all group policy windows
1 Like
That's what you get if you set JSCRIPTVER=3 as far as I know.
There is also a COM Classic version of Chakra internally called "JScript 9 Legacy" (provided by jscript9Legacy.dll), introduced with Windows 11 24H2, which brings back compatibility with Active Scripting hosts and intended as a compatible drop-in replacement for JScript 5.8
jscript9Legacy.dll is what is used now on Windows 11 24H2 (we see it causing crashes in dump files).
If you set JSCRIPTVER=3 then this kicks it into another mode where things like String.trim() work. So based on the wikipedia article I'd say this represents the most recent development on Chakra before they dropped their own version in favor of Chrome.
- On Windows 11 24H2, by default you get JScript 5.8 compatible
- Setting the version number to 3 enables newer features (but it's still not that new).
Unfortunately it doesn't, even if the new .dll might be used; as I wrote above JSCRIPTVER=3 does not support basic ES 5 classes nor ES6 ()=>, let alone ES 9. Upon reading the Wikipedia page on Chakra again, it states:
It requires a specific Microsoft JavaScript Hosting (JsRT) API for proper use. Therefore, it is installed side by side with JScript 5.x and is only used by Internet Explorer 9 and later as well as JsRT hosts, while other Active Scripting hosts keep using the 5.x version when requesting the JScript engine.
That is apparently why the scripts get stuck at ES3 version. I was probably mistaken that this engine was COM-based, or the info is added later. The whole spiel using the same name for entirely different versions is very confusing. If you'd consider looking into this JsRT API in the future, that'd be awesome though. Even ES9 is a huge jump from current state.
Yes but the wikipedia page then goes on to say the COM Classic version of Chakra was introduced in Windows 11 24H2 which is what we're now dealing with.
It doesn't really make sense that they'd have a later version of Chakra but only expose an earlier version via COM, if they're going to the trouble of adding COM compatibility.
No way to really know though as this is all guesswork, even the wikipedia page is really just guessing.
Presumably Microsoft stopped development on Chakra when they switched to using Chrome for Edge, so I'm not sure there'd be any benefit in looking into it given:
- there's no evidence there's a "later" version of Chakra that's just sitting there unused
- even if there was, development stopped on it in 2018 and so it won't have the latest features anyway
2 Likes
Thanks for the clarification. Once put in context, I understand why you did that (it was just not mentioned in the initial post here).
FWIW, you can check the code behind this :
This is how I did it (it does use .caller ... but also toString 
) but might not be that far from what you did too ...
It is used in a logger function so when calling the log function you don't need to mention the function (caller) and it is automatically mentioned in the log.
this.GetCaller = function() {
try { return arguments.callee.caller.caller.toString().match(/function\s+([^\s\(]+)/)[1]; }
catch (e) { return "<<Unknown caller function>>"; }
};
EDIT : This is in response to @cyilmaz clarification on the reasons of the function ... toString().
1 Like