VBScript, CreateObject from dll??
-
Saturday, January 05, 2013 1:34 AM
Hello all,
Is it possible to Create an object from a dll file? For example, we use the FileSystemObject all the time in Script ... or at least I do. I have always accessed the file system the same way:
Dim objFSO Set objFSO = CreateObject("Scripting.FileSystemObject")
Ok, the reason that code works is because of COM providing an automation interface from the file: "C:\Windows\System32\scrrun.dll". Ah, but then there is a FileSystemObject in three different places that I know of: IHost: "C:\Windows\System32\wscript.exe", IWshRuntimeLibrary: "C:\Windows\System32\wshom.ocx", and Scripting: "C:\Windows\System32\scrrun.dll" (which the example above uses).
So, is there some way to create an object (in this case, the FileSystemObject) by knowing the file, instead of knowing the "magic words"? When I use: Set objScrRun = CreateObject("C:\Windows\System32\scrrun.dll") in VbsEdit, the object will load into the object browser, but I have been unable to actually use the object this way. In other words, when I go on to type: objScrRun. the emphasis being on the "." or dot, I do not get the code completion that I get when I create the object as originally stated at the beginning of this post. I sure am hoping that I can do the same things by calling the full path and name of a dll file, so I don't have to go and hunt down the "magic" words for instantiating an object. It would be better to learn it that way anyway, as it takes the "mystery" out of what it is you are actually doing. That way it is so much easier to distinguish the differences in where the interface is coming from, ie: there is a FileSystemObject in wscript.exe (IHost), scrrun.dll (Scripting), wshom.ocx (IWshRuntimeLibrary).
Student
- Edited by 3ScriptsToMars Saturday, January 05, 2013 2:04 AM spelling
All Replies
-
Saturday, January 05, 2013 2:25 AM
No. Not in scripting and why would you want to.
CreateObject only responds to ProgIds. It cannot be used with files.
See: http://technet.microsoft.com/en-us/library/ee156598.aspx
What makes you think Scripting.FileSystemObject exists in other DLLs? It doesn't. It is accessible through many automation interfaces including VB6/5/4, VBA and others.
The FSO is only available in scrun.dll along with the other scripting classes. Look in the registry and you will see only one reference to that ProgID and one file reference.
Happy New Year ¯\_(ツ)_/¯
- Marked As Answer by 3ScriptsToMars Saturday, January 05, 2013 3:33 AM
-
Saturday, January 05, 2013 3:28 AM
Yes, I already knew what the documentation says about ProgIds. Why I would want to should be clear as day, and I am not going to spell it out for you. It'll just end up with you arguing. Just like when I had said about using an object browser to look and see what there is to use, I got jumped on by two or three of you who say that is absurd. According to you guys, you have to have a problem first, then decide if scripting is a viable solution, then find out what objects you need to use to solve the problem. Yes, yes, yes, ... that is all fine and good when you are busy in the industry, you've had years of practice and being mentored under your belt, and someone is always coming to you for a problem to solve. ... poor me (Haha) ... I had to start off with very little knowlege, the XP Registry Guide, and VBScript Self-Paced Learning Guide. Turns out that I wish I would have gotten the Windows 2000 Scripting Guide, instead. I am pretty sure I would have gotten of to a better fundamental understanding of what is even scriptable because of COM providing the interface and all of that.
Me, I am using VbsEdit to load libraries so I can see the dll, ocx, exe files that provide a scriptable COM interface. I am browsing, that is why it is called a browser. Now, I did the registry search, and you are correct. However, when you load the dll files that I described in my post, you will see the FileSystemObject underneath each of the three: IHost, IWshRuntimeLibrary, and Scripting. The only thing that I can come up with is that the FileSystemObject in IHost and the IWshRuntimeLibrary are just pointers to the Scripting.FileSystemObject. .... or maybe that is not correct either.
So, since I explained all of that, I guess I'll just go ahead an respond to you question: "...and why would you want to." Again, it would be to avoid all this confusion. If I could just load the dll, I already have all the interfaces, classes, methods, and properties. I wouldn't have to hunt down a ProgId. It would have been really beneficial to write the scripting engine to use an #include directive. Then it would have been as easy as knowing the file. ie: #include "C:\Windows\System32\scrrun.dll" .... boomb you'd have the filesystemobject, TextStream, Dictionary, etc... etc...
Alright, then. Anyway, hi ho, hi ho, it's off to find ProgIds, I go
Student
- Edited by 3ScriptsToMars Saturday, January 05, 2013 3:35 AM
-
Saturday, January 05, 2013 3:44 AM
That is what I posted. The references you see are just pointers or references.
If you want to understand this then you should take a course in COM and automation.
There is no confusion. A ProgId is registered in the registry. Except for versions it cannot refer to more than one DLL. 'CreateObject' calls the registry to find the ProgId and to know how to instantiate it based on criteria that is very complex. COM supports many languages and calling conventions. It is not a DLL or fileloader loader.
There is no confusion. The object browser - I have few - will allow you to browse by ProgId.. This is a clue as to what you can load. Not all ProgIds can be loaded by a script engine.
Call Microsoft and tell them that you want them to redesign years of programming techniques to suit your idea of how an advanced technical programming interface should work. Who knows. Maybe they will hire you as an advisor.
On the serious side. What you see is that way for very good technical and historical reasons (CORBA). You can research COM and see what I am referring to.
Unfortunately we cannot always have things be the way we want them to be. - Sorry.
Happy New Year ¯\_(ツ)_/¯
-
Saturday, January 05, 2013 4:55 PM
3,
Here are some supplementary responses to a few of the things you've asked about. The focus here is generally practical, applied administrative solution-building, which is why there's a degree of disconnect between your questions and the answers. I asked a lot of the same questions when I started working with WSH, but that was in a different context - the WSH/VBScript newsgroups in 2000-2002 had a different focus and were more oriented towards development issues. A lot of it wasn't practical, but these are fun topics.
> Is it possible to Create an object from a dll file?Speaking of simple VBS/JS files, and in the sense of either "choose the file from which I load a well-known class" or "load a dll so I can access other bits", the answer is no - it just isn't possible. Late binding, used exclusively by running scripts, was designed to completely bypass explicit binding to files.
So, even though there is a FileSystemObject coclass exposed by the type libraries for scrrun.dll, wscript.exe, and wshom.ocx, you can't pick and choose where you load from. To do that you need to be able to perform early binding to a specific file. In any case, there's often no difference; if I recall correctly, wshom.ocx depends on scrrun.dll and may simply be re-exposing the interfaces taken from scrrun.dll.
What you _can_ do if you're using a WSF or WSC is to make use of reference and object tags, which allow you to load type library info or pre-instantiate classes. The primary practical use of this has been accessing constants without needing to explicitly define them in scripts (like ForReading, ForAppending, and ForWriting; if you reference scrrun's typelib in a WSF, you can use them as-named).>So, is there some way to create an object (in this case, the FileSystemObject) by knowing the file, instead of knowing the "magic words"?
No, and this is by design. One of the thorny problems COM was supposed to solve was the problem of not being able to find necessary resources, and it did this by providing for class/interface registration. Late binding via CreateObject goes one further by allowing version-agnostic access to resources. The idea was to *prevent* the cluster**** that would happen if you had to manually load scrrun.dll, since it might be in locations such as c:\windows\system\scrrun.dll, D:\WinNT\system32\scrrun.dll, C:\Windows\SysWow64\scrrun.dll.
>... I sure am hoping that I can do the same things by calling the full path and name of a dll file, so I don't have to go and hunt down the "magic" words for instantiating an object. It would be better to learn it that way anyway, as it takes the "mystery" out of what it is you are actually doing. That way it is so much easier to distinguish the differences in where the interface is coming from, ie: there is a FileSystemObject in wscript.exe (IHost), scrrun.dll (Scripting), wshom.ocx (IWshRuntimeLibrary).
What you're saying is exactly what I said when I first started working with scripting. I believe what you're after is a way to rapidly explore the wealth you have in COM automation. By binding to a particular file in VBSEdit, if I recall that correctly, you get intellisense allowing you to see classes, methods, and properties.What you probably want is a COM object browser; this made all the difference to me in exploring COM. I went from needing to ask endless questions about a particular component or hunt through (often stale/erroneous) documentation to being able to find and grasp the role of new objects in seconds.
The COM browser from Microsoft, Oleview, is a bit deficient for easy exploration in my opinion, but it's a useful fallback. It's very difficult to understand if you're new to COM stuff, but it's available via MSDN and even in a couple of download packages on the Microsoft downloads site (do a search for oleview).
Over the years I've personally become accustomed to using Mark Pryor's *free* TLViewer tool; it's well-designed for COM use. You can find it at http://www.tlviewer.org/tlviewer/. It can take a few minutes of work to get it running precisely right with the Windows changes over the years, but once it's going it's an amazingly useful tool.
- Marked As Answer by 3ScriptsToMars Saturday, January 05, 2013 5:40 PM
-
Saturday, January 05, 2013 5:47 PM
Thanks Alex,
That was huge, and I really appreciate your explanation and your tips for tools to browse COM. Yes, you nailed it. What I am after is a way to rapidly explore the wealth in COM automation. I thought that the object browser in VbsEdit was doing that for me already. Well, it, sort of, is. I have read infromation about the early and late binding, but to tell you the truth, I forgot all about it until you just brought it up. I am going to check out OleView, and TLViewer, too.
... hahahaha ... yeah, buddy, I feel like momma dun just dressed me and know I am ready for school .... lol .... lookout!
No really, thanks again .... you to jrv .... you answer questions like it ain't nobody's business ... lol
:-)
Student
-
Saturday, January 05, 2013 6:35 PM
It is interesting that you sign "Student" yet you like to argue every point. You always dislike being told that what you want to do cannot be done the way you are trying to do it. You also take it personally when told that your technical "wants" are not possible to fulfill.
You have repeatedly thrown words and concepts into your questions that show you do not have any programming background and that you technical knowledge of Windows is limited to the GUI. This is not abnormal or bad. You just need to spend some time on basics.
Alex has a said pretty much what you have been told in other threads and in this one. What you want cannot be done in scripting. Other s have noted the late/early binding and the COM support for scripting.
I still say that if you sent sufficient time with the learning material and researched terms you are not fully sure of you would be up to speed in a short time. Why make it all so difficult for yourself.
And please drop the personal barbs. I am addressing your stated level of competence in scripting. It is not condescending. I am just writing without using a complex technical descriptions.
This particular thread is classic. CreateObject is defined one way. It takes a ProgId. This can be determined from the documentation. Why argue with the design of Windows and the scripting system. You cannot change it.
Happy New Year ¯\_(ツ)_/¯
.png)
