Typelib : ProgID / VersionIndependentProgID not found

[R.Wieser]

Hello All,

I've just browsed thru the MSWINSCK.OCX typelib, trying to find the name
with which its loaded using wscript.createobject. That name is
"mswinsock.winsock". The reason I'm doing this is because I want to
retrieve the objects CLSID, even if its not registered.

The problem is that I can't find that name anywhere inside the typelib. I
can find the name "winsock" in its (only) CoClass, but I can't find
"mswinsock" (on its own) anywhere, much less a combination thereof.

Do I have to assume that the name stored in the registry (under
VersionIndependentProgID and ProgID) is/may be some kind of made-up name
with no connection to whats in the TypeLib, or am I missing something here ?

Regards,
Rudy Wieser

[Mayayana]

| I've just browsed thru the MSWINSCK.OCX typelib, trying to find the name
| with which its loaded using wscript.createobject. That name is
| "mswinsock.winsock". The reason I'm doing this is because I want to
| retrieve the objects CLSID, even if its not registered.
|
| The problem is that I can't find that name anywhere inside the typelib. I
| can find the name "winsock" in its (only) CoClass, but I can't find
| "mswinsock" (on its own) anywhere, much less a combination thereof.
|
| Do I have to assume that the name stored in the registry (under
| VersionIndependentProgID and ProgID) is/may be some kind of made-up name
| with no connection to whats in the TypeLib, or am I missing something here
?
|

It doesn't seem to be entirely standardized.
In general, it's server.class. So mswinsock is the
server, the OCX. It's relevance is to find the
server file path and typelib path. But there are
also classes that don't have server names, like
winmgmts. I've never quite understood how that
works.

[R.Wieser]

Mayayana,

Post by Mayayana
It doesn't seem to be entirely standardized.

Hmmm ... I was afraid of that.

I was thinking of just dropping the prefix string (upto-and-uncluding the
first-found dot), but with no actual standarisation that could as easily
work against me. :-\

Post by Mayayana
It's relevance is to find the server file path and typelib path.

True, but that only works when the object is already registered to the
system.

In my case I've got the unregistered(!) "server file" and work from there
(first step: using LoadLibrary function on it to obtain the TypeLib info
resource).

Post by Mayayana
But there are also classes that don't have server names,
like winmgmts. I've never quite understood how that
works.

The (home use only) OCX objects I've written do not have them either, but I
can see why, with potentially many such objects present on a system, a
prefix to the classes in those "server files" would be a good idea. Much
less likely to, in the registry, get name clashes.

Regards,
Rudy Wieser

Post by Mayayana
| I've just browsed thru the MSWINSCK.OCX typelib, trying to find the name
| with which its loaded using wscript.createobject. That name is
| "mswinsock.winsock". The reason I'm doing this is because I want to
| retrieve the objects CLSID, even if its not registered.
|
| The problem is that I can't find that name anywhere inside the typelib.

I

Post by Mayayana
| can find the name "winsock" in its (only) CoClass, but I can't find
| "mswinsock" (on its own) anywhere, much less a combination thereof.
|
| Do I have to assume that the name stored in the registry (under
| VersionIndependentProgID and ProgID) is/may be some kind of made-up name
| with no connection to whats in the TypeLib, or am I missing something here
?
|
It doesn't seem to be entirely standardized.
In general, it's server.class. So mswinsock is the
server, the OCX. It's relevance is to find the
server file path and typelib path. But there are
also classes that don't have server names, like
winmgmts. I've never quite understood how that
works.

[Mayayana]

I don't know if this will help, and you may already
know it: My impression is that the server name
is not standardized from COM Registry to typelib,
but that that's not really a problem.

You have mswinsock.winsock. mswinsock is not in
the typelib. Nor is it the name of the file.
If you call LoadTypeLibEx to get a reference to an
iTypelib for the file, then call ITypeLib.GetDocumentation,
the second parameter returned, which is the server name,
is MSWinsockLib. I find that's typical. The server name in
the typelib does not match the server name used in the
ProgID.

