SCRIPT makes TCC disappear.

[vefatica]

This script works (to get the timestamp of https://jpsoft.com/downloads/v28/tcmd.exe).

v:\> ifiletime.vbs
Sun, 21 Nov 2021 20:18:22 GMT

Both of these make TCC disappear (at least back to v24).

script ifiletime.vbs
script /e VBScript ifiletime.vbs

It's a stack buffer overrun in NTDLL.DLL. I have a .DMP file if it'll help.

Here's the script.

'ifiletime.vbs
Dim h
Dim lastmod
Set h = CreateObject("MSXML2.ServerXMLHTTP")
    h.Open "HEAD", "https://jpsoft.com/downloads/v28/tcmd.exe", False
    h.send
    lastmod = h.getResponseHeader("Last-Modified")
WScript.Echo(lastmod)

 

[rconn]

SCRIPT hasn't changed in at least 5 years.

Do you have other scripts that *do* work with SCRIPT, or does everything fail?

 

[rconn]

100% a Windows bug - it's crashing inside the Windows IActiveScript code (after that code helpfully removes the TCC exception handler to ensure that the app will crash).

 

[vefatica]

I have a few others, all VBS. They also fail similarly.

 

[Joe Caverly]

Hi @vefatica,

@rconn says "SCRIPT is pretty much obsolete; Microsoft has abandoned the technology."

All of the COM objects that I have written work with SCRIPT, but a few of the Microsoft COM Objects do not. In your script, the problem is the MSXML2.ServerXMLHTTP object.

Try running your .vbs script in TCC 18 or earlier, and it should work.

Fortunately, PowerShell does not have this problem;

r:\>type ifiletime.ps1
$h = new-object -com "MSXML2.ServerXMLHTTP"
$h.Open("HEAD", "https://jpsoft.com/downloads/v28/tcmd.exe")
$h.send()
$lastmod = $h.getresponseheader("Last-Modified")
$lastmod

r:\>pshell ifiletime.ps1
Sun, 21 Nov 2021 20:18:22 GMT

Joe

 

[Joe Caverly]

In my PowerShell Profile, I have the following;

function CreateObject($progID)
 {
     new-object -com $progID
 }

This emulates the VBScript CreateObject, so my PowerShell code can now look like;

$h = CreateObject("MSXML2.ServerXMLHTTP")
$h.Open("HEAD", "https://jpsoft.com/downloads/v28/tcmd.exe")
$h.send()
$lastmod = $h.getresponseheader("Last-Modified")
$lastmod

Joe

 

[vefatica]

I can only try v18 in Windows 7. There I get this.

\\jj\v$\ifiletime.vbs(6, 5) msxml3.dll: An error occurred in the secure channel support

 

[vefatica]

100% a Windows bug - it's crashing inside the Windows IActiveScript code (after that code helpfully removes the TCC exception handler to ensure that the app will crash).

Well, I don't know much about it. CSCRIPT.EXE and WSCRIPT.EXE do OK. Do they use the same technology?

 

[Joe Caverly]

Hi @vefatica,
No, CSCRIPT.EXE and WSCRIPT.EXE are their own engines, just like the SCRIPT command in TCC is its own engine.

Microsoft has kept CSCRIPT.EXE and WSCRIPT.EXE updated and working in Windows 10;

Thus, CSCRIPT/WSCRIPT are the ways to run .vbs files in TCC, especially if you are using any COM object.

If you are doing non-COM object scripting, SCRIPT should run them with no problems.

Joe

 

[vefatica]

I guess I can run TCCv18 ... directly from its home on the remote machine. There, script ifiletime.vbs gives this.

and wscript //h:cscript ifiletime.vbs gives

 

[Joe Caverly]

Hi @vefatica,
I tried running the ifiletime.vbs script in TCC 15 under Windows XP, and it returned;

[R:\]ver

TCC  15.01.40   Windows XP [Version 5.1.2600]

[R:\]cscript ifiletime.vbs
Microsoft (R) Windows Script Host Version 5.7
Copyright (C) Microsoft Corporation. All rights reserved.

R:\ifiletime.vbs(6, 1) msxml3.dll: The message received was unexpected or badly formatted.

Joe

 

[vefatica]

No, CSCRIPT.EXE and WSCRIPT.EXE are their own engines, just like the SCRIPT command in TCC is its own engine.

I don't understand. CSCRIPT.EXE and WSCRIPT.EXE are appealing to some engine (right?). Doesn't TCC's SCRIPT do the same thing?

 

[Joe Caverly]

Hey @vefatica,
WScript.Echo does not work with the SCRIPT command. It can't, as it has no idea what WScript means, since that only works with the CSCRIPT/WSCRIPT engines.

Instead, try using;

TakeCommand.tcommand("echo whatever")

Thus, CSCRIPT/WSCRIPT have no idea what TakeCommand.tcommand means, as that is only in the engine for the SCRIPT command.

Joe

 

[Joe Caverly]

Hey again,
CSCRIPT.EXE is its own engine.
WSCRIPT.EXE is its own engine.
SCRIPT is its own engine.

These each have their own Active Script engines.

Joe

 

[vefatica]

Hey again,
CSCRIPT.EXE is its own engine.
WSCRIPT.EXE is its own engine.
SCRIPT is its own engine.

These each have their own Active Script engines.

Joe

I still don't understand (but that's OK). Why do all three have an option to specify the engine?

 

[Joe Caverly]

Found this text in the Active Scripting Wikipedia Page;

The third-party shell Take Command can, as of version 10, be configured for direct interoperability with the script host and its installed engines; a WSH engine based on the Take Command language is reportedly now in development.

Joe

 

[Joe Caverly]

I still don't understand (but that's OK). Why do all three have an option to specify the engine?

There are many script engines.

VBScript, JScript, Perl, Python, Fortran, etc.

VBScript is the default.

I think the confusion might be in my terminology, as I have always referred to them as engines.

The interfaces to Active Scripting engines are public, so any developer can create applications that are programmable in Active Scripting languages as well as engines for additional languages.

Joe