Ally316714

Hi all,

QUESTION

Could someone describe a way to link libraries of code statically into a single Windows executable such that they have the same isolation benefits of DLLs, without actually using DLLs

BACKGROUND

My dillemna is that I am using a familiy of C code libraries that I need to integrate into a single binary application but without using dynamic link libraries. Sounds simple, yet the libraries declare/define macros, structures, and functions with the same names as their sister libraries but are not always implemented the same nor properly isolated. (I believe each library was _originally_ imagined to be used on its own, thus great liberty was used developing new libraries based off the first... sigh).

Traditionally, I would have isolated the libraries by using DLLs. This works perfectly because they are separate projects and separate at link-time - just like the C libraries on their own. However, in this case they must be linked into a single binary.

Before, I've tried using C++ namespacing and a library wrapper, but this does not prevent certain link-time conflicts ... usually, I have to modify the source of the libraries, but I cannot (nor want to) do this any more (if I don't have to). If this could be done by using individual static libraries, modifying linker options, or using magic pragmas somehow, that would be great.

Thanks,

Ally




Re: Visual C++ Language Help linking libraries with code isolation benefits of DLLs

Ramkrishna Pawar

Only separate modules have benefits of isolation, so you can Only use separate executable modulles to get there.

Why can't you separetly create static libraries






Re: Visual C++ Language Help linking libraries with code isolation benefits of DLLs

Bruno van Dooren

No silver bullet. Sorry.

The only real way to solve your problem is

1) refactor the static libraries to use unique names, or

2) use DLLs.

What is the reason you cannot use DLLs Maybe we can find a solution for that.





Re: Visual C++ Language Help linking libraries with code isolation benefits of DLLs

Ally

Thanks for your reply Bruno.

It's because of the way Microsoft signs binaries used as operating system components (in this case on Vista). If any dependent binary changes (such as a DLL, e.g. COM objects), then the signing breaks. I can appreciate their decision in this, however we currently use the libraries in COM objects which can be used by other applications. Therefore, if a sister application is installed later, it could break the signing. No doubt, I could put them in unique DLLs as part of the distribution. I was looking for a way to integrate all the libraries into one binary for security/copy-protection reasons, to simplify the deliverable, and simplify the project in whole. The other reason is because this issue is something that's come up several times before and I was looking for a better solution. Apparently there is none.






Re: Visual C++ Language Help linking libraries with code isolation benefits of DLLs

Bruno van Dooren

No problem. I understand your issues now.

I don't know much about installing additional OS components (except for device drivers), but there is an alternative:

wrap the static libs in DLLs, but instead of linking directly to the DLLs, use LoadLibraryEx to load the DLLs at runtime from a known path, and then use getProcAddress to resolve the function addresses.

That known path would then be application specific in c:\program files\, regardless of where the actual exe is installed.

That way you can easily prevent conflict with future versions while still having the benefit of separate DLLs.

I think this is a clean solution.





Re: Visual C++ Language Help linking libraries with code isolation benefits of DLLs

Ally

Thanks again, Bruno.

Yes, this is what I would do, place them in DLLs and link them indirecty (instead of COM). I have done this when the occasion calls for it before. But it isn't the solution I was hoping for.

I didn't think this would be straightforward. I was expecting brute force stuff like creating different sections of memory and mapping into code memory. Perhaps some MS rep snooping the forums might have a trick about the linker that would isolate the binaries using namespaces or code sections or other pragmas I've looked in the linker and compiler documentation for switches, but nothing is standing out. Ultimately, if I have no choice, I'll have to do it the other way - but no harm looking for a better solution.






Re: Visual C++ Language Help linking libraries with code isolation benefits of DLLs

Ally

Sorry, I meant "link them directly". The solution of placing them in specific paths may avoid me having to give unique filenames to DLLs and to use the same DLLs for sister apps just in different locations. But since this is an operating system component, I am not sure if the DLLs must reside in the System32 directory or not. Specifically, this is for a family of sAPOs in Vista which would use libraries depending on options. Since some packages would use similar libraries and could be installed at different times, this is where signing breakage may occur and must be avoided. On Vista, APOs are part of the drivers, so signing is tied to all components.

In any case, if someone can offer a non-DLL option, this would be ideal.






Re: Visual C++ Language Help linking libraries with code isolation benefits of DLLs

Bruno van Dooren

Afaik there is no requirement that the DLLs be in any specific location IF you manually load them into your exe.

To make it safe, you could use a guid as part of the directory name that would be used by a given version of your application.

This is the best solution I can think of. Maybe someone else chimes in, but for now I think this is your best bet.

I really don't think there is a brute force solution to your problem since most of your problems are related to symbol names, and they won't change anymore unless you molest them manually. But that would be really hairy, and not something you'd want to ship.





Re: Visual C++ Language Help linking libraries with code isolation benefits of DLLs

Ally

Agreed, I'll pursue this avenue in the meantime and hopefully it works out OK. Thanks again for the thoughts!