From: Владимир Ч. <sv...@gm...> - 2013-01-31 14:54:05
|
On Tue, Jan 29, 2013 at 4:32 PM, Владимир Чернышев <sv...@gm...>wrote: > > On Sat, Jan 26, 2013 at 8:16 PM, William S Fulton <ws...@fu... > > 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<http://stackoverflow.com/a/12044370> >> >> >> Current approach is writing C++ component extensions >>>> (https://en.wikipedia.org/**wiki/C%2B%2B/CX<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<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<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<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<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: >>> http://social.msdn.microsoft.**com/Forums/en-US/** >>> toolsforwinapps/thread/**db7f417e-730c-4cad-8dc4-**0a78ad119d3c/<http://social.msdn.microsoft.com/Forums/en-US/toolsforwinapps/thread/db7f417e-730c-4cad-8dc4-0a78ad119d3c/> >>> >>> 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 > > http://stackoverflow.com/questions/7807361/how-to-p-invoke-to-a-native-dll-from-metro > > >> >> 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<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. >> >> William >> > > > > -- > with best regards, > Vladimir Chernyshev > -- with best regards, Vladimir Chernyshev |