Sign in to follow this  
Followers 0
billym

help identifying com files programmatically?

5 posts in this topic

I am in the need for a function that looks at files and if they could be a com object that needs to be registered, it will tell me and or do so. I am under the impression that there is entry points that only exist in com objects that I might be able to use to identify if the exe/dll/ocx has the need for registration on the local machine. Maybe even the "QueryInterface" call might help. Just do not know how to implement.

Share this post


Link to post
Share on other sites



The 4 functions commonly exported by COM servers are:

DllCanUnloadNow

DllGetClassObject

DllRegisterServer

DllUnregisterServer

The Register/Unregister functions are what regsvr32.exe call to register/unregister a COM server. You should be able to safely use DllCall() on DllRegisterServer. If it's a COM server, it'll be re-registered (Should cause no harm). If it's not a COM server, DllCall() will fail (unless the DLL happens to export that function for other reasons).

Share this post


Link to post
Share on other sites

The 4 functions commonly exported by COM servers are:

The Register/Unregister functions are what regsvr32.exe call to register/unregister a COM server. You should be able to safely use DllCall() on DllRegisterServer. If it's a COM server, it'll be re-registered (Should cause no harm). If it's not a COM server, DllCall() will fail (unless the DLL happens to export that function for other reasons).

Sounds great, just kinda concerned about the excessive registering of com objects on a machine. I am writing a au3 script to dynamically create the building of other au3 scripts that will install and if necessary, register files only if needed. The logic is to go through specific sub/directories that I have layed out and identify the files that reside in them. Then use the above logic to check for the need for registration on the machine they get installed on (are they com or not), if so, make sure that after the installfile command for that file is written to the au3 script, to add the command to register it as well. Once completed it will compile a ready to run exe. What do you think? Given that my collection of files to install are constantly changing, could this become a major concern ? What happens if I have a working file registered already on this machine and I use the process above on a newer version of the file that may contain missing/modified functionallity?

If these are not concerns then I am all for it, otherwise I really need a passive way to check.

I know there must be a way, the program com explorer shows dynamically shows an option to register/unregister in the context menu when you right click on a com object only.

Share this post


Link to post
Share on other sites

The alternative is more complex. You can use DllCall() and the Windows API functions LoadLibrary, GetProcAddress and FreeLibrary to load the DLL and then look up a function in the DLL by name with GetProcAddress. If the return value of GetProcAddress is non-NULL, the function exists in the DLL. Finally close the library with FreeLibrary.

Off the top of my head (Tested):

Func _DoesDllFunctionExist($sDll, $sFunction)
    Local $hKernel = DllOpen("kernel32.dll")
    Local $aDll = DllCall($hKernel, "hwnd", "LoadLibrary", "str", $sDll)
    If @error Or Not $aDll[0] Then
        DllClose($hKernel)
        Return 0
    EndIf

    Local $nRet = 0
    Local $aFunc = DllCall($hKernel, "ptr", "GetProcAddress", "hwnd", $aDll[0], "str", $sFunction)
    If Not @error And $aFunc[0] Then $nRet = 1

    DllCall($hKernel, "none", "FreeLibrary", "hwnd", $aDll[0])
    DllClose($hKernel)
    Return $nRet
EndFunc

You would use it like so:

Local $nResult1 = _DoesDllFunctionExist("user32.dll", "SendMessageA")
Local $nResult2 = _DoesDllFunctionExist("user32.dll", "SendMessageskljdfkjf")
MsgBox(0, "", $nResult1 & @CRLF & $nResult2)

That should print:

1

0

You'll want to check for DllRegisterServer at the very least.

Share this post


Link to post
Share on other sites

The alternative is more complex. You can use DllCall() and the Windows API functions LoadLibrary, GetProcAddress and FreeLibrary to load the DLL and then look up a function in the DLL by name with GetProcAddress. If the return value of GetProcAddress is non-NULL, the function exists in the DLL. Finally close the library with FreeLibrary.

Off the top of my head (Tested):

Func _DoesDllFunctionExist($sDll, $sFunction)
    Local $hKernel = DllOpen("kernel32.dll")
    Local $aDll = DllCall($hKernel, "hwnd", "LoadLibrary", "str", $sDll)
    If @error Or Not $aDll[0] Then
        DllClose($hKernel)
        Return 0
    EndIf

    Local $nRet = 0
    Local $aFunc = DllCall($hKernel, "ptr", "GetProcAddress", "hwnd", $aDll[0], "str", $sFunction)
    If Not @error And $aFunc[0] Then $nRet = 1

    DllCall($hKernel, "none", "FreeLibrary", "hwnd", $aDll[0])
    DllClose($hKernel)
    Return $nRet
EndFunc

You would use it like so:

Local $nResult1 = _DoesDllFunctionExist("user32.dll", "SendMessageA")
Local $nResult2 = _DoesDllFunctionExist("user32.dll", "SendMessageskljdfkjf")
MsgBox(0, "", $nResult1 & @CRLF & $nResult2)

That should print:

You'll want to check for DllRegisterServer at the very least.

You rock! will try it as soon as I get back to my dev machine.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0