Re: SHELL32: use structure defined in standard headers for advertised shortcut info

[Dmitry Timoshkov]

"Mike McCormack"  wrote:
> - LINK_ADVERTISEINFO buffer;
> - EXP_DARWIN_LINK buffer;

...
> - TRACE("magic %08lx  string = %s\n", buffer.magic, debugstr_w(buffer.bufW));
> - TRACE("magic %08lx  string = %s\n", buffer.dbh.dwSignature, debugstr_w(buffer.szwDarwinID));
> - if( (buffer.magic&0xffff0000) != 0xa0000000 )
> - if( (buffer.dbh.dwSignature&0xffff0000) != 0xa0000000 )

After reading your patch I inspected ShlObj.h from PlatformSDK and found out
the following:

typedef struct
{
    DWORD       cbSize;             // Size of this extra data block
    DWORD       dwSignature;        // signature of this extra data block
    CHAR        szTarget[ MAX_PATH ];   // ANSI target name w/EXP_SZ in it
    WCHAR       swzTarget[ MAX_PATH ];  // UNICODE target name w/EXP_SZ in it
} EXP_SZ_LINK, *LPEXP_SZ_LINK;
#define EXP_SZ_LINK_SIG                0xA0000001   // LPEXP_SZ_LINK (target)
#define EXP_SZ_ICON_SIG                0xA0000007   // LPEXP_SZ_LINK (icon)

Is it a better choice?

SHELL32: use structure defined in standard headers for advertised shortcut info

[Mike McCormack]

Dmitry Timoshkov wrote:
> After reading your patch I inspected ShlObj.h from PlatformSDK and found out
> the following:
>
> typedef struct
> {
>     DWORD       cbSize;             // Size of this extra data block
>     DWORD       dwSignature;        // signature of this extra data block
>     CHAR        szTarget[ MAX_PATH ];   // ANSI target name w/EXP_SZ in it
>     WCHAR       swzTarget[ MAX_PATH ];  // UNICODE target name w/EXP_SZ in it
> } EXP_SZ_LINK, *LPEXP_SZ_LINK;
> #define EXP_SZ_LINK_SIG                0xA0000001   // LPEXP_SZ_LINK (target)
> #define EXP_SZ_ICON_SIG                0xA0000007   // LPEXP_SZ_LINK (icon)
>
> Is it a better choice?

Well, it's clear as mud.  It appears Microsoft reluctantly documented 
these structures as part of their settlement with the DOJ, and had some 
highschool intern do it.

The values used when an advertised shortcut is created are 0xa0000006 
and 0xa0000007.  The contents of the blocks are the MSI Product ID and 
the MSI Component ID of the link target.

Clicking on the link then fires up MSI and installs the Component... I 
haven't done that part at all yet.  It uses several undocumented MSI 
functions.

0xa0000007 could be either EXP_LOGO3_ID_SIG or EXP_SZ_ICON_SIG, neither 
of which seems like a MSI product ID to me.  Further more, these should 
be accessed via the IShellLinkDataList interface.

So I think there's alot of work to be done here.... and for 
CLSID_ShellLink in general.  I've discovered that the Windows 2000 
version exports all of the following interfaces:

{000214ee-0000-0000-c000-000000000046}	IShellLinkA
{000214f9-0000-0000-c000-000000000046}	IShellLinkW
{0000010b-0000-0000-c000-000000000046}	IPersistFile
{00000109-0000-0000-c000-000000000046}	IPersistStream
{000214e8-0000-0000-c000-000000000046}	IShellExtInit
{000214e4-0000-0000-c000-000000000046}	IContextMenu
{000214f4-0000-0000-c000-000000000046}	IContextMenu2
{bcfce0a0-ec17-11d0-8d10-00a0c90f2719}	IContextMenu3
{00000122-0000-0000-c000-000000000046}	IDropTarget
{000214eb-0000-0000-c000-000000000046}	IExtractIconA
{000214fa-0000-0000-c000-000000000046}	IExtractIconW
{45e2b4ae-b1c3-11d0-b92f-00a0c90312e1}	IShellLinkDataList
{00021500-0000-0000-c000-000000000046}	IQueryInfo
{37d84f60-42cb-11ce-8135-00aa004bb851}	IPersistPropertyBag
{fc4801a3-2ba9-11cf-a229-00aa003d7352}	IObjectWithSite
{6d5140c1-7436-11ce-8034-00aa006009fa}	IServiceProvider
{89bcb740-6119-101a-bcb7-00dd010655af}	IFilter

We only implement the first 4.

Looking round further, it looks as though the SCF_* flags defined at the 
top of dlls/shell32/shelllink.c are the same as the flags to 
IShellLinkDataList::GetFlags

shell32 is really a POS.  It's the only remaining bit of Windows that 
isn't widely understood, and I'm sure Microsoft is happy with that.

Mike

SHELL32: use structure defined in standard headers for advertised shortcut info

[Mike Hearn]

On Wed, 16 Mar 2005 12:12:47 +0900, Mike McCormack wrote:
> We only implement the first 4.

Some of those are only needed by Explorer/the shell though, I doubt it's
necessary to implement them to run the apps (unless you want to run
Explorer of course :)

SHELL32: use structure defined in standard headers for advertised shortcut info

[Kuba Ober]

On środa 16 marzec 2005 08:27 am, Mike Hearn wrote:
> On Wed, 16 Mar 2005 12:12:47 +0900, Mike McCormack wrote:
> > We only implement the first 4.
>
> Some of those are only needed by Explorer/the shell though, I doubt it's
> necessary to implement them to run the apps (unless you want to run
> Explorer of course :)

Of course right now that's not a priority, but maybe someone will like to run 
some Explorer replacements that may be likely to use those APIs.

Cheers, Kuba

SHELL32: use structure defined in standard headers for advertised shortcut info

[Jakob Eriksson]

Mike Hearn wrote:
> On Wed, 16 Mar 2005 12:12:47 +0900, Mike McCormack wrote:
> > We only implement the first 4.
>
> Some of those are only needed by Explorer/the shell though, I doubt it's
> necessary to implement them to run the apps (unless you want to run
> Explorer of course :)

Yes, probably, but what about the Explorer replacements like
Directory Opus and Total Commander, anybody ran those in Wine?

regards,
Jakob