But that shouldn't matter. You have the typelib for
mswinsck.ocx. That file is the server. It doesn't much
matter what it's called if you already know what file
you're dealing with.

I'm not certain this approach will always work, but it
seems that it should: If you make sure to snip any
server name from the front and any version name from
the back (like server.class.1) then you should always
have a class name that will be unambiguous in the
context of that typelib.
One catch, though: The typelib does not have to
be in the DLL/OCX. It usually is, but IE, for example,
has an external typelib. If the object is not registered
you won't have any way to know that.

[R.Wieser]

Mayayana,

Post by Mayayana
I'm not certain this approach will always work, but it
seems that it should: If you make sure to snip any
server name from the front and any version name from
the back (like server.class.1) then you should always
have a class name that will be unambiguous in the
context of that typelib.

:-) Apart from removing the verion name at the back (did not think about
that) that was what I was referring to in my previous message when I said
"dropping the prefix string".

Post by Mayayana
One catch, though: The typelib does not have to
be in the DLL/OCX. It usually is, but IE, for example,
has an external typelib. If the object is not registered
you won't have any way to know that.

True, and something I have to find a solution for too (most likely to, if no
internally-stored typelib is found, change the extension of the offered
object name to ".IDL" and see if it exists). But I'm taking one step at a
time.

And there are other problems (things to do) too, like MSWinSock having
"events" (call backs), which I have no idea of how my object-loader should
deal with them ...

Regards,
Rudy Wieser

Post by Mayayana
I don't know if this will help, and you may already
know it: My impression is that the server name
is not standardized from COM Registry to typelib,
but that that's not really a problem.
You have mswinsock.winsock. mswinsock is not in
the typelib. Nor is it the name of the file.
If you call LoadTypeLibEx to get a reference to an
iTypelib for the file, then call ITypeLib.GetDocumentation,
the second parameter returned, which is the server name,
is MSWinsockLib. I find that's typical. The server name in
the typelib does not match the server name used in the
ProgID.
But that shouldn't matter. You have the typelib for
mswinsck.ocx. That file is the server. It doesn't much
matter what it's called if you already know what file
you're dealing with.
I'm not certain this approach will always work, but it
seems that it should: If you make sure to snip any
server name from the front and any version name from
the back (like server.class.1) then you should always
have a class name that will be unambiguous in the
context of that typelib.
One catch, though: The typelib does not have to
be in the DLL/OCX. It usually is, but IE, for example,
has an external typelib. If the object is not registered
you won't have any way to know that.

[Mayayana]

| And there are other problems (things to do) too, like MSWinSock having
| "events" (call backs), which I have no idea of how my object-loader should
| deal with them ...
|

I don't know if I dare ask what you're trying
to accomplish. :)

An OCX is normally sited in a window. I've only
used events in AxEXEs created with
WScript.CreateObject, and even then it's very
clunky, since the script has to be kept looping
while waiting for an event. Dealing with multiple
events would be even more tricky.

[R.Wieser]

Mayayana,

Post by Mayayana
I don't know if I dare ask what you're trying
to accomplish. :)

Rather simple actually: I'm trying to load an unregistered object (into a
basic VBScript engine). Nothing more, nothing less.

I'm quite aware that this will won't work for for all objects, but currently
I'm aiming at "well-behaved" ones (and not yet trying to make usage of any
event-callbacks)

Post by Mayayana
An OCX is normally sited in a window.

.. But there is no reason it needs to be. Not even with the (given as an
example) MSWinSck.ocx control. :-)

Post by Mayayana
and even then it's very clunky, since the script has to
be kept looping while waiting for an event.

Which is just a shortcoming of W- and CScript.exe. I've embedded the
VBScript engine in a program of mine, and could, from within my program,
call functions in the script long after it itself had ended. Or, said
differently, the script stayed active/accessible until I told the engine to
shut it down down (IActiveScript::Close).

It means that the only thing either W- and/or CScript needs to do is to hold
off closing until it is told to do so (as a result of calling "wscript.quit"
perhaps).

