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/ ------------------------------------------------------------------------