Re: why some dll's are scriptable and some are not?
- From: "mayayana" <mayaXXyana1a@xxxxxxxxxxxxxxxx>
- Date: Tue, 22 Aug 2006 14:08:31 GMT
This may be more than you or others want to know,
but if it were me I'd want the whole story.... so here goes:
Regular DLLs can present their functions in several ways,
but none are usable by script. Partly that's due to the
structure of the DLL and partly it's due to the limits inherent
with script.
Script can only use COM DLLs.
COM (component object model) is the same as OLE (object
linking and embedding), which is the same as ActiveX.
It's all just marketing. (In fact, in the book The Essence
of COM the author goes to some length to make fun of
these terms, explaining that ActiveX actually has no
technical definition whatsoever. :) The term "automation"
also refers to COM.
So a COM DLL is also an ActiveX DLL. It basically means that
it's structured according to the COM system, which provides
functionality wrapped in objects. Part of the COM
system is the use of type libraries to document an object's
structure. A type library can be an external file or it can
be internal to the COM object file. Windows provides methods
through its "OLE" functions to read type libraries. What all of
that means is that any COM executable (DLL, OCX, EXE) can be
"queried" as to what objects and methods it provides.
Another part of COM is that it's all documented in the
Registry (unlike regular DLLs).The reason you can use CreateObject
is because the object name is listed in HKCR. A subkey there
points to a key in HKCR\CLSID, which points to the source file
and type library for the object. So when you call CreateObject,
WSH looks up the object in the Registry and loads it for you.
Besides being limited to COM objects, VBS does not deal
with data types, which is required for regular DLLs (and many
COM objects). For VBS there is only the "variant" data type.
So, for the most part, VBS is limited to COM objects that
provide variant parameters in their properties and methods.
All of those limitations seem arbitrary at first glance,
but they're connected with the fact that VBS is very "high
level", far removed from the machine level of operation.
At the bottom, the role of the OS is to make the machine
usable. So Windows provides ways to do basic things like show
a textbox on the screen.
ActiveX controls, .Net classes, Java classes, etc. wrap that
functionality and make it more accessible to tools with less
access. That's the whole idea with objects: They wrap
functionality, trading efficiency for convenience.
At the top level of all that is script, which is really acting
by proxy. In other words, VBS is just text that gets interpreted
by the WSH, so it's limited by what the WSH - or other hosts -
provide.
If it were a restaurant, Windows might be the pans and
food. The cooking is done by C, C++, VB, Delphi and other
code that can be compiled to a native executable. (Usually
C or C++ does the most basic cooking (hardware drivers), while
C++, VB and Delphi do the dishes (GUI programs and
ActiveX controls). And you could say that Java and .Net are
a bit like prep cooks. They have limited access to the kitchen.
Just as the cooks can only make dishes they
have the ingredients for, script is like a waiter who can only
request things that the cooks make. And the waiter can only
get the dish in the ways made accessible by the cook. (An
ActiveX control only makes specific functions available by
design, just as the cook will only give you specific dressings on
your salad.)
----
Since COM objects can be queried via their type libraries,
and since they're documented in the Registry, it's possible
to collect and view that data. That's what an object browser
does. (And that's why an ActiveX DLL has to be registered.
Otherwise there would be no way to find it with COM.)
An object browser shows the methods and properties
available from an object by reading it's type library.
(But an object browser is mostly just for reference. You
almost always need documentation to actually make use
of COM objects. The object browser just shows a listing
of the methods.)
Object browsers:
Besides the object browser in Visual Studio 6 I think MS
Word has the same thing.
This is a popular easy-to-use object browser, similar to
the VS version:
http://www.tlviewer.org/tlviewer/tlviewer.htm
This one also lets you list all COM objects on your system:
http://www.jsware.net/jsware/webed.php3
This one (watch out for wordwrap) is the MS Oleview
program. This link is for a 2000/XP version only. I don't
know whether the Win9x version is still available online.
Oleview also comes with Visual Studio 6. It displays all
type library data on your system, showing the details of
all COM objects. It's more difficult to navigate and read
than an object browser is, though, because of the layout.
It's pretty much just a raw typelib dump.
http://www.microsoft.com/downloads/details.aspx?FamilyID=5233b70d-d9b2-4cb5-
aeb6-45664be858b6&DisplayLang=en
If you want to write code yourself to list objects,
enumerate the keys of HKCR. For each one that
has a CLSID subkey, open the following key:
HKCR\CLSID\xxx (where xxx is the CLSID subkey default value).
In that key check for a key named InProcServer32. The
default value in that key is the path of an "in-process"
component - an ActiveX DLL or control.
A LocalServer32 key indicates an out-of-process server -
an ActiveX EXE.
is there any easy-to-use ActiveX object that can send
messages to MSN Messenger & Google Talk ?
I have no idea about that. I've never used IM. But
anything with an automation interface can be scripted.
MSN Messneger may have that.
.
- References:
- Prev by Date: Re: Reading/Writing Text File
- Next by Date: Final: Rename folder with actual date
- Previous by thread: why some dll's are scriptable and some are not?
- Next by thread: Re: why some dll's are scriptable and some are not?
- Index(es):
Relevant Pages
|
Loading
