Mobile app support?

[Paulo Pinto]

Am 25.01.2013 20:37, schrieb Johannes Pfau:
> Am Thu, 24 Jan 2013 20:31:58 -0500
> schrieb Nick Sabalausky <SeeWebsiteToContactMe at semitwist.com>:
>
>> On Fri, 25 Jan 2013 00:24:31 +0100
>> "Andrew Pennebaker" <andrew.pennebaker at gmail.com> wrote:
>>
>>> What's the state of Android, iOS, and Windows RT support for D?
>>> Wouldn't it be great if we could write cross-platform mobile apps
>>> in a single language?
>>
>> Someone else will have to answer about the state of D on
>> Android/iOS/Win8Arm, as I don't know. My understanding it that it's
>> getting there, but not quite there yet. Someone's been working on
>> connecting D with ObjC. I don't know anymore details.
>
> I don't remember anyone working on Windows RT or iOS. Michel Fortin has
> code to interface to ObjC which would benefit iOS development:
> * A template based solution, but IIRC that created to much bloat and
>    development was stopped.
> * A dmd patch which added extern(ObjC).
>    http://michelf.ca/projects/d-objc/
>    I'm not sure what's the status here. IIRC I thought it was a quite
>    intrusive language change (it added additional syntax except from
>    extern(ObjC)), but with UDAs + compiler support it could probably be
>    adapted to make it less controversial. Either way it would be a huge
>    patch and huge patches tend to get not reviewed merged into dmd so
>    it's difficult.
>
> I can tell more about Android: About a year ago I tried porting D(GDC)
> to Android. I didn't care about JNI/GUI, I just wanted to get druntime
> and phobos working first. There are 2 fundamental issues, both making D
> on Android impossible right now:
>
> * Google castrated it's libc: it doesn't support TLS. D can't work
>    without TLS. (Things might get better with C++/11 which also has TLS
>    support). AFAIK google was just to lazy to implement TLS (Java
>    doesn't need it), ARM/Linux even provides hardware support for fast
>    TLS (TLS register).
> * GCC has emulated TLS. It would be slow but it could work. Except that
>    it can't work with the D garbage collector right now. It could be
>    integrated with some effort, but it would veeeery be slow. (Basically
>    emuTLS allocates small distinct memory ranges, real TLS has one big
>    range per thread. Now the GC needs to get all ranges and scan them.
>    Our current approach can't get the small ranges. Even if we could
>    make it work scanning many small ranges is slow)
> * And, not related to the other issues, but also a show-stopper: the
>    android runtime linker is pretty stupid. Applications which where not
>    started by the javaVM or use static linking have strange problems
>    (such as global variables not working. Even fprintf(stdout) doesn't
>    work, known android problem).
>    It actually seems this has been fixed now
>    ( http://code.google.com/p/android/issues/detail?id=28598 ), but only
>    in recent Android versions. There could be more issues like these
>    though, as google officially does not support native applications.
>    Even if those did work, you can't write gui applications if you app
>    wasn't started by the Java VM.
>    The Android solution is this: Write a
>    small JAVA app, load the native shared library, call function in the
>    shared library done. Well, D shared libraries don't work yet and we
>    need a shared druntime & phobos as well.
>
> That's it for Android. For ARM in general, gdc support is quite OK.
> There are <10 failures in the compiler test suite which are really arm
> specific bugs. Not much work has been done on druntime & phobos ARM
> supprt though. I know that at least the GC & TLS is working on
> ARM/Glibc.
>


And I can provide some information regarding Windows Phone 8, at least
from I know from reading MSDN and Channel 9 videocasts.

The main operating system runtime is WinRT, so D would probably need to
make use of it.

D already supports COM and there was a Microsoft employee that played a 
bit with it, if I remember correctly.

Nonetheless, D code would need to interoperate with WinRT, which is
actually improved COM objects, and their projections (metadata). In a 
similar way like C++/CX and .NET do.

Plus certain care needs to be taken with the small set of available 
Win32 calls, otherwise it won't be possible to sign the applications:

https://forums.embarcadero.com/message.jspa?messageID=484319#484319

--
Paulo