MicrosoftWeb Server is only one aspect of VBscript. It is used elsewhere for administration and Windows Installer and other deployment projects. There are many thousands of installations and deployments for finished product, written with best-practices, that will fail if VBscript is disabled. These are used for anything from driver deployment packages to full-fledged applications and services. Many (most?) vendor deployment packages will cease to function once Microsoft decides to disable or remove VBscript. The time involved and cost to refactor all these deployment packages and applications would be in the hundreds of millions of dollars and likely exceed it. [Many authors of those packages (which have worked for decades) have moved on.]
I hear you... But MicroSoft does not. But still, it must be possible to let AI generate something like the Windows Scripting Host, solely relying on Python. The Python Scripting Host. Actually, Python IS a scripting host. The only thing we need is a VBScript to Python transpiler. ASP4 does exactly that, and it also includes the complete legacy ASP classes and often used COM libraries. I don't manage servers, so I can't really judge what's needed exactly. But I'm sure anyone who still uses VBScript for Windows administration, should perfectly be able to tell what needs to be included.
Let me be clear: the real issue is not administration, because that can be replaced by PowerShell and other scripting languages. It is thousands and thousands of Installer packages and setup deployments that are using VBscript internally. I want to be clear that VBscript is one of the recommended ways to handle these capabilities and natively supported with Windows Installer. The custom actions for these installer packages need access to the installer session handle, so VBscript engine cannot run out of process and PowerShell cannot be used. It also needs to be bound to the current Windows Installer execution phase (CLIENT (non elevated)/SERVER (elevated) mode). For Windows Installer, this mechanism is buried internally inside msiexec.exe - so there is no way for anyone besides Microsoft to change that. Whatever mechanism you propose would have to require a DLL interface that mimics existing and fully support COM/ActiveX. Since the installer can run under the current user with normal permissions or elevated and can run under the Windows Installer SYSTEM service account, it's not straightforward to partition these with an out-of-process host using an in-process DLL proxy, while maintaining separation of access.
Additionally, there's other setup and deployment programs outside of Windows Installer (MSI) technology that use direct self-hosting for VBscript. This would all have to be refactored as well for any setup EXE bootstrappers. In many cases, there is no clear alternative to their existing technology stack, so those programs would have to be completely rewritten from the ground up.
Python is not part of native Windows deployments so that would not be good to make as a dependency.
Agreed there is no other that can clone vbscript.
