On Tue, Jan 29, 2013 at 4:32 PM, Владимир Чернышев <sveolon@gmail.com> wrote:

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.

I've done some tests on whether whose wrappers for COM target could be used on WinRT. I've tried example.cxx from Examples. For desktop generated COM sources were compiled and linked with virtually no errors. Bad news are when I tried to compile the same sources as Windows Store dll or Windows Phone dll (which are WinRT components) I've got a bunch of compilation errors like these:

1>------ Build started: Project: COMexample, Configuration: Debug Win32 ------
1>  example_wrap.cxx
1>..\..\com_test\example_wrap.cxx(186): error C3861: 'CreateErrorInfo': identifier not found
1>..\..\com_test\example_wrap.cxx(198): error C2065: 'IID_IErrorInfo' : undeclared identifier
1>..\..\com_test\example_wrap.cxx(200): error C3861: 'SetErrorInfo': identifier not found
1>..\..\com_test\example_wrap.cxx(319): error C3861: 'DispGetIDsOfNames': identifier not found
1>..\..\com_test\example_wrap.cxx(327): error C3861: 'DispInvoke': identifier not found
1>..\..\com_test\example_wrap.cxx(417): error C3861: 'CoLockObjectExternal': identifier not found
1>..\..\com_test\example_wrap.cxx(478): error C2065: 'IID_ISupportErrorInfo' : undeclared identifier
1>..\..\com_test\example_wrap.cxx(1433): error C2065: 'IID_ISupportErrorInfo' : undeclared identifier
1>..\..\com_test\example_wrap.cxx(1621): error C3861: 'GetModuleFileName': identifier not found
1>..\..\com_test\example_wrap.cxx(1642): error C2065: 'HKEY_CLASSES_ROOT' : undeclared identifier
1>..\..\com_test\example_wrap.cxx(1642): error C3861: 'RegOpenKeyEx': identifier not found

Full text search through the SDK's headers has shown that some of the symbols like GetModuleFileName are enabled under desktop but disabled under phone using #ifdefs, but most part of not found identifiers are really missing.

So for me it seems like even though WinRT is declared to be a COM-based OS, currently there's no way to use pure COM wrappers. To be honest I have to say that I have no experience in Windows programming, I'm just looking for ways to generate platform wrappers for our cross-platform library. So I definitely might misunderstand something.


with best regards,
Vladimir Chernyshev

with best regards,
Vladimir Chernyshev