Am Thu, 24 Jan 2013 20:31:58 -0500 schrieb Nick Sabalausky <[email protected]>:
> On Fri, 25 Jan 2013 00:24:31 +0100 > "Andrew Pennebaker" <[email protected]> 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.
