Compiler dependency in ctypes

Question

I have a third party, closed source library coming as a windows dll built with visual studio 2010. First, I planned building an extension module for that dll using e.g. SWIG. However that's spoiled by the fact that it's build with VS 2010, whereas all python 2 distributions are built with VS 2008.

Now it seems ctypes doesn't have this limitation. I've built a trivial dll using VS 2010 (dependency walker shows the dll is linked to msvcr100.dll) with a function:

int fnTestLib2(int a, int b)
{
    return a+b;
}

loaded it in ctypes and

fcn = mydll.fnTestLib2
fcn.argtypes = [ctypes.c_int, ctypes.c_int]
fcn.restype = ctypes.c_int
print fcn(1,2)

correctly prints 3.

Now, I'm somewhat confused: Is this just because I'm lucky and because the example is trivial or is there a fundamental difference in the underlying technique of ctypes and an extension module? If yes, what is it? ;)

And finally: would it be safe to implement a ctypes wrapper library for that third party dll?

EDIT Upon Serge's answer I compiled my swig extension using distutils in combination with the Windows SDK. So, now I have my extension bla.pyd and it indeed seems to work. Though I'm wondering if the this dependency on two c runtimes is recommendable or not. Looking at it with dependency walker:

Answer 1

I'm not an expert on SWIG not ctypes, but when younger I often struggled in Windows dll hell.

First your example is way too trivial. As you do not call any function from the standard library, the example could work even without mscvr100.dll in the path. You should at least try to use one simple function such as strlen (not lstrlen which would be a Windows API function ...) :

#include <string.h>
int testfunc(char *str) {
    return strlen(str);
}

I could not test because I presently have no VS2013 compiler.

Next, there is a major difference between SWIG and ctypes :

• SWIG interfaces C/C++ source code with Python
• ctypes directly interfaces an executable dll with Python

As ctypes directly interfaces a dll, you should not worry with what compiler the dll was compiled, nor which other dll it uses provided they are on the path. It would be really different if it had to use an static library (xxx.a) because in that case, the library formats should be compatible. You simply have to know what calling convention is used (stdcall or cdecl) to know if you should use windll or cdll (respectively).

By the way, according to this other post on SO How to create a DLL with SWIG from Visual Studio 2010, it is also possible to create an extension dll for Python with VisualStudio 2010. It is normal because from python side, the extension library is just a dll and it uses it as such, but the hard part is to have access to the Python dll from VisualStudio environment.