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.

[steph78630]

Thank you for your clarification.

Therefore, if the engine is disabled, the compilation with ScriptCryptor will fail.

But what about running the compiled file on a machine where the engine is disabled ?

Is the problem the same, or does the file run correctly on its own ?

This clarification seems important to me because it allows compilation with ScriptCryptor :

> From a machine with the engine enabled or an older machine (for eg. Windows 10 or Windows 7)
> While allowing the compiled file to run on all newer machines (for eg. Windows 11 - 25H2 and later versions)

[support]

Compilation itself doesn't require an engine; the compiler simply adds the necessary objects to the executable.

A significant portion of the runtime code remains within the scripting engine. Partial functionality may be retained, but restoring full functionality will likely be difficult.

[steph78630]

Can you clarify what you mean by "Compilation itself doesn't require an engine" ?

During compilation, the chosen scripting engine (cscript or wscript) is retrieved from C:\Windows\System32 by ScriptCryptor and then integrated into the compiled file being created.

So, if I understand correctly, if cscript.exe and wscript.exe are removed from the Windows source code in the future, I don't see how the compiler will continue to function.

[support]

No, the engine is not integrated into the executable during compilation. The system engine is always used during program execution.

Everything will depend on which interfaces and objects remain accessible after the engines are removed from the system. For example, Scripting.FileSystemObject and Scripting.Dictionary...