Use this snippet to discover what version of JScript you are running, change the version number up/down as needed.
/*@cc_on @*/
/*@if (@_jscript_version >= 5)
DOpus.Output('JScript version 5', '#88ff88');
@else @*/
DOpus.Output('Microsoft!', '#88ff88');
/*@end @*/
Interesting, didn't know about this variable.
But careful, JScript v5.x is still at best ES3, not JavaScript/EcmaScript/ES v5. JScript's internal versioning goes up to 5.8 but is still a Microsoft proprietary implementation of ES3 from 1999. I don't think you would have anything less than v5.6 or 5.8 even on most recent Windows machines. Hoping that DOpus devs will give us jscript9.dll or chakra.dll some time as I posted elsewhere.
For those interested in this (sorry for hijack your post galaxyhub) :
Searching for a way to use Chakra or Jscript9 in WSH, I think that I found (at least it seems so) a workaround. This is what I do:
DO NOT PROCEED IF YOU DON'T UNDERSTAND ANY OF THIS
The CLSID for the Chakra Javascript engine is :
{16d51579-a30b-4c8b-a276-0ff4dc41e755}
Check if you have this registry keys (create if you don't):
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{16d51579-a30b-4c8b-a276-0ff4dc41e755}\ProgID]
@="Chakra"
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Wow6432Node\CLSID\{16d51579-a30b-4c8b-a276-0ff4dc41e755}\ProgID]
@="Chakra"
From here, we could enable chakra with its own entry, to call it this way:
cscript.exe Version.js //E:Chakra
For that, we have to first create other entries in the registry. But since we are most interested in using with DO, and since in DO there's no way to set the engine, we're going to replace the jscript default entry. For that, search for:
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\JScript\CLSID
and change the value to {16d51579-a30b-4c8b-a276-0ff4dc41e755}
Seems you don't need to reboot for the change to take effect.
A little test in DO before the change:
And then after:
Make sure to revert the changes after you're done with testing, since it may break other things (?).
So perhaps an option in DO to select Chakra, if it's enabled as engine, to avoid replacing jscript engine would be nice.
PD: Sorry for the crappy explanation 
Update: It seems that you don't need to change HKEY_LOCAL_MACHINE\SOFTWARE\Classes\JScript\CLSID. In fact, after creating a new entry for Chakra in the registry, it appears as selectable in DO:
I made this changes :
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{16d51579-a30b-4c8b-a276-0ff4dc41e755}\ProgID]
@="Chakra"
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Wow6432Node\CLSID\{16d51579-a30b-4c8b-a276-0ff4dc41e755}\ProgID]
@="Chakra"
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Chakra]
@="JScript Language"
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Chakra\CLSID]
@="{16d51579-a30b-4c8b-a276-0ff4dc41e755}"
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Chakra\OLEScript]
(You will probably need change permissions for the first two.)
I love that you found a workaround, seems to be from this StackOverflow post (detailed information can be found there) but careful:
But I love that DOpus accepted it without obstacles, although extensive testing is needed. As I posted here both jscript9.dll & chakra.dll are apparently COM objects, what DOpus also uses. It'll be much safer for all if DOpus changed its own engine only instead of this solution, or better yet give more adventurous people like us here the option to select the engine in prefs (v5.8 or v9?), and we'd gladly give feedback about compatibility, etc.
Feel free to bug devs like I do 
Squeaky wheel gets the oil (don't kill us Leo/Jon)
Of course. It is necessary to change the ownership of certain keys (even as an admin). Not realistic for everyday use. And it is not guaranteed to be backward compatible. It's obviously not for everyone. But you have to admit that being able to do it makes it kind of fun, at least for me.
It's a holiday in my country, so I know what I'm going to do this day.
Oh I do love that it worked this easily indeed, with all the consequences obviously. I saw your edit & warning too 
By the way, if you are adventurous and serious about investing more time into DOpus script, then you should definitely also look into TypeScript transpiling to ES3. Switching to TypeScript solved almost all my headaches I had with developing with vanilla JScript, big win being much easier modularization and superior IDE support in VSC.
Just remember any script you write with an alternative version of JS may not work for anyone else, so can’t really be shared without testing on a normal Windows install.
On top of it potentially breaking anything that uses JScript scripts on your own machine, I am not sure it’s worth all the potential downsides just for a couple of small language features.
In terms of replacing the JScript version Opus uses, I think it’d be better to switch away from Microsoft’s scripting engines entirely, since they can’t be depended on to maintain anything as a platform feature (rather than “we currently use it so we’ll let you as well, but when our whims change we’ll completely abandon it because we don’t care about anyone else”). But we’ll probably only do this if we really have to as we don’t want to break all the existing scripts (unless there is really no choice).
Maybe it could be done in a way that keeps both old and new engines, with a way for scripts to signal which they want. Possibly in the future, but we have too much else to do at the moment to start on that (and honestly don’t find slight differences in JS versions that exciting for the small scripts used in Opus that don’t need fancy language features).
How about a comment at the top of the script
/// dopus_js_9
// or
/// dopus_js_5
/* rest of script */
and this would be not only eslint, tsc, etc. compatible, but also scripts could be easily tested with old or new engine? Super easy, super visible.
My thoughts on future-safe language choices are summarized in the 2nd last link above.
Other programming languages are using the keyword pragma, starting with e.g. ##javascript9 to control the compiler behaviour or to dismiss warnings.
Perhaps this is another way?
No rush, Leo. And you're right. Just seeing the requests from some people (TBH, I don't see the benefit outweighing the cost either), I wondered if there might be a way to make it possible, so take it as just another "proof of concept" rather than me encouraging all users to change their registry.
I imagine that if in future versions, a new scripting language independent of WSH were added (without replacing the existing ones), and its use were encouraged, eventually JScript scripts would likely migrate or be phased out (eg. you don't see VBScript scripts these days).
Please no special keywords that ESlint and TSC cannot parse, or at least with triple slash directives style like TypeScript uses in front, they do not cause any parsing problems in external editors.
/// ##javascript9
is super safe, too.
##javascript9 // instant parsing problem in VSC
So you are coding JScript in Visual Studio Code when writing some lines for DO? Just interested...
Well, "some lines" is an understatement
My (more popular) MediaInfo & (unpublished) multi-threaded hash scripts are both ~5k lines of untranspiled code; the movie management script I'm working on is >15k in TypeScript. The DOpus helpers ts file is >9k, prob over 10k once I incorporate all the v13 changes.
My question was not meant to discredit your work, not at all, just out of interest if you could code for DO in VSC, using all of DOs own JS objects.
So no offense in any way 
Out of curiosity, has anyone actually tried making the changes? Because besides showing the correct version, it doesn't seem like it's really using Chakra.
No worries, no offense taken
Yes, I do use VSC almost for anything more than 30 lines of code, I rarely store anything in buttons, but in.js files. especially so I can reuse the commands or logic.
See:
^ This 2nd one has fundamentally changed how I code for DOpus. First time you open any old script in VSC, the warning might be overwhelming, but I'll never go back.
Not me, I stoped at the Regedit error, but tested only this to verify your findings:
// run with cscript.exe test.js //E:{16d51579-a30b-4c8b-a276-0ff4dc41e755}
WScript.Echo(GetScriptEngineInfo());
function GetScriptEngineInfo()
{
var s= "";
s += ScriptEngine() + " Version ";
s += ScriptEngineMajorVersion() + ".";
s += ScriptEngineMinorVersion() + ".";
s += ScriptEngineBuildVersion();
return(s);
}I mean trying within DO.
Selecting Chakra in Script Type, that will show the correct version (11.xx in my case).
But using other post ES3 stuff won't. Interesting.