"Douglas J. Steele" <NOSPAM_djsteele@NOSPAM_canada.com> wrote in
message <uP3f9VgmHHA.3872@TK2MSFTNGP04.phx.gbl>:

Try through WScript

Set wshObj = CreateObject("WScript.Network")

[]

I assume you've determined that the object I used above does not
represent the whole WSH object model?

I don't recall where I got the correct reference for using the FSO
with late binding.

Given that the wshom.ocx has the FileSystemObject as one of its
members, I'd think that it's the same thing. But an OCX is intended
to be used as a replacement for doing it directly. My guess would be
that this OCX is just an interface to the same functionality as I'm
getting through the Scripting object. Yes, just browsing the
registry I see that Scripting refers to the scripting functionality
in scrrun.dll. The OCX is a superset of scrrun.dl functionality, but
most of the additional functionality seems to me to be just
additions to make it easier to do things that scrrun.dll does.

OK, I'm wrong in what I say above. The libaries have a lot of
overlap, but are not the same. The OCX has these members:

 Drive, Drives, File, Files, FSO, Folder, Folders, TextStream,
 WSHCollection, WSHEnvironment, WSHExec, WSHNetwork, WSHShell,
 SWHShortcut, SWHURLShortcut

while the DLL adds Dictionary and Encoder, but lacks all the WSH
members.

However, the WSH members all seem to me to be for controlling the
WSH, rather than for implementing functionality offered by the WSH's
object model. That is, the WSH members are for getting to
functionality that doesn't have its own top-level object. I don't
know enough about the WSH to know what those would be.