fun stuff

Hey all,

Here are a few more things that have come up recently:

1.) SHLoadInProc/SHEnableServiceObject (follow-up)

If the COPYDATASTRUCT you receive has dwData == 2, the cbData is set to 
20 (XP SP2). But sizeof(CLSID) == 16. That leaves room for another 
DWORD. So I tried:

struct LoadInProcData
{
     CLSID rclsid;
     DWORD dwUnknown;
};

I knew the CLSID had to come first because I had previously just casted 
lpData to a CLSID* and had succefully gotten the CLSID. A short test 
program resulted in the following values for dwUnknown:

1 - SHLoadInProc
2 - SHEnableServiceObject(clsid, FALSE)
3 - SHEnableServiceObject(clsid, TRUE)

That was almost too easy. Then again there is no app known to use 
SHEnableServiceObject, so there's no point in implementing it currently.


2.) SHFindFiles

As you might know, SHFindFiles doesn't work if Explorer isn't running. 
At least on most 2k/XP setups. Despite it being documented to return a 
BOOL, it returns REGDB_E_CLASSNOTREG if Explorer is not the shell. We 
had previously gotten it to work while an IE instance was running in the 
background, but I couldn't reproduce this any more. Maybe it's because 
of SP2. Either way, Regmon indicated that SHFindFiles is looking for a 
COM object, specifically CLSID_ShellBrowserWindow. I hope to have 
reduced the problem to the following line:

HRESULT hr = CoCreateInstance(CLSID_ShellBrowserWindow, NULL, 
CLSCTX_LOCAL_SERVER, IID_IUnknown, (LPVOID*)&pUnk);

This line returns S_OK under Explorer but REGDB_E_CLASSNOTREG if 
Explorer is shut down. I do not know whether fixing this will acutally 
fix SHFindFiles, but I think there's a good chance that the two are related.

Oleview.exe reveals that CLSID_ShellBrowserWindow is from shdocvw.dll, 
but it is apparently only registered when Explorer is running. Thus we 
must somehow get shdocvw.dll to register it. DllRegisterServer didn't 
help. A quick look at Dependency Walker reveals that the XP SP2 
explorer.exe only links to three shdocvw.dll functions (names from WINE):

RunInstallUninstallStubs, WinList_Init, WinList_Terminate

Unfortunately neither of those appears to register the desired COM 
object... a test app which called all possible combinations of these 
three functions resulted in no change whatsoever. Of course there's 
always the possibility that Explorer uses GetProcAddress or calls the 
register export through some other DLL - if there is a dedicated 
"register classes" export at all.


3.) SHChangeNotifyRegister

Apparently this neat function stops working if Explorer is not the 
shell. A program I wrote which uses it only receives notifications a) if 
Register was called while Explorer was the shell and b) while Explorer 
is still running. Once Explorer is shut down the notifications stop 
coming in. Restarting Explorer doesn't help, Register needs to be called 
again.

I will probably convert my program to use FindFirstChangeNotification - 
assuming that this works without Explorer. Call me naive, but I have 
always assumed that the change notifications are kernel object, since 
they are waitable after all. Thus I wonder where the connection to 
explorer.exe is.


That's all for now. Lots of fun stuff to mess with.

ilmcuts

__________________________________________________
Subscription options and archive:
http://www.freelists.org/list/shell-coding