On Sat, Jan 26, 2013 at 8:16 PM, William S Fulton <wsf@fultondesigns.co.uk> wrote:
On 26/01/13 10:27, Vladimir Kalinin wrote:
I've tried to use swig to generate C# wrappers for WinRT platform,
but it seems like the don't support PInvoke anymore.
I don't know how you arrived at that conclusion, PInvoke does seem to be supported, but seems you are limited by the APIs you can call. More info here: http://stackoverflow.com/a/12044370

Current approach is writing C++ component extensions
(https://en.wikipedia.org/wiki/C%2B%2B/CX) which have extended
C++ syntax and enable to call generated native code from wide range of languages.

Ah no, yet another Microsoft extension.

My question is: is there anyone who is working on support of C++/CX
in swig? Doesn't swig have policies which may be against
such support? For example, is it ok that despite the fact that
C++/CLI syntax is a ECMA standard, there's only one compiler which
supports it?

SWIG support standards for the input C and C++, but the target languages aren't necessarily standards based. For .net, SWIG supports the ECMA C# standard and that works for many .net environments. Unfortunately Microsoft don't support .net consistently on all their .net platforms, in particular Compact Framework, for example HandleRef is missing. Some users have modified SWIG to work around this, see http://swig.10945.n7.nabble.com/C-and-the-Compact-Framework-windows-mobile-td9989.html.

I've done a small research using the information from the link above. As link is a bit outdated, the patched files couldn't be applied to the current swig. I've tried using swig 1.3.36 and replaced some files according to the post. Good news are it really fixes using of HandleRef. The bad news are it uses methods like SysAllocString and SysFreeString, for which I can't find any header in Windows Phone Kits SDK. Current Swig seems not to have such problem. So it seems for me that the only way for me is to modify current swig so as to avoid using HandleRef in a manner from the link.

I just noticed that SafeHandle was introduced into the CLI standard ECMA-335 in Dec 2010 - http://www.ecma-international.org/publications/standards/Ecma-335-arch.htm. SWIG first used IntPtr, then changed to use HandleRef in SWIG-1.3.25 to fix memory management issues. There are no known problems with this approach, but it could be modified to use SafeHandle instead which might be needed for WinRT. It isn't clear to me from the docs what is supported for WinRT, but at least SafeHandle can be used for ".NET for Windows Store Apps" - http://msdn.microsoft.com/en-us/library/system.runtime.interopservices.safehandle.aspx, but not HandleRef - http://msdn.microsoft.com/en-us/library/system.runtime.interopservices.handleref.aspx. Владимир, you might want to try a simple SafeHandle example and let us know.

I can't believe they stopped supporting P/Invoke in Win 8. E.g. see the
last answer in this thread by MS employee:

Perhaps you need to fix a manifest or something like that.
Sounds reasonable. Unfortunately I can't google anything useful about the topic. Any way, I'll continue searching.

Владимир, I suggest you try a single minimalistic test with a global function that takes just primitive types that avoid HandleRef, such as this SWIG interface file:

%module example

%inline %{
int add(int a, int b) {
  return a+b;

and report back.
I've tried this example, it was compiled with no errors, but in as soon as I called P/Invoke I received an exception, exactly as in this topic

WinRT seems to be based on COM technology. There is a nearly finished COM target language for SWIG - https://github.com/swig/swig/tree/gsoc2008-jezabek. As COM can be called from .NET and any WinRT supported language, it might be the best approach to wrapping native C/C++ code.


with best regards,
Vladimir Chernyshev