Asp Forum - References - microsoft.public.vb.general.discussion

Ian Post

6/9/2011 4:46:00 AM

In the .VBP file there is
Reference=*\G{565783C6-CB41-11D1-8B02-00600806D9B6}#1.2#0#..\..\WINDOWS\system32\wbemdisp.tlb#Microsoft
WMI Scripting V1.2 Library

When I open the IDE Projects\References it shows
C:\WINDOWS\system32\wbem\wbemdisp.tlb
The .tlb is in that folder and not in the first path.

It all compiles and the EXE runs fine.
I can handle the, for this case, ..\..\ translation to C:
How does it work that the \vbem\ does not appear in the path in the
..VBP file?
If it all goes back to the registry, then what is the purpose of the
path shown in the .VBP?

11 Answers

ralph

6/9/2011 6:45:00 AM

On Wed, 08 Jun 2011 21:46:10 -0700, BeeJ <nospam@nowhere.com> wrote:

>In the .VBP file there is
>Reference=*\G{565783C6-CB41-11D1-8B02-00600806D9B6}#1.2#0#..\..\WINDOWS\system32\wbemdisp.tlb#Microsoft
>WMI Scripting V1.2 Library
>
>When I open the IDE Projects\References it shows
>C:\WINDOWS\system32\wbem\wbemdisp.tlb
>The .tlb is in that folder and not in the first path.
>
>It all compiles and the EXE runs fine.
>I can handle the, for this case, ..\..\ translation to C:>
>How does it work that the \vbem\ does not appear in the path in the
>.VBP file?
>If it all goes back to the registry, then what is the purpose of the
>path shown in the .VBP?
>

I'm not sure either - other than the Reference path often appears more
of a "hint" than deterministic. What you are observing is common. I
thought it was a simple matter of reducing the path string length in
the .vbp file. (.vbp files follow an .ini format, and way back when,
there were limitation in string lengths. But that is pure superstition
on my part.)

In some cases you can even edit the .vbp file and replace a Reference
path with a bogus one and the compile will work just fine. Other times
any tampering will lead to problems, or will be ignored and the
original 'hint' will be written back.

(For grins, correct the path or reregister the typelib in different
locations and see what happens.)

VB always reads the Registry with the GUID to obtain the true
location. This is seldom a problem except when one attempts to write a
utility to read the .vbp files. (That's how I found out about it. You
learn not to trust that path. <g>)

-ralph

Ian Post

6/9/2011 3:43:00 PM

Yes, I am trying to read the .VBP to get the paths.
I am now looking at trying to read the Registry, however, so far I
cannot figure out the method.

I find that the CLSID or is it GUID is all over the place.
e.g. under
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{...}\TypeLib(Default)
Where the path is located at

HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{...}\InProcServer32\(Default)

So what does the {...} refer to?
There are many different values that wind up with a \TypeLib and
\InProcServer32 pair that have the same path information.
I assume that I need the specific one since one of the found may
actually point to a different version of the same file.
How do I get that {...} value to search for?
Then how do I get to the path? Always under \InProcServer32 ?
I have been trying different Registry access routines but I have not
found the correct method yet.

I also find what is probably the "root" location at
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\TypeLib\{searchedfor}
and path at

HKEY_LOCAL_MACHINE\SOFTWARE\Classes\TypeLib\{searchedfor}\1.2\0\Win32

The original source of
{565783C6-CB41-11D1-8B02-00600806D9B6}#1.2#0#
Seems to have all the necessary info to dive to \Win32
So what Registry API to use to get there?
Any pointers would be very helpful.

Mayayana

6/9/2011 5:20:00 PM

See here for the best COM tutorial I've ever found:

http://spec.winprog.org...

| HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{...}\TypeLib(Default)

Points to the HKCR\Typelib\{...} key for the object.
The path of the typelib is there. It's usually in the
same file as the server, as it is with VB6 components,
but it doesn't have to be.
|
| HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{...}\InProcServer32\(Default)
|

Points to the path of the server (parent library) in the case
of in-process components. Out-of-process (Ax EXE) has a
matching key named LocalServer32.

Ian Post

6/9/2011 6:10:00 PM

Still like some pointers.

From
Reference=*\G{565783C6-CB41-11D1-8B02-00600806D9B6}#1.2#0#..\..\WINDOWS\system32\wbemdisp.tlb#Microsoft
WMI Scripting V1.2 Library

I figured out how to parse and find the path value in the registry.
In this case I use this string to search
SOFTWARE\Classes\TypeLib\{565783C6-CB41-11D1-8B02-00600806D9B6}\1.2\0\win32

