|
|
Dears friends,
I want to develop an application.
The input for the application is a COM dll filename.
The application will display (output of the application) whether the input COM dll is a registered one or not.
Could you please tell me how can i do this?
I mean how to identify the DLL is a registered one or not.
Regards,
Krishnakumar
|
|
|
|
|
It's not going to be easy. A dll get's registered by writing a registry entry with a GUID that points to the DLL. I'm not aware of any information that is the other way around.
For the ATL wizard DLLS, you could load the resources, search for GUIDs, and look them up, but that only works if people have used the ATL classes. Not always true...
About the only way I can see is to brute force it, by enumerating all the HKCR\CLSID subkeys, and see if any of them end up pointing to your DLL.
It can also be a nit more complex... They may not specify a full path, and may instead use just "mydll.dll", and let windows fill in the path for it.
Not much joy for you, sorry.
Iain.
|
|
|
|
|
Thanks for your information.
|
|
|
|
|
In addition to Iain's reply:
I don't see any other way than walking through the registered COM servers below the HKCR/CLSID registry key.
It also depends on what you mean by "registered".
Even though the server may be registered in terms of there is an existing entry in the registry below the HKCT/CLSID, its typelib and interfaces may not be registered properly. If you want to detect this as well you're in for a lot of grunt work.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
Thanks for your information.
By the word "registered", I mean that whether the thing "regsvr32 mydll.dll" had been done or not.
|
|
|
|
|
Just to add... All that regsvr32 does it to look for a RegisterServer exported function in the DLL. What that function does is completely up to the writer of that DLL. It could do a LOT of things (typelibs, interfaces, registering its interface with various shell places...).
You may need to go back to basics, and ask what *you* mean by registered, and why you care. There may be a better method of getting to the solution of the actual problem you face.
Iain.
|
|
|
|
|
Krishnakumartg wrote: By the word "registered", I mean that whether the thing "regsvr32 mydll.dll" had been done or not.
Ok.
Let us elaborate on this for while...
Like Iain said, what "regsvr32" does is simply load the .dll-file with ::LoadLibrary(), get the entry address of the exposed function DllRegisterServer() with ::GetProcAddress() and finally call DllRegisterServer() in the library.
What that function does is entirely up to the library.
In case of COM servers in DLLs, the DllRegisterServer() function is assumed to add information about the objects and interfaces exposed from the library into the registry.
There's no guaranteed way of knowing what COM servers, interfaces and/or their GUIDs just by looking into the library. Different COM servers may be created with different tools, they may or may not have the typelibrary included as a resource in the library.
Even if you walk through the registry tree below the HKCR/CLSID key and enumerate all registered servers, you may find servers that reside in files with the same name as the one provided to the application, but you have no clue whether this might be a later version if the paths differ.
You also have to consider what to do if you come to the conclusion that the DLL provided to the application has not been registered.
Are you supposed to register it? Then you can save a lot of trouble and simply register it without checking whether it was previously registered or not.
Is the user supposed to figure out if this DLL should be registered? Based on what information? How could the user possibly know?
My point is that there's no safe way of figure out whether a certain DLL has been "registered" or not. And even if there was, it's unclear what should be done with the file.
BUT, if you have a handful of COM servers and you know their IDs and interfaces, you could try to create each one of them and if the creation fails with the error REGDB_E_CLASSNOTREG you know that it has not been registered yet.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
Hi all,
I've build the whole solution of one of my C++ project in release mode. Compilation is fine, but when the exe is building it says that one of file is missing and Interface not registered
Can someone tell me how to solve this question.
Thanks a lot
I appreciate your help all the time...
CodingLover 
|
|
|
|
|
I've never seen this message. Do you have any custom build steps in your project?
Iain.
|
|
|
|
|
CodingLover wrote: I've build the whole solution of one of my C++ project in release mode.
So you're able to build the debug version without errors?
Try to find out what the differences are..
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
Actually I can compile in debug as well as release. But I cannot build it.
I appreciate your help all the time...
CodingLover
|
|
|
|
|
CodingLover wrote: Actually I can compile in debug as well as release. But I cannot build it.
That's contradiction in term as compiling is part of the build process.
Now I know the project can be successfully compiled in both debug and release version.
Are you able to link without errors?
When do you get this error?
Please be specific. You may paste the surrounding lines from your output window in your reply.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
Roger Stoltz wrote: That's contradiction in term as compiling is part of the build process.
Now I know the project can be successfully compiled in both debug and release version.
Are you able to link without errors?
Yes I can build any project in Debug or Release mode without any errors. But when I build the solution it gives an error, like this.
Building file 'E:\Test\output\Setup.msi'...
ERROR: Could not find file 'D:\Project\Starter\app.config' 'Interface not registered'
Please help me, I\m wired with this error for two days now. 
I appreciate your help all the time...
CodingLover
|
|
|
|
|
Sorry, but I don't think I can help you with this.
It looks like the problem occurs when you're building the installation package and I haven't done that a lot. I thought the "interface not registered" was about a COM interface.
I suggest you post a new question in the forum and explain your problem more detailed.
Be sure to put something like "error when building installation package" in the subject line in order not to misguide people who are trying to help.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
|
CodingLover wrote: Actually I fix the problem
Very good.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
Hi all
We have a situation with our custom TSP and an application . The TSP is a Telephony service provider which provides service to MS dialer . The issue is when the PC is restarted svchost.exe (which is active due to starting of TSP )consumes 50% CPU and another application X which commonly shares registry entries with TSP take long time . After 5 to 10 minutes the CPU load comes down and the application starts . The issues seems to be , as mentioned above , with the concurrent access of common resources (registry etc) by the TSP + application X . The worst case scenario is : Application X , as its unable to access registry , forgets the old configuration and a configuration application is started - which calls for trouble as a technician visit to site is mandatory in most cases . The point is : Application X is always part of Start menu and the TSP is started by service host as a service. I am searching for ideas to unblock this situation . Whats the best way to make svchost.exe and Application X not to fight for recources at the same time ?
1. Is its advisible to mutex lock the code surrounding the registry access ? (will it solve or worsen the situation ..!?)
2. Is there anyway we can make application X to be started only after starting of all services and other applications ? ie is there any way to prioritize the starting order of processes?
thanks
redindian
|
|
|
|
|
|
Hi
I am trying to check for the existance of the file "Microsoft.VC80.CRT.manifest" within a user defined folder
to try and find it i am using
dwResult = SearchPath(lpbPath,lpbFilename,lpbExt,dwBufferSize, szBuffer, &lpbPEnd);
where lpbFilename = "Microsoft.VC80.CRT"
and lpbExt = ".manifest"
lpbPath with be a user defined path passed to the function
however nothing is returned,i use this function to search for traditional file type (i.e something.ext) and this works fine
can anyone help at all
thanks
simon
|
|
|
|
|
Try BOOL PathFileExists(LPCTSTR pszPath);
Somethings seem HARD to do, until we know how to do them.
 _AnShUmAn_
|
|
|
|
|
_AnShUmAn_ wrote: Try BOOL PathFileExists(LPCTSTR pszPath);
thanks
|
|
|
|
|
Hi All,
I am having huge C++/MFC project. from that multiple DLLs is creating but when i am trying to load a DLL using LoadLibrary funtion than it gives an error when it reaches on the following line
ASSERT(AfxGetThread() == NULL);
can any body please tell me why it is happaning.
thanks
Bankey
|
|
|
|
|
bankey1010 wrote:
ASSERT(AfxGetThread() == NULL);
You may get this assertion in a thread spawned with any other function than AfxBeginThread(). It's a common mistake to create threads with e.g. CreateThread() even though the MFC framework is used.
Verify that all secondary threads are created with AfxBeginThread().
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
Maybe the following note on AfxGetThread() documentation [^] would be useful
[Note] Note:
If you are porting an MFC project calling AfxGetThread from Visual C++ versions 4.2, 5.0, or 6.0, AfxGetThread calls AfxGetApp if no thread is found. In Visual C+ .NET and later, AfxGetThread returns NULL if no thread was found. If you want the application thread, you must call AfxGetApp.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