By the way: That VBScript engine -wrapping program is what I'm writing that
"load a non-registered object" for. :-)

Regards,
Rudy Wieser

Post by Mayayana
| And there are other problems (things to do) too, like MSWinSock having
| "events" (call backs), which I have no idea of how my object-loader should
| deal with them ...
|
I don't know if I dare ask what you're trying
to accomplish. :)
An OCX is normally sited in a window. I've only
used events in AxEXEs created with
WScript.CreateObject, and even then it's very
clunky, since the script has to be kept looping
while waiting for an event. Dealing with multiple
events would be even more tricky.

[Mayayana]

| > I don't know if I dare ask what you're trying
| > to accomplish. :)
|
| Rather simple actually: I'm trying to load an unregistered object (into a
| basic VBScript engine). Nothing more, nothing less.
|

I guess I don't really get the advantage of that, but
it does sound intriguing.

| > An OCX is normally sited in a window.
|
| .. But there is no reason it needs to be. Not even with the (given as
an
| example) MSWinSck.ocx control. :-)

I suppose not, but usually an OCX is an OCX
because it makes sense: The events with winsock.
The interactive GUI with most controls, like text
boxes and buttons. With your skills you can go
straight to winsock API in your code, anyway. I'm
guessing you must be trying to create an adaptable
tool like AutoIt that will allow scripters to get all
that functionality easily. Though there's also another
issue that might come into play: Licensing. The winsock
control doesn't seem to require a license, but many do.
Loading the control directly, without it being
incorporated in licensed software, may be a problem.

[R.Wieser]

Mayayana,

Post by Mayayana
I guess I don't really get the advantage of that,
but it does sound intriguing.

I on my part do not really see the advantage of "*must* be made available
for everyone, anywhere" philosophy MS has wrought for them. I regard that
as rather dangerous even. For example, there is *no* difference between a
local-only object and a webpage accessible one ...

The advantage (to me) is twofold : I can load objects that are in a building
stage (unfinished), and I can limit the usage of an object to a specific
script.

Post by Mayayana
I suppose not, but usually an OCX is an OCX
because it makes sense: The events with winsock.
The interactive GUI with most controls, like text
boxes and buttons.

Granted, an OCX has got a number of good points. Like divulging all the
info (by way of a typelib) a GUI driven, compiling environment needs to use
such an OCX component -- even though you already know that a typelib can
easily lie about the abilities of the object its ment for.

Also, did you know that W/CScript fully ignores any constants and
enumerations available in a typelib ? :-\

Post by Mayayana
With your skills you can go straight to winsock API
in your code, anyway.
I'm guessing you must be trying to create an adaptable
tool like AutoIt that will allow scripters to get all that
functionality easily.

Pretty-much that. But as VBScript seems to be part of a default install
(don't know about later Windows versions though ...) there should be less of
a threshold to use it.

Post by Mayayana
Licensing. The winsock control doesn't seem to require a
license, but many do.

Actually, that MSWINSCK.OCX does have a licence. Is an easily copy-pastable
one tough (some have suggested that it was done on purpose... ).

Post by Mayayana
Loading the control directly, without it being
incorporated in licensed software, may be a problem.

Those are legal, not technical problems.

Also, I'm not providing those objects. Its upto the user to check if the
("shrink-wrap") EULA for such licenced objects is enforcable in his part of
the world (not in Europe), or if he's excluded from following them as long
as he has the licence and its for home use only (as in Europe). :-)

Regards,
Rudy Wieser

Post by Mayayana
| > I don't know if I dare ask what you're trying
| > to accomplish. :)
|
| Rather simple actually: I'm trying to load an unregistered object (into a
| basic VBScript engine). Nothing more, nothing less.
I guess I don't really get the advantage of that, but
it does sound intriguing.
| > An OCX is normally sited in a window.
|
| .. But there is no reason it needs to be. Not even with the
| (given as an example) MSWinSck.ocx control. :-)
I suppose not, but usually an OCX is an OCX
because it makes sense: The events with winsock.
The interactive GUI with most controls, like text
boxes and buttons. With your skills you can go
straight to winsock API in your code, anyway. I'm
guessing you must be trying to create an adaptable
tool like AutoIt that will allow scripters to get all
that functionality easily. Though there's also another
issue that might come into play: Licensing. The winsock
control doesn't seem to require a license, but many do.
Loading the control directly, without it being
incorporated in licensed software, may be a problem.

