Mobile app support?

[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.