Prev: Does anyone know where I can find info on RtlInitializeExceptionChain
Next: Mutex race?
From: glitteringsounds on 21 Apr 2010 03:16
Hello,

I need to write a stub(module), when given some PE (DLL/EXE) as
input , it should give the information that this PE is Win32 DLL/EXE
or COM DLL/EXE? I need it programatically to determine this.

Is there any windows APIs?

Regards
Usman
From: Jeroen Mostert on 21 Apr 2010 16:04
On 2010-04-21 9:16, glitteringsounds wrote:
> I need to write a stub(module), when given some PE (DLL/EXE) as
> input , it should give the information that this PE is Win32 DLL/EXE
> or COM DLL/EXE? I need it programatically to determine this.
>
Every executable implementing a COM server is a regular Win32 executable. An
in-process server (DLL) is fairly easily recognized: it will export a
DllRegisterServer() function you can get at with DllImport(). An
out-of-process server (in an .EXE) cannot be definitely recognized as doing
anything with COM, except heuristically: if the executable imports
CoRegisterGetClassObject() it's *probably* an out-of-process server, though
that's not guaranteed. Conversely, if it doesn't import
CoRegisterGetClassObject() that doesn't mean it's not a server. You can
always scan HKEY_CLASSES_ROOT for all servers, of course, but that takes a
while.

A better question is probably why you think you need this. What exactly do
you hope to accomplish with this information?

--
J.
From: glitteringsounds on 27 Apr 2010 09:20
On Apr 22, 1:04 am, Jeroen Mostert <jmost...(a)xs4all.nl> wrote:
> On 2010-04-21 9:16, glitteringsounds wrote:> I need to write a stub(module), when given some PE (DLL/EXE) as
> > input , it should give the information that this PE is Win32 DLL/EXE
> > or COM DLL/EXE? I need it programatically to determine this.
>
> Every executable implementing a COM server is a regular Win32 executable. An
> in-process server (DLL) is fairly easily recognized: it will export a
> DllRegisterServer() function you can get at with DllImport(). An
> out-of-process server (in an .EXE) cannot be definitely recognized as doing
> anything with COM, except heuristically: if the executable imports
> CoRegisterGetClassObject() it's *probably* an out-of-process server, though
> that's not guaranteed. Conversely, if it doesn't import
> CoRegisterGetClassObject() that doesn't mean it's not a server. You can
> always scan HKEY_CLASSES_ROOT for all servers, of course, but that takes a
> while.
>
> A better question is probably why you think you need this. What exactly do
> you hope to accomplish with this information?
>
> --
> J.
I have looked up PE file format closely..I found there a bit in Data
Directory index table called 'COM+ Runtime header'.

What about this..?
Will it'll be help full for deciding and declaring wheather PE is COM
or Win32...?
From: Leo Davidson on 27 Apr 2010 10:32
On Apr 27, 2:20 pm, glitteringsounds <muhammadusman.kha...(a)gmail.com>
wrote:

> I have looked up PE file format closely..I found there a bit in Data
> Directory index table called 'COM+ Runtime header'.
>
> What about this..?
> Will it'll be help full for deciding and declaring wheather PE is COM
> or Win32...?

Not really. Even if all COM+ EXEs have to have that header (and I
don't think that is true anyway), not all COM EXEs use COM+. In fact,
almost none of them use it.

What are you actually trying to achieve here? Why do you care if an
EXE is a COM server or not?

You can find out if an EXE is installed as a COM server by looking for
it in the appropriate parts of the registry under HKCR.

If you need to see if an EXE, which may not be installed, might be a
COM server you could see if it imports CoRegisterClassObject from
OLE32.DLL. (Of course, that will not be foolproof. It may use
GetProcAddress at runtime, or it may register COM objects but only in
exceptional circumstances and not normally be what you'd consider a
traditional COM EXE server.)
From: Jeroen Mostert on 27 Apr 2010 15:26
On 2010-04-27 15:20, glitteringsounds wrote:
> I have looked up PE file format closely..I found there a bit in Data
> Directory index table called 'COM+ Runtime header'.
>
It has nothing at all to do with COM+, or COM for that matter. This header
went unused until it was repurposed for .NET (which was originally born from
an effort to make COM more ubiquitous, and started off as a sort of COM++).
Unless you want to see if an executable is a .NET assembly, it's not going
to help.

--
J.
 | 
Pages: 1
Prev: Does anyone know where I can find info on RtlInitializeExceptionChain
Next: Mutex race?