I've created a Windows library with an implementation of nsIModule (and nsIProtocolHandler) a while ago. I've only recently got round to debugging it some more, but FireFox doesn't run my library any more. I've tried to register my module again, with regxpcom and deleting xpti.dat and compreg.dat, but my contract-id doesn't get listed. If I try debugging firefox or regxpcom, it appears like my DLL doesn't get loaded (where they used to call NSGetModule of my DLL).
Has something changed to the registration process? Do I need to provide a .xpt file? It wasn't required before, and I don't need/use any interfaces of my own, so if I do it would be an empty type library anyway...
http://xxm.svn.sourceforge.net/viewvc/xxm/trunk/Delphi/gecko/
I've done a bit more searching, and found out what I need is to create an XPI file.
https://developer.mozilla.org/en/Creating_XPI_Installer_Modules
Related
The situation is following.
These dlls are loaded in a process:
c:\abc\foo.dll
c:\abc\bar.dll
c:\zxc\foo.dll
And the process is located in c:\abc\.
I'm loading c:\zxc\bar.dll. It implicitly links to foo.dll. And it should link to c:\zxc\foo.dll, which is in same folder.
I load it with
LoadLibraryExA("c:\\zxc\\bar.dll", NULL, LOAD_LIBRARY_SEARCH_DLL_LOAD_DIR)
If c:\abc\foo.dll is not loaded in process, then c:\zxc\foo.dll gets properly loaded and c:\zxc\bar.dll links to it.
But if c:\abc\foo.dll is loaded, then c:\\zxc\\bar.dll links to c:\abc\foo.dll instead of c:\zxc\foo.dll (even if c:\zxc\foo.dll is already loaded in the process). This was confirmed with help of "Show loader snaps" checkbox of Global Flags.
How do I work around it?
The bar.dll is third party so I cannot implement DELAYLOAD in it.
And I cannot prevent loading c:\abc\foo.dll to the process.
I'm thinking of hooking ntdll!LdrpFindOrMapDll, but it seems unreliable and I will have to test this thoroughly in all supported Windows versions, so I'm first searching for a simpler workaround.
I think you can try to make your foo.dll a side-by-side assembly, and reference it in your dll manifest.
This is how, for instance, Common Controls of 5 and 6 versions and Visual Studio different C runtime versions supposed to coexist in the same process.
If this works, don't necessarily need to install your foo.dll to WinSxS folder, maybe you can do with private assemblies.
If side-by-side assemblies won't work for you, then any hooking solution is complex and risky.
Think of it: number of calls like GetModuleHandleW(L"foo.dll") supposed to return proper one DLL handle in each context!
(and side-by-side assemblies do this trick if bar.dll code is compiled with ISOLATION_AWARE_ENABLED defined)
I'm trying to inject a DLL to a new process using the latests 32 bit Detours library.
http://research.microsoft.com/en-us/projects/detours/
It worked for me in the past but after a change in the DLL, it stopped working for all processes. When I resume the process I get a message box saying
The application was unable to start correctly (0xc000007b). Click OK to close the application.
I've recreated this with a plain and empty DLL injected that has no dependencies other than kernel32.dll. With other executables it works perfectly.
Any idea why this can happen?
It turned out that the problem was the the DLL I was injecting using Detours did have any exports. Once I added a dummy export, everything worked perfectly.
I don't know what the documentation looked like at the time you encountered this but based on a dummy export apparently working around the problem and the current documentation, you probably missed some requirements stated in Detouring 32-bit and 64-bit Processes. Unfortunately it says to do things without explaining how the pieces fit together.
Detours expects your helper DLL to export DetourFinishHelperProcess with ordinal 1. This isn't a function you define yourself. It will get compiled into your DLL as a result of calling DetourIsHelperProcess in your DllMain function as shown in the Using Detours sample.
Ok, I went through great lengths but I finally got my integration to quickbooks working on my VB6 application. It works perfectly on my build machine. I actually installed the qbdsk11 on my build machine and worte and tested the code. The ONLY new reference in the project is the QBFC11.dll.
So, I added the QBFC11.dll to my innosetup, told it to do a regsvr on the dll, and hoped this was enough.
NOT.
First, during install, I get a failure to register the dll. Apparently, this DLL isnt meant to be registered?
But the .DLL was put in Windows System32, so I tried my program anyways...
NOPE. Doesnt work. I get a runtime 91, about an object variable not set. Which makes sense, if it cant create the object.
So, for grins, I moved a copy of the .DLL into the program folder, next to my executable.
Same thing. Runtime error 91.
So, i then grab the whole qbsdk11 installer and install it on this machine. I figure I can make it an additional download for people who want to use this extra functionality.
But no, even with the whole SDK installed, I still get the same runtime error.
I have not been able to find any CLEAR information on how to proceed. I'd prefer for this to be part of my base install. But apparently something still just isn't right.
What did I miss? How do I fix this? I don't even know what to try next.
If you're using QBFC11, you must install the QBFC11 redistributable components with your application. You can find instructions on how to do this in the QBSDK Programmer's Guide in the section titled Redistributing SDK Components With Your Application, subsection Using Installers and Merge Modules.
The most likely cause of the runtime error you're currently getting is the manipulation of the QBFC11.DLL that you did before you installed the SDK. I would start again with a clean OS image so that you can get the proper procedure down.
I have a VB6 program which tries to run a DLL written in C#.
This DLL has a COM interface so I can create an object of a class in it with "CreateObject".
The problem is that it runs and works well when I run it from the VB6 IDE, but when I make an EXE and try to run it, it throws the exception:
"Automation error. The system cannot find the file specified (-2147024894)."
Why is it happening and how can i solve it?
Look at Project, References in the IDE and look which dll or ocx file belongs to the object you are referencing with CreateObject (the Object Manager might also help to find out).
This dll file must be available when the exe is compiled, too. Usually, you need to have it registered with regsvr32.exe.
A technique I use to figure issues of this type is to open the add reference dialog in Visual Basic 6. I scroll the list of available COM Libraries and see if the problem DLL is listed. If it is then CreateObject should work, you should be able to assign it do a variant variant and use late binding to access it's members.
In addition try temporally set a reference to the variable and instead of using CreateObject use the = New and see what error messages, if any, it gives you. Generally I found them to be more informative then the ones thrown by CreateObject.
Finally it would help if you post the reason why you are choosing to use CreateObject instead of setting of a reference. If the DLL is a known object that will be continually used by the program then a reference should be set and early binding generally used.
Finally it may be that the error is resulting from a dependency of the C# COM DLL not the DLL itself. If for example I was to take a Com Library and properly register it but it relies on the COM Library Widget2000 and it NOT registered then it will throw the automation error. Especially if you are testing the EXE in it's installed environment and not the environment in which you complied it.
For example suppose I have a CAD program written in VB6 and I have source tree that begins with MyCAD. THe exe is in MyCAD/MainEXE and the shape library is in MyCAD/ShapeLibrary. I run the IDE everything is fine. Then I make my setup and goto my test machine and install it and it error on the creation of shapelibrary.
The first thing I would do it check if MainEXE will run straight out of the MainEXE directory of my source tree. That test will eliminate whether it is a install issue or a quirk of the IDE vs complied version. Then I would look at the setup and see what not being registered. Also look at either the source for the C# library or the setup for the library and see what dependencies it needs. Since it a complied COM DLL you should be able to use a dependency walker tool to see what COM references it needs. Finally make sure the correct version of the .NET framework is installed.
If you are compiling the C# DLL on your test machine - make sure you have ticked the register for COM Interop setting. If you are not compiling on the same machine you need to run RegAsm with the /codebase option.
try compiling it as an installer and include the dll/com that you use in the compilation of the installer package so that the dll/com that you use will be include in the compilation of your exe.., and install it in the windows not just copy past it.
I have an application with a plug-in architecture that is using Boost.Threads as a DLL (specifically, a Mac OS X framework). I am trying to write a plug-in that uses Boost.Threads as well, and would like to link in the library statically. Everything builds fine but the application quickly crashes in my plug-in, deep within the Boost.Threads code. Linking to the DLL version of Boost.Threads seems to resolve the problem, but I'd like my plug-in to be self-contained.
Is it possible to have two instances of Boost.Threads with such a setup (one as a DLL, one statically linked in another DLL)? If so, what might I be missing to make the two instances get along?
Once my team faced a similar problem. For reasons I will not mention at this time, we had to develop a system that used 2 different versions of Boost (threads, system, filesystem).
The idea we came up with and executed was to grab the source code of both versions of Boost we needed, and then tweak one of them to change the symbols and function names to avoid name clashing.
In other words, we replaced all references to the name boost for bubbles inside the sources (or some other name) and also made changes to the compilation so it would build libbubbles instead of libboost.
This procedure gave us 2 sets of libraries, each with having their own binaries and header files.
If you looked at the source code of our application you would see something like:
#include <bubbles/thread.hpp>
#include <boost/thread.hpp>
bubbles::thread* thread_1;
boost::thread* thread_2;
I imagine some of the guys here already faced a similar situation. There are probably better alternatives to the one I suggested above.