Future compatibility of ScriptCryptor with Windows 11 (24H2 / 25H2 and beyond)

[steph78630]

Hello,

I’m currently using ScriptCryptor to compile my VBScript code into standalone EXE files. I read on your website that ScriptCryptor includes its own runtime and does not depend on wscript.exe or cscript.exe, which is great.

However, I’d like to clarify a few critical points regarding long-term compatibility with future versions of Windows :

Since Microsoft announced that VBScript.dll will be completely removed starting with Windows 11 version 25H2, can you confirm that ScriptCryptor-compiled executables will still run without issues (because they don’t rely on the system’s VBScript engine) ?

Does ScriptCryptor rely on any other Windows components that might be deprecated or removed in the future (e.g. WMIC has already been retired, but WMI remains) ?

If my scripts use COM objects such as WScript.Shell, Scripting.Dictionary, or WMI via GetObject("winmgmts:..."), am I correct in assuming these calls still depend on Windows system components, and therefore the only risk of incompatibility would come from Microsoft itself removing or modifying those COM/WMI services ?

Is there any official roadmap or guarantee of continued compatibility of ScriptCryptor executables with Windows 11 24H2 / 25H2 and beyond ?

I just want to make sure that the applications I distribute today will remain functional in the next major releases of Windows, without having to migrate everything to PowerShell.

Thanks in advance for your clarification !

Best regards,
Stephane

[support]

Unfortunately, once VBS support is completely removed from Windows in 2027, we won't be able to provide full scripting support.

[steph78630]

Hi support team,

I just performed some tests:

On Windows 11 25H2, I moved the two files cscript.exe and wscript.exe from the C:\Windows\system32\ folder using a Linux tool, while Windows was offline (since Windows prevents this move when it is running)...

I ran your ScriptCryptor compiler, which asks me for the script engine path (since it can no longer find it in C:\Windows\system32).

Using ScriptCryptor's Browse... function, I selected the new script engine path (for example, D:\cscript.exe).

> My myscript.vbs file is correctly compiled and works, but unfortunately, the compiled file overwrites the selected script engine file (myscript.vbs becomes cscript.exe).

To ensure your compiler works even in future versions of Windows, after 2027 and behond :

1 - Integrate the two scripting engines files into your application's installation folder, or automatically search the scripting engine files in the ScriptCryptor application's folder if it's not found in C:\Windows\system32\ (this will allow the user to manually add script engines files to this folder if needed)

2 - Fix the action that overwrites the scripting engine file during compilation.

Best regards, Stéphane

[support]

That's not exactly how it works. Cscript.exe/Wscript.exe is simply a frontend for the script engine, and Windows is asking where to find it. If the engine itself is disabled, the compiled file will fail with an error. You can check this yourself by going to "Settings -> System -> Optional Features -> View or edit optional features" and removing VBSCRIPT from the list.