I have dll project in Visual Studio 2012, which is compiled with /MT (static multi-threaded runtime library). It also links third-party static lib, also compiled with /MT (library A), no problem so far.
The problem comes with another static lib (library B), which is unfortunatelly compiled with /MD. In my dll, i need to link both and there is no alternative to any of them (and I cannot recompile them with different option). I was able to successfully link everything together, but now I have problems with memory allocation and deletion - sometimes it fails to delete allocated object, sometimes another weird errors occurs. I believe it's caused by mixed memory managment functions, used by different parts of my dll - when new is called, object is created in library B, but when delete is called, it tries to release memory using different set of functions-, but I might be wrong.
So my question is, is this really caused by mixed memory-managment functions? And if so, is there any way to get this work together?
The only solution I think of is to wrap library B in another dll compiled with /MD and then use it from original dll to ensure different memory managment functions will be used. I'm not sure, if this would help and I would like to avoid it.
You already seem to have understood the cause of the problems you're seeing, and it is described on MSDN as follows
If it's really not possible to get all your linked libraries to use the same version of the CRT, then your only possible choice is to avoid passing CRT objects across the boundaries of these modules. Whether or not you can do this with your scenario is entireley dependent on your application. The crucial point in the above article is this sentence:
If you design your DLL so that it passes CRT objects across the boundary or allocates memory and expects it to be freed outside the DLL, you restrict the DLL users to use the same copy of the CRT library as the DLL. The DLL and its users use the same copy of the CRT library only if both are linked with the same version of the CRT DLL.
I know you've stated that it is not possible to obtain or build compatible modules to link to your application but I would recommend that you revisit this exhaustively and avoid mixing different CRT libraries at all costs.
Related
I need to write a program that uses some COM objects, accessed from the python comtypes package. I use the clsid and/or progid to create and use them. These objects are provided by a third party, and normally they are installed with a normal installer (setup.exe or MSI file).
Let's suppose that these DLL files have a license that allows me to ship them together with my program. Is it possible to load these DLL files into memory, and use them from a portable app without actually registering them? Or alternatively, can I register them from my program?
A related question is this: how to determine the chain of DLL files that are needed to create a given COM object? (Other than trial and error.)
Background: in reality, there are multiple libs and the main problem is that I do not want the users to run 4 different installers before they can start the actual program. That would be too difficult for an average user.
You're asking a lot of questions here. There are a lot of ways to accomplish what you're trying to accomplish, and it's hard to answer such a broad set of questions. If you have specific questions on how to do a specific thing, please start new posts for those.
That said, I will try to give you some information to help you figure out what you need/want to do.
Can you use a COM DLL without registering it?
Yes. There are several ways, depending on the needs of the COM DLL and the platform you're using. However, some options won't always work, and other options are very challenging.
DllGetClassObject - In some cases, depending on the COM object you're trying to load, you can just load the DLL, call the DllGetClassObject function directly, and use the returned IClassFactory to create your object. This is the easiest way -- if it works. If the class you create requires that the DLL be registered (maybe it does a CoCreateInstance internally, or maybe it needs proxy support), this won't work for you. To determine if this will work, it's either trial-and-error, or you have to ask the developer of the COM DLL.
Registration-free COM - This is how it's done in .NET. I'm not sure if you can do anything like this easily in Python.
CoRegisterClassObject - If you are going to create your own registration-free COM implementation, this function is going to be critical. I believe this is a fundamental implementation detail for Microsoft's registration-free COM. However, be aware that this would be a very challenging thing to do, and it would require a very good understanding of COM.
Can you register a COM DLL from your program?
Yes. There are a few ways. However, you are likely to run into security issues here -- typically, COM components register themselves in HKEY_LOCAL_MACHINE, and you typically need admin rights to write here. Some COM components/installers are designed to register themselves in HKEY_CURRENT_USER, which would get around the security thing. However, you may have no control over where a component registers itself, and even if you do, registering in HKEY_CURRENT_USER isn't a perfect solution.
regsvr32.exe - One option is to programmatically invoke regsvr32.exe on the DLL.
DllRegisterServer or DllInstall - If a COM DLL can be registered with regsvr32.exe, then it has at least one of these functions exported. You can load the DLL manually and call these functions just like regsvr32.exe does. DllInstall is less common than DllRegisterServer. If DllInstall is present, it may give you the option of installing in HKEY_CURRENT_USER. If not, you have to just do whatever DllRegisterServer does, since there are no options you can provide to that function.
Write the registry values yourself -- If you can figure out all the registry settings that are needed, there's nothing stopping you from putting them into the registry manually. This would get around the HKEY_LOCAL_MACHINE/HKEY_CURRENT_USER issue -- you can write them wherever you like (but HKEY_LOCAL_MACHINE still probably requires admin rights).
regedit.exe - Another way to write the registry values yourself is to store them in a .reg file and call regedit.exe to merge them.
How do you determine dependencies of a DLL?
Ideally, the developer of that DLL knows and can tell you. That's the only way that's truly fool-proof.
For COM dependencies, it may be impossible to figure this out any other way than asking the developer or trial-and-error. This is because a COM dependency may exist simply because some code in the DLL just calls CoCreateInstance to create some third-party COM object, and since this is something that is only expressed in source code, there is no metadata on the DLL that will help you find these dependencies.
The above is also true for any dynamically-loaded dependencies. For example, if some code just calls LoadLibrary directly, there is no way for you to determine the dependency from the outside.
For statically-loaded dependencies, you can use tools like Dependency Walker. Note that a lot of the dependencies you will see are system dependencies -- you don't want to include, for example, user32.dll and kernel32.dll because these are installed with Windows.
How do you install third-party dependencies?
If you know exactly what files to write, where to write them and what registry settings (etc) need to be applied, you can do all of that yourself. For some dependencies, it can be easier to just include the third-party installer in your installer and just execute it silently. Many installers support a silent mode for just this reason. A good example of this is the Visual C++ runtime (msvcrt*.dll) -- many applications need this dependency, and many installers just include Microsoft's installer as a part of their distribution, and the primary installer just calls the secondary installers silently.
I'm developing a shared library in C++ under Linux.
Is there a way from the shared library code to reload itself when a new build is available for example?
I was thinking of using dlclose and dlopen to reload but the former needs a handle which is accessible to the running process only.
Any idea how to retrieve that handle from the shared library code? Any better solution to the whole idea?
I understand hot swapping is dangerous but this will make development and testing much more easier.
When you rebuild a shared library its exported symbol addresses may change.
Hence, when reloading a shared library, all symbols its users import must be re-resolved.
Objects with virtual tables residing the shared library must be destroyed before unloading the shared library1.
If the library was loaded automatically by ld.so you cannot reload it.
If the application loaded the shared library using dlopen, the same code must be run again to re-load the library and re-resolve the symbols.
There is also thread-local storage that may complicate things.
In other words, it is too complicated to make re-loading a shared library work without the application being aware of it.
1I once debugged an intersting bug in the past. There was a shared library which was loaded at run-time using dlopen and unloaded after use. The application would later crash in std::cout destructor during termination. Turned out that the shared library was outputting Boost.Date_Time objects into std::cout. When doing so, the library would std::cout.imbue a new locale with a custom facet object from Boost.Date_Time (facets have virtual functions). When the library got unloaded, the facet object was still there owned by that locale, but its vtable pointer was referring the virtual table in the unloaded shared library, which would cause the crash when destroying the facet.
Due to MonoTouch using dll's within the actual app, how secure is this approach? For instance, if someone is using the Mono.Security.dll, couldn't someone swap out that dll with one which implemented the methods and perform a code injection attack on an app?
how secure is this approach?
As much as any existing ones I know :-)
couldn't someone swap out that dll
No for several reasons.
You cannot change the applications files. That would break the digital signature and iOS won't execute it. That alone removes a MitM attack;
the code from every .dll is already compiled to native code (by the AOT compiler) and part of the main executable binary. Swapping a new .dll won't change the code that is executed;
the .dll that is deployed on devices is stripped (for release builds). There's no IL (code) inside it since it would not be useful (we can't JIT on iOS). Even if you add a .dll with IL code (e.g. a debug build) it won't be executed (again it would require JITting);
Why are the .dll deployed ? for their metadata (e.g. if you use reflection)
Final note: MonoTouch produce native ARM executables just like Objective-C would.
I'm trying to compile a statically linked binary with GCC and I'm getting warning messages like:
warning: Using 'getpwnam_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
I don't even know what getwnam_r does, but I assume it's getting called from inside some higher level API. I receive a similar message for gethostbyname.
Why would it not be possible to just statically link these functions in like every other function?
Function calls that need access to NSS or iconv need access will open other libs dynamically, since NSS needs plugins to work (the helper modules like pam_unix.so). When the NSS system dlopens these modules, there will be two conflicting versions of glibc - the one your program brought with it (statically compiled in), and the one dlopen()ed by NSS dependencies. Shit will happen.
This is why you can't build static programs using getpwnam_r and a few other functions.
AFAIK, it's not impossible to fully statically link an application.
The problem would be incompatibility with newer library versions which might be completely different. Say for example printf(). You can statically link it, but what if in a future that printf() implementation changes radically and this new implementation is not backward-compatible? Your appliction would be broken.
Please someone correct me if I'm wrong here.
I have a DLL (written in C) that uses static thread local storage (__declspec(thread)), and I want to use this DLL from a Visual Basic graphic interface.
Unfortunately, when running the interface on Windows XP that DLL which use static thread local storage crashes when it try to acess its thread variables.
How can I solve this problem?
Thanks,
Regards
G.B.
PS
I would like to not modify the DLL.
This is a known limitation of static TLS. Although you aren't explicitly calling LoadLibrary(), the VB runtime does so on your behalf.
Note that this limitation has been lifted from Vista. The most comprehensive reference that I know of is on Ken Johnson's blog.
You may be able to get around the problem if you could get the DLL included in the imports table of the generated .exe, which would likely involve some PE hacking and I'm far from certain it's a viable strategy. Otherwise you'll need to change the DLL.