Build options

Build options

Hi, The current build options in the release notes for the SDK state that the code generation flag needs to be set as : · For Debug Builds, set the Runtime Library to Multi-threaded Debug DLL (/MDd). · For Release Builds, set the Runtime Library to Multi-threaded DLL (/MD). My issue is that I use middleware solutions that come with pre-built libs - just as the IADP SDK - but that are built with the /MT /MTd options. This causes conflicts when trying to link as the runtime libs are in effect declared as both dynamic and static - forgive my ignorance on compiler options if this isn't the case. I'm sure at some point I have used middleware which has supplied both sets of libs, one built against the /MD / MDd and the /MT / MTd options. I've seen solutions in the forums to wrapping the SDK libs up to supply them as dll's - the Unity Middleware post - but nothing that address this specific issue. Any ideas, or have I just convinced myself that this is an issue, but in fact I'm missing something much more obvious. Thanks Martin
10 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.


For the time being, you are correct. Building an ATOM Library DLL in those cases is the simplest route. In the future the ATOM SDK may change, and we will also know what version of CRT ships with the ATOM store.

Thanks for the reply.

If the SDK was compiled with static CRT libs then don't you have more control over the libs you ship - the runtime calls are shipped in the libs you supply? Otherwise the ones that are installed on the machine running the ATOM store / developers machine will be used - not the ones that were used at the snapshot of development? But then again that's a whole thread on static vs dynamic linking...

Any pointers on how to begin to set about this task - the Unity thread glossed over the actual details.

Your statement is correct; if the ATOM SDK were to link using static libs then you would have more control.

I would be happy to give a few pointers. What is your IDE, what framework is your application built upon?

The basic idea is to create a standalone DLL which uses facade to expose the ATOM SDK methods you require (at least authentication).

I'm running Visual Studio 2008 - the only supported IDE? Framework? .Net 3.51 SP1 - but so far as I know I' not using the Framework - No Common Language Runtime support set in my compiler options.

So I'm guessing then I have to create a project, add the relevant headers from the Atom SDK and then macro up for dll export / import?
#define DLL_EXPORT __declspec(dllexport)
#define DLL_IMPORT __declspec(dllimport)

And then link against the libs?

You will want to set your include and library folders, as well as the core ATOM SDK dependencies (adpcored.lib adpcppfd.lib psapi.lib shlwapi.lib).

Then you will want to expose a few methods to allow for authentication and error logging.
* I prefer to use the facade architecture pattern in these cases to gain simplicity/re-use in the calling code (your application).

If you have any trouble do not hesitate to ask.


Without getting into the debate of using static libs vs. dll's, I would think that the SDK folks would want the path to develop with the SDK to be as simple as possible. Linking in all kinds of libraries that have dependencies on various CRT versions always seems to be problematic. The whole point of Dll's is that they can have all these dependencies wrapped up in a usable package. I would much prefer that the SDK take one of two paths to make a lot of these problems go away.

1) Allow the developer to just dynamic load the core binary and get the proc. addresses they need to do the basic stuff to get authenticated.

2) Include lightweight libraries that we link with that load the core binary(s) dynamically thereby isolating all the dependencies from the app developers so they are free to use whatever they want in terms of middleware, etc. These libraries can include routines to perform step #1 if developers don't want to do the grunt work themselves.

Network and graphics libraries use extension all the time to make API's more flexible. I would like to see this SDK follow in that direction instead of being so locked down. The whole issue of having the right things installed at run time is another issue but I think of that as a separate install time issue that is easier to deal with than dependencies contained in libraries.

We are considering adding support for dynamic libraries. However, one of the rationales for static libraries was increased security. With a DLL someone can easily bypass security/authorization checks by replacing the DLL with a dummy/proxy DLL.

Increased security, and robustness of the security model is a major focus for the next release.

IADP Architect

I agree that the .dll path has some perils associated with it. If you had a lightweight library that we could link with that excluded all of the dependencies on other library versions and isolated all of the core guts in a more secure core dll then you could initiate some sort two handed encryption handshake between the two layers to help keep security a major factor when the loading happens.

I would rather see something come from you guys that is standard instead of various users cooking up ways around these dependencies.

Thanks for the input, I look forward to the next release to see what goodies you've cooked up.


We're working on it.

There are several new API sets in the next release and we are refactoring the security code, plus adding more protection in depth. On open platforms, there is no perfect security model, even closed platforms are cracked.

For now, I would avoid wrapping the static libraries in a DLL if possible. Although we do not plan to do anything to directly forbid/prevent it, we plan to nothing to support it in the future.

IADP Architect

Leave a Comment

Please sign in to add a comment. Not a member? Join today