[JJ]

Post by R.Wieser
Hello All,
I've just browsed thru the MSWINSCK.OCX typelib, trying to find the name
with which its loaded using wscript.createobject. That name is
"mswinsock.winsock". The reason I'm doing this is because I want to
retrieve the objects CLSID, even if its not registered.
The problem is that I can't find that name anywhere inside the typelib. I
can find the name "winsock" in its (only) CoClass, but I can't find
"mswinsock" (on its own) anywhere, much less a combination thereof.
Do I have to assume that the name stored in the registry (under
VersionIndependentProgID and ProgID) is/may be some kind of made-up name
with no connection to whats in the TypeLib, or am I missing something here ?
Regards,
Rudy Wieser

Type Library is simply a way to publicize COM classes and/or interfaces so
that other programs may access them without knowing their type information
beforehand. So, a COM library is not required to include all of the
classes/interfaces in its Type Library - or include any at all.

Some COM libraries may even be still accessible even though they're not
registered into the registry. In this case, they are accessed manually by
calling its DllGetClassObject() exported DLL function directly - like
OLE32.DLL does. Those kind of COMs are intended to be used by programs that
already have the type information beforehand.

COM classes in the registry simply tell programs which DLL to ask the
required COM class. The OLE32.DLL does the dirty work for you. i.e. retrive
the given class, find it in the registry, load the associated COM's DLL,
then call its DllGetClassObject().

[R.Wieser]

JJ,

Post by JJ
So, a COM library is not required to include all of the
classes/interfaces in its Type Library - or include any at all.

True, but thats a whole other problem (for which there seems to be no
solution :-\ ).

I used mswinsck.ocx as an example as the needed CLSID is mentioned/exposed
in both the registry as well as in the typelib. Its just that the names do
not match up, and I wanted to know/figure out why that is.

Post by JJ
In this case, they are accessed manually by calling its
DllGetClassObject() exported DLL function directly
- like OLE32.DLL does.

And like I'm doing when loading an unregistered object. :-)

... but currently I'm feeding it a CLSID, instead of its (much more commonly
known) object name.

Regards,
Rudy Wieser

Post by JJ

Post by R.Wieser
Hello All,
I've just browsed thru the MSWINSCK.OCX typelib, trying to find the name
with which its loaded using wscript.createobject. That name is
"mswinsock.winsock". The reason I'm doing this is because I want to
retrieve the objects CLSID, even if its not registered.
The problem is that I can't find that name anywhere inside the typelib.

I

Post by JJ

Post by R.Wieser
can find the name "winsock" in its (only) CoClass, but I can't find
"mswinsock" (on its own) anywhere, much less a combination thereof.
Do I have to assume that the name stored in the registry (under
VersionIndependentProgID and ProgID) is/may be some kind of made-up name
with no connection to whats in the TypeLib, or am I missing something here ?
Regards,
Rudy Wieser

Type Library is simply a way to publicize COM classes and/or interfaces so
that other programs may access them without knowing their type information
beforehand. So, a COM library is not required to include all of the
classes/interfaces in its Type Library - or include any at all.
Some COM libraries may even be still accessible even though they're not
registered into the registry. In this case, they are accessed manually by
calling its DllGetClassObject() exported DLL function directly - like
OLE32.DLL does. Those kind of COMs are intended to be used by programs that
already have the type information beforehand.
COM classes in the registry simply tell programs which DLL to ask the
required COM class. The OLE32.DLL does the dirty work for you. i.e. retrive
the given class, find it in the registry, load the associated COM's DLL,
then call its DllGetClassObject().