[Swig-devel] [ swig-Feature Requests-1816842 ] .NET Compact Framework support

[SourceForge.net <no...@so...>]

Feature Requests item #1816842, was opened at 2007-10-19 18:06
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=351645&aid=1816842&group_id=1645

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: David Piepgrass (qwertie)
Assigned to: Nobody/Anonymous (nobody)
Summary: .NET Compact Framework support

Initial Comment:
I need SWIG C# to work on the .NET Compact Framework 2.0 and I have been working on changes to that end. The problems I've run into so far are the following:

1. Apparently, single-byte strings (char * and std::string) cannot be marshalled in the .NET CF at all. period. This means that the current exception handling doesn't work and special typemaps will be needed for char* and std::string. Also, the SWIGStringHelper cannot be used and must be disabled.

2. HandleRef does not exist on .NET CF. IntPtr must be used instead. Simply replacing HandleRef with IntPtr may introduce a subtle race condition, although the .NET CF is mostly undocumented and I do not know whether it is a problem on that platform (at least my code hasn't crashed yet!).

3. In the exception handling code, [ThreadStatic] is used and ArgumentException is initialized with three arguments. In CF, [ThreadStatic] doesn't exist and ArgumentException does not support the "parameter name" argument.

In many cases, changes needed to support the CF may reasonably be applied to the desktop version of SWIG. For example, creating exceptions from Unicode strings is somewhat beneficial, even on the desktop, because C++ code will be able to throw exceptions with exotic characters. Other changes, such as special typemaps for char* and std::string to convert strings to unicode, are a waste of CPU time on the desktop.

Therefore, I propose that CF-specific logic be guarded with #ifdef UNDER_CE blocks. (UNDER_CE is a standard predefined identifier when running under Windows CE, the only platform for which the CF currently exists.) Therefore, one would enable "compact framework mode" by passing -DUNDER_CE to SWIG on the command line. In C# code the standard identifier is WindowsCE instead, which you may notice in the attached patch.

To start things off, I've attached a patch which updates the exception handling to (1) always pass unicode strings and (2) conditionally (#if !WindowsCE) not use [ThreadStatic] nor the 3-argument version of the ArgumentException constructor. In order to pass unicode strings, I allocate a BSTR. While BSTRs are not actually needed for exceptions (malloc would do just fine), I suspect I need BSTRs later to help eliminate SWIGStringHelper. However, I have a concern here: I don't know if BSTR support is available on Linux (if not, then how would Mono P/Invoke handle UnmanagedType.BStr?)

BTW I think this Unicode code is incompatible with Linux/Mono. I suspect SWIG must be changed (universally) to use 'unsigned short *' instead of 'wchar_t *' in order to marshall wide strings correctly on Linux/Mono, because wchar_t is 4 bytes on Linux, whereas .NET strings are UTF-16--but then again, I don't know if Mono marshalls wide strings with 2 or 4 bytes per character.

The second big problem I mentioned was that HandleRef doesn't exist on Compact Framework; tomorrow I'll add a comment about replacing it with IntPtr.

By the way, I'm only trying to support version 2.0 of the CF. The .NET CF 1.0 has some limitations on P/Invoke that would make it much harder to support; in particular, callbacks from C++ to C# (delegate -> function pointer conversion) is only supported in CF 2.0.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=351645&aid=1816842&group_id=1645