SCRIPT makes TCC disappear.

May 20, 2008
11,853
121
Syracuse, NY, USA
This script works (to get the timestamp of https://jpsoft.com/downloads/v28/tcmd.exe).

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

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

Code:
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.

Code:
'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)
 
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;
Code:
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
 
In my PowerShell Profile, I have the following;
Code:
function CreateObject($progID)
 {
     new-object -com $progID
 }

This emulates the VBScript CreateObject, so my PowerShell code can now look like;
Code:
$h = CreateObject("MSXML2.ServerXMLHTTP")
$h.Open("HEAD", "https://jpsoft.com/downloads/v28/tcmd.exe")
$h.send()
$lastmod = $h.getresponseheader("Last-Modified")
$lastmod

Joe
 
May 20, 2008
11,853
121
Syracuse, NY, USA
I can only try v18 in Windows 7. There I get this.

Code:
\\jj\v$\ifiletime.vbs(6, 5) msxml3.dll: An error occurred in the secure channel support
 
May 20, 2008
11,853
121
Syracuse, NY, USA
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?
 
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;

1637795618108.png


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
 
May 20, 2008
11,853
121
Syracuse, NY, USA
I guess I can run TCCv18 ... directly from its home on the remote machine. There, script ifiletime.vbs gives this.

1637795683652.png


and wscript //h:cscript ifiletime.vbs gives

1637795787581.png
 
Hi @vefatica,
I tried running the ifiletime.vbs script in TCC 15 under Windows XP, and it returned;
Code:
[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
 
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;
Code:
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
 
May 20, 2008
11,853
121
Syracuse, NY, USA
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?
 
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
 

Similar threads