So, does the *\G indicate the registry section?
SOFTWARE\Classes\TypeLibor is that implied by References=

Where can I find this and other possible values?

Ian Post

6/9/2011 6:18:00 PM

Thanks.
Unfortunately there are some missing images throughout the three Parts.

ralph

6/9/2011 6:26:00 PM

On Thu, 09 Jun 2011 08:43:12 -0700, BeeJ <nospam@nowhere.com> wrote:

>Yes, I am trying to read the .VBP to get the paths.
>I am now looking at trying to read the Registry, however, so far I
>cannot figure out the method.
>
>I find that the CLSID or is it GUID is all over the place.
>e.g. under
> HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{...}\TypeLib(Default)
>Where the path is located at
>
>HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{...}\InProcServer32\(Default)
>
>So what does the {...} refer to?
>There are many different values that wind up with a \TypeLib and
>\InProcServer32 pair that have the same path information.
>I assume that I need the specific one since one of the found may
>actually point to a different version of the same file.
>How do I get that {...} value to search for?
>Then how do I get to the path? Always under \InProcServer32 ?
>I have been trying different Registry access routines but I have not
>found the correct method yet.
>
>I also find what is probably the "root" location at
> HKEY_LOCAL_MACHINE\SOFTWARE\Classes\TypeLib\{searchedfor}
>and path at
>
>HKEY_LOCAL_MACHINE\SOFTWARE\Classes\TypeLib\{searchedfor}\1.2\0\Win32
>
>The original source of
> {565783C6-CB41-11D1-8B02-00600806D9B6}#1.2#0#
>Seems to have all the necessary info to dive to \Win32
>So what Registry API to use to get there?
>Any pointers would be very helpful.
>

1.

The VBIDE appears* to always use the ...
\HKEY_CLASSES_ROOT\TypeLib\{guid}\<version>\<locale>\win32 node/key
for Type Libraries.

However, this information is always duplicated at ...
\HKEY_LOCAL_MACHINE\SOFTWARE\Classes\TypLib\{guid}\ ...

Any node that branches off a CLSID key, is used only by the COMML (COM
Management Library) to instance an object.

