The MASM Forum

General => The Campus => Topic started by: Zen on July 02, 2015, 09:51:57 AM

Title: shell.dll exports question
Post by: Zen on July 02, 2015, 09:51:57 AM
I'm wondering,...this is kind of a bizarre question,...
I was playing around with Japheth's COMView, and I found this COM Class (actually the CLSID),...and, it looked interesting,...
It's name is: COpenControlPanel,...and it's supposedly exported from shell.dll,...(this is the [Default] location string associated with the  InprocServer32 SubKey).   
When I run dumpbin on shell.dll with the /EXPORTS option in the command line, I get an enormous number of exported functions,...and, most of them are exported by ordinal,...but, no, COpenControlPanel.   
...So, I'm wondering,...is there a way to determine which ordinal is actually COpenControlPanel ???

...Or, maybe,...I should just write a COM Client app and call CoCreateInstance using the CLSID (or, maybe using a Class Moniker),...
What do you think ???
Title: Re: shell.dll exports question
Post by: dedndave on July 02, 2015, 10:37:27 AM
COM interfaces won't show up in exports because they are virtualized methods
i.e., they might look more like data than code, until you call them
Title: Re: shell.dll exports question
Post by: Yuri on July 02, 2015, 02:18:48 PM
COM server DLLs export a function named DllGetClassObject. It's used to obtain a ClassFactory object, which in turn is used to create the object you need. CoCreateInstance probably does all this behind the scenes.
Title: Re: shell.dll exports question
Post by: Zen on July 03, 2015, 04:23:51 AM
Quote from: DAVE!!!COM interfaces won't show up in exports because they are virtualized methods.
Thanks, DAVE,...I didn't know that,...:icon_eek:
Title: Re: shell.dll exports question
Post by: dedndave on July 03, 2015, 04:26:53 AM
i think you probably did know it - it just hasn't sunk in, yet - lol
remember - COM interfaces are essentially "structures" filled with code vectors   :t
they're not referenced by name, but by registered CLSID
Title: Re: shell.dll exports question
Post by: Zen on July 03, 2015, 04:29:32 AM
DAVE !!!
...And, all this time I thought you were merely a 'Device Context groupie',...:bgrin:
Title: Re: shell.dll exports question
Post by: dedndave on July 03, 2015, 04:46:50 AM
i understand just enough of both to be hazardous - lol
Title: Re: shell.dll exports question
Post by: Zen on July 03, 2015, 06:04:00 AM
...Well,...again,...thanks,...DAVE !!!
You're so well informed,...I wish I had your brain,...
Title: Re: shell.dll exports question
Post by: FORTRANS on July 03, 2015, 06:55:38 AM
Zombie?
Title: Re: shell.dll exports question
Post by: K_F on July 07, 2015, 04:53:45 PM
A question on this...

Does a COM object register itself every time it runs, or only once on installation.
Just thinking that if it only registers it's GUI on running then DllGetClassObject/CoCreateInstance would likely fail, or do these two functions load the DLL for you ? :icon_confused:
Title: Re: shell.dll exports question
Post by: Zen on July 08, 2015, 06:21:31 AM
Hi, VAN,   
Typically a COM CoClass (an InprocServer32 DLL) is only registered once when it is installed. The code (Register Server (https://msdn.microsoft.com/en-us/library/windows/desktop/ms691213(v=vs.85).aspx)) makes a number of Registry entries that the COM Library uses to determine the location of the server. The client application calls CoCreateInstance (https://msdn.microsoft.com/en-us/library/windows/desktop/ms686615(v=vs.85).aspx), using the CLSID, and the SCM (https://msdn.microsoft.com/en-us/library/windows/desktop/ms685150(v=vs.85).aspx) loads the COM DLL (if it is an InprocServer (https://msdn.microsoft.com/en-us/library/windows/desktop/ms683835(v=vs.85).aspx)) and, returns a pointer to the Com Class's Virtual Function Table.