Re: [MinGW-dvlpr] Fwd: [Mingw-users] Re: w32api uuid.lib generation for pocket pc

[Luke D. <cod...@ho...>]

----- Original Message ----- 
From: "Keith Marshall" <kei...@us...>
To: <min...@li...>
Sent: Saturday, May 20, 2006 10:27 PM
Subject: Re: [MinGW-dvlpr] Fwd: [Mingw-users] Re: w32api uuid.lib generation 
for pocket pc


> On Friday 19 May 2006 11:54 am, Earnie wrote:
>> I'm thinking we need to pull the libuuid.a library from our
>> distribution! We are distributing MS's original object library! What
>> are our distribution rights for uuid.lib?
>
[snip]
> Some have suggested use of an awk script, to extract registry
> information.  Michael has stated that perl would be better.  I would
> probably choose awk rather than perl myself, simply because I am more
> familiar with it; however, in this case I would suggest that *neither* is
> appropriate; once we've identified how to extract the required
> information from the registry, then I think we should provide our own
> implementation of an accessor routine, or suite of accessor routines,
> which will look up that information, in the end user's registry, at
> runtime.  That way, we avoid any issues of whether information extracted
> from my registry is valid in the context of your's, *and* we can now
> distribute our own libuuid.a, which we've developed cleanly, and without
> resorting to reverse engineering of Microsoft's uuid.lib.
>
> Regards,
> Keith.

Firstly, a user application cannot look up the value of e.g. IClassFactory 
at run-time because it would require traversing the entire subtree at 
HKEY_CLASSES_ROOT\Interface, which is far too slow. As for CLSIDs, COM 
already provides APIs to look these up using descriptive strings 
(CLSIDFromProgID()) although those strings are not quite the same as the 
names in the header files.

In the interest of continuing to provide some sort of libuuid, the attached 
Python script "gen_uuid.py" does the following:

1. It reads a file called new_uuid.c, and extracts the lines that are 
similar to the following:

/*DEFINE_GUID(CLSID_StdMarshal);*/
DEFINE_GUID(OLE_DATAPATH_PICT,0x2de0a,0,0,0xc0,0,0,0,0,0,0,0x46);

The former kind are interpreted as GUIDs that we don't know yet, and the 
latter kind are interpreted as known GUIDs.

2. It traverses the registry in HKEY_CLASSES_ROOT\Interface and HKCR\CLSID

3. If any of the unknown GUIDs in the input file were found in the registry, 
it updates these in a data structure.

4. The file is written again with updated GUIDs, along with a fixed header 
at the top (not derived from the input file)

The idea of this read/merge/write procedure is to allow developer A to run 
the script and check-in their changes, and later have developer B run the 
script without deleting entries that might be in developer A's registry but 
not developer B's registry. It is also designed to process multiple files in 
sequence. If anyone wants to rewrite this in Perl/C/etc. then be my guest 
:-)

The attached file new_uuid1.c shows the file before running the script, and 
was derived from uuid.c by doing a search-and-replace to convert the old 
reverse-engineered GUIDs into unknown GUIDs. The attached file new_uuid2.c 
shows the file after running the script on my PC (for ~10 minutes by the 
way). Most of the IID_* symbols are now filled in but only two CLSID values 
were found in the registry and the rest are unknown. Some of them might be 
in the registry in places I haven't searched yet, but I doubt it.

Luke