WSC (Windows Script Components) Without Registration!
------------------------------------------------------------------------
http://www.ericphelps.com/scripting/samples/wsc/
------------------------------------------------------------------------
FIRST, A WARNING:
Don't go clicking on things in this folder if you have IE set at the
typical low Microsoft security settings. Nothing BAD will happen,
but those things that LOOK like they should be pictures (JPG or GIF
file extensions) ARE NOT PICTURES. Even the "text files" with TXT
file extensions (except for this readme file) aren't text files! IE,
being too smart for YOUR own good, will ignore the file extension,
ignore the mime type, perform "mime sniffing", correctly identify
the files as scripts and then RUN THEM! Like I said, nothing bad
will happen, but I would be really upset if a script ran when I
tried to open what I thought was a picture or text file! If you
read the rest of this file (boring as it is), you'll see what each
file in this directory is for. Then you won't need to be surprised
or upset when Windows does stupid unexpected things to you. Because
they won't be unexpected -- they'll be fun!
------------------------------------------------------------------------
WSC files are "objects" with methods and properties just like
compiled ActiveX / COM objects already registered on your computer.
For people who write lots of scripts, WSC files are a GREAT way
of putting code in one place rather than pasting it into every script.
The good news (for those people who build or deploy on locked-down
systems) is that when you create a WSC, you do NOT have to register
it on your system! In fact, it doesn't even have to be on your system!
All you need to know is the path to the WSC file, and you can use it.
For example, if you had a WSC file named "foo.wsc", you could use it
WITHOUT REGISTERING IT (or even if you did register it!) like either
of these two examples:
Set objFoo = GetObject("script:C:\Some Folder\foo.wsc")
Set objFoo = GetObject("script:http://www.myserver.com/foo.wsc")
Yes, that second example is HTTP method! You can park the WSC file on
a web server on the internet or on your intranet. This is good news
for anybody who wants to maintain one code base that is shared by
hundreds of users.
Of course, if you don't register it and don't generate type libraries
for the WSC file, you won't get intellisense help when writing your
script. You'll just have to know how to use it! So what? Register it
on the development machine for easier coding, but don't bother
registering it when you deploy it.
Writing a WSC file *can* be WAY simpler than all the stuff you've read!
For example, if you don't want methods and properties and you don't
want to pass arguments or return values... In other words, if you just
want to DO SOMETHING, your WSC code can be as simple as this:
Yes, that's it! You DO NOT need the class ID, component ID, type library,
or method declarations. In fact, I used that exact code in the
"HelloWorld.wsc" example in this directory. You can test it over http
with a single line of VBS code like this:
GetObject "script:http://www.ericphelps.com/scripting/samples/wsc/HelloWorld.wsc"
Because the "object" generated by GetObject is never used again, I
didn't bother to assign it to anything. That's why I left off the
parentheses.
But wait... There's more! When you use the http method to reference a
WSC object, you download that WSC code from the server and run it on
your PC. That's why it DOES NOT MATTER what kind of server you put the
WSC code on. But... If it runs on your PC, it has to exist as a file,
right? Well, yes. If you look in your Internet Explorer cache files,
you'll find a copy of the WSC file there. But... Ummm... Suppose you
really are on a locked-down machine and you don't want a WSC file
sitting in your IE cache? Well, the file has to be there, or at least
it's going to end up there, but it doesn't have to have a WSC file
extension! When you call it from the script, you do it with a "script:"
preface. That overrides any file extension. You can give your "wsc"
file an "htm", "jpg", "txt" or any other harmless and uninteresting file
extension you want. The same is true for "wsc" files on your hard drive.
Want proof? Try running these two VBS code lines:
GetObject "script:http://www.ericphelps.com/scripting/samples/wsc/HelloWorld.txt"
GetObject "script:http://www.ericphelps.com/scripting/samples/wsc/HelloWorld.gif"
The "HelloWorld" files are all identical. The three extensions "wsc",
"txt", and "gif" are the only difference. The extension makes NO DIFFERENCE
to your script. Look in your IE cache... Which one draws the most attention?
------------------------------------------------------------------------
In fact, the harmless file extension trick is also true for ActiveX /
COM objects that started life as DLL or OCX files. You can give them
any extension you want BEFORE you register them on your system. And
they'll work! What fun! But that's another story.
------------------------------------------------------------------------
Since you have the WSC file (regardless of what file extension you gave it)
in your cache, you might wonder why you have to download it every time.
Well, the system doesn't seem to want to use the cached version, but you
can force it. You can use code similar to the "FindInCache.vbs" script I
have in this directory to see if you can find it in the cache. If you find
it and verify it is quality stuff (first few bytes match, recent time stamp,
etc.), then you can have your GetObject use a local file reference.
------------------------------------------------------------------------
Optional reading: A Real-Life (lame) Example
------------------------------------------------------------------------
For a real-life example of how you can run code on your computer that
you don't want to (or aren't supposed to) install on your computer,
download the "GZip.vbs" sample in this directory. The GZip.vbs script
is written to allow you to do drag-and-drop gzip compression of files.
You drop a file on the script and it will "gzip" compress that file.
Why GZIP? Suppose you need to send a file to some Unix or VAX
mainframe that doesn't support ZIP files? And you're not supposed to
have GNU utilities sitting on your computer when it gets scanned by
the corporate software N^zis. What do you do? You make a script like
"GZip.vbs"! And you make a matching WSC file that buries the needed
program inside itself. Then you stick that WSC file where nobody is
going to look (like a free geocities account) and give it a harmless
looking file extension. Which I did. When the vbs file runs, it downloads
and runs the wsc file (actually named "GZip.jpg". That will be in the
cache. If anybody looks in your cache, they'll probably try to view it
with a graphics program, fail misearably, and figure it's a corrupted
picture. While YOU will be able to write an automated script to gzip
the file to send to the mainframe.
If you download the "GZip.jpg" file and open it with Notepad, you'll
see all the wsc code. The only stuff you won't find in a normal WSC
file is the trick I used to embed the gzip.exe file:
I got gzip.exe from the GNU Utilities collection at:
http://unxutils.sourceforge.net/
I embedded the gzip program in the script with my SFX creator from:
http://www.ericphelps.com/scripting/samples/sfx/
After dropping the exe on the SFX script, I just copied and pasted
the resulting code into the wsc/jpg file.
If gzip isn't exciting enough for you, you can bury anything this way.
An encryption program. An emailer. A file conversion utility. Something
to think about!
------------------------------------------------------------------------
http://www.ericphelps.com/scripting/samples/wsc/
------------------------------------------------------------------------