[* I modified that 'always' because I vaguely remember exceptions with
objects/controls where the reference guid is treated as a Class ID
though used as a TypeLib. I assume that is because the VBIDE is
calling COMML below the scenes during design-time. But too long ago
and I've slept since then.]

2.
For working with the Registry download one of the many Registery
Class/s available online. You'll likely modify them to fit your needs.

"Complete Registry control" VBAccelerator
http://www.vbaccelerator.com/home/vb/code/libraries/Registry_and_Ini_Files/Complete_Registry_Control/a...

"A___Ultimate Registry Class"
http://www.planetsourcecode.com/vb/scripts/ShowCode.asp?txtCodeId=28518&am...

You'll likely modify them to fit your needs.

I suggest you do not use the API to directly manipulate the Registry
in a program. Best to use throughly tested and trusted code, that
validates parameters, you have wrapped in a class. Not that the
Registry is super fragile or the API calls too complicated, but rather
the consquences of a mistype can be dramatic. <g>

3.
In practical use any of the path-keys will work, thus it doesn't
matter. In the context in which the VBIDE is saving them, the given
GUID *must* return a component that can provide the compiled binary
information required.

In a healthy system this should always be the same component. If a
given GUID can point to separate locations and multiple components -
then there is more trouble brewing.

-ralph

ralph

6/9/2011 6:45:00 PM

On Thu, 09 Jun 2011 11:10:19 -0700, BeeJ <nospam@nowhere.com> wrote:

>Still like some pointers.
>
>From
>Reference=*\G{565783C6-CB41-11D1-8B02-00600806D9B6}#1.2#0#..\..\WINDOWS\system32\wbemdisp.tlb#Microsoft
>WMI Scripting V1.2 Library
>
>I figured out how to parse and find the path value in the registry.
>In this case I use this string to search
>SOFTWARE\Classes\TypeLib\{565783C6-CB41-11D1-8B02-00600806D9B6}\1.2\0\win32
>
>So, does the *\G indicate the registry section?
>SOFTWARE\Classes\TypeLib>or is that implied by References=
>
>Where can I find this and other possible values?
>

It is a form of 'data typing' values in a text format.

The "*\G" IIRC is to indicate what followed was a GUID. ... *\G{...}
In other data fields I've seen "*\A ... " which I think means "ASCII".
I think there is a "*\N ..." - number which appears too.

This is a common technique often used back in the day with "ini
formats". Not sure it is documented anywhere.

-ralph

Bob Butler

6/9/2011 7:09:00 PM

"ralph" <nt_consulting64@yahoo.net> wrote in message
news:orv1v6l258n8ggh9eib1tr4k1pg24lat7t@4ax.com...
> On Thu, 09 Jun 2011 08:43:12 -0700, BeeJ <nospam@nowhere.com> wrote:
>
<cut>
> 1.
>
> The VBIDE appears* to always use the ...
> \HKEY_CLASSES_ROOT\TypeLib\{guid}\<version>\<locale>\win32 node/key
> for Type Libraries.
>
> However, this information is always duplicated at ...
> \HKEY_LOCAL_MACHINE\SOFTWARE\Classes\TypLib\{guid}\ ...

It's not so much that the info is duplicated; HKEY_CLASSES_ROOT is a merged
view of
HKEY_LOCAL_MACHINE\Software\Classes and HKEY_CURRENT_USER\Software\Classes

Mayayana

6/9/2011 7:59:00 PM

|
| I figured out how to parse and find the path value in the registry.
| In this case I use this string to search
|
SOFTWARE\Classes\TypeLib\{565783C6-CB41-11D1-8B02-00600806D9B6}\1.2\0\win32
|

Didn't we talk about this exhaustively in the recent
past? As I recall I pointed out that the Typelib key
can be undependable, and I think Ralph filled in the
backstory on that. But like Ralph I've slept recently
and can't remember half of what I thought I knew. :)

So.... Your method is fine if you do it by hand, but don't
depend on it if you work programmatically. To be thorough
you need to enumerate the version subkeys. Example:
On my system HKCR\InternetExplorer.Application points
to HKCR\CLSID\{0002DF01-0000-0000-C000-000000000046}.
The default text there is "Internet Explorer(Ver 1.0)". The
ProgID key default value is "InternetExplorer.Application.1".
but the typelib path is here:

HKCR\TypeLib\{EAB22AC0-30C1-11CF-A7EB-0000C05BAE0B}1.1\0\win32
If I programmatically checked under

HKCR\TypeLib\{EAB22AC0-30C1-11CF-A7EB-0000C05BAE0B}1.0\0\win32
I wouldn't find a registered typelib.

In most cases you can enumerate the version key and
language key and you should be fine if you just take the
first hit. To be thorough, also check first for the specific
version you want, if that's relevant. (Language is nearly
always 0.) But some things will have multiple valid versions.
(Like msxml. On my system I have 4 versions of MSXML:
2.6, 3, 4, 6. The CurVer (current version) of Msxml.DOMDocument
is v. 1! The CurVer of Msxml2.DOMDocument is v. 3.)

And other things may have multiple version
keys with only one valid version. For instance, if you build
ActiveX controls and don't carefully unregister the versions
that VB registers on compile, different builds might show up
as different typelib versions. Those different keys may or may
not point to the same file and may or may not point to identical
typelibs.

ralph

6/9/2011 8:18:00 PM

On Thu, 9 Jun 2011 12:09:23 -0700, "Bob Butler"
<bob_butler@cox.invalid> wrote:

>
>"ralph" <nt_consulting64@yahoo.net> wrote in message
>news:orv1v6l258n8ggh9eib1tr4k1pg24lat7t@4ax.com...
>> On Thu, 09 Jun 2011 08:43:12 -0700, BeeJ <nospam@nowhere.com> wrote:
>>
><cut>
>> 1.
>>
>> The VBIDE appears* to always use the ...
>> \HKEY_CLASSES_ROOT\TypeLib\{guid}\<version>\<locale>\win32 node/key
>> for Type Libraries.
>>
>> However, this information is always duplicated at ...
>> \HKEY_LOCAL_MACHINE\SOFTWARE\Classes\TypLib\{guid}\ ...
>
>It's not so much that the info is duplicated; HKEY_CLASSES_ROOT is a merged
>view of
>HKEY_LOCAL_MACHINE\Software\Classes and HKEY_CURRENT_USER\Software\Classes
>

Good amplification.

I was avoiding Registry "views" and "hives" and just stick to - "If
you see it here, you'll see it there". <g>

microsoft.public.vb.general.discussion

References

Ian Post

ralph

Ian Post

Mayayana

Ian Post

Ian Post

ralph

ralph

Bob Butler

Mayayana

ralph

x Login to ForumsZone