General Scripting - What's the difference ...

Can someone tell me the difference between the WSH and VBScript ?? And perhaps there isn't a difference, or perhaps there is, ... I dunno.
The reason I ask is this, I have some code which reads:

I then have from my book the following:

What is the difference between these two pieces of code ??
Is the first VBScript ??
Am I forcing a specific when using WScript.### ??
Why does the first work the same as the second even though they are different ??
Too many questions for one post. But the book doesn't cover these "inquiring minds want to know" desires, it simply tells you what to do and where to go.
Thank you so much for your help, it is really appreciated.

You've asked very good questions. Let me see if I can explain this.

First, let's look at the acronyms. WSH stands for Windows Script Host and VBScript stands for Visual Basic Scripting Edition.

The Windows Script Host is a scripting environment that can execute code written in a variety of languages. One of these such languages is VBScript.

VBScript is a COM-enabled language meaning that it allows you to access global COM objects that are native to the system. It provides the CreateObject and GetObject methods for accessing these objects. This is illustrated in your first example.

The Windows Scripting Host also provides two methods by the same name, for the same purpose. These can be accessed through the WSH's own COM object, WScript as in the second example. Since the WScript object is available at script execution, it is available to languages that do not provide ways of connecting to COM objects and exposes these two methods to add that functionality. That's why the methods appear as children of the WScript object as denoted by the dot syntax. (WScript.CreateObject as opposed to just CreateObject). Without specifying an object as the parent, WSH would assume the global method provided by VBScript as in the last example.

In most cases, VBScript's methods and WScript's methods can be used interchangeably. They do the same thing by connecting to and returning a reference for a COM object. WScript's version does add functionality that allows you to do event driven programming, but they are the same for all intents and purposes since that is far beyond the scope of this post.

COM objects are most commonly instantiated by their ProgID, a text string that identifies the object. "Scripting.FileSystemObject" is a generic ProgID that refers to the Windows Scripting Host's FileSystemObject, a COM object that exposes properties and methods for working with files and folders. The "WScript.FilesystemObject" ProgID references the same object, although the first ProgID is most commonly used.

Nilpo,
So is there a better and worse practice to the use of this code, or is it more a personal preference; less typing, etc. ??
And the COM objects accessed from the WSH, are they only the embedded ones, another words, the ones native to windows ?? I would assume so as third party software would have their own ProgID if they have one at all. I have another post which trails a little deeper into this I think.
Thank you.

Again, unless you're doing event-driven work, you can use either VBScript's or WScript's set of methods. I typically used VBS's since it saves some keystrokes.

You should also use the "Scripting.FileSystemObject" ProgID. This is the generic ProgID that represents the newest FSO object on the system.

As far as COM objects go, you can use any of them that are installed on the system--native or third-party--so long as they provide a scripting interface.