www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Mobile app support?

reply "Andrew Pennebaker" <andrew.pennebaker gmail.com> writes:
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?
Jan 24 2013
next sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Fri, 25 Jan 2013 00:24:31 +0100
"Andrew Pennebaker" <andrew.pennebaker 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.

But if you just want "cross-platform mobile apps in a single language"
there is Marmalade <http://madewithmarmalade.com>. The downsides are
that it's neither free nor free, and you have to use C++, not D. And
last I looked it didn't yet support C++11 or Win8Arm, though I'm sure
it'll eventually get those.

Of course, I look forward do being able to do it all in D, and without
a non-free and non-free toolkit.
Jan 24 2013
parent reply Johannes Pfau <nospam example.com> writes:
Am Thu, 24 Jan 2013 20:31:58 -0500
schrieb Nick Sabalausky <SeeWebsiteToContactMe semitwist.com>:


 On Fri, 25 Jan 2013 00:24:31 +0100
 "Andrew Pennebaker" <andrew.pennebaker 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.
Jan 25 2013
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-01-25 20:37, Johannes Pfau wrote:


 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.


You can do it manually to avoid bloat but that is very tedious.


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


It hasn't had an update for two or three years.


 * 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)


DMD on Mac OS X currently uses an emulated TLS.

-- 
/Jacob Carlborg
Jan 25 2013
parent Johannes Pfau <nospam example.com> writes:
Am Fri, 25 Jan 2013 21:43:29 +0100
schrieb Jacob Carlborg <doob me.com>:


 
 DMD on Mac OS X currently uses an emulated TLS.
 


yep, but a custom implementation. I'd like to use the GCC
implementation for increased compatibility between C/C++ __thread and D
(foe example declaring a __thread variable in C, using it in D or the
other way round)
Jan 25 2013
prev sibling next sibling parent Paulo Pinto <pjmlp progtools.org> writes:
Am 25.01.2013 20:37, schrieb Johannes Pfau:

 Am Thu, 24 Jan 2013 20:31:58 -0500
 schrieb Nick Sabalausky <SeeWebsiteToContactMe semitwist.com>:


 On Fri, 25 Jan 2013 00:24:31 +0100
 "Andrew Pennebaker" <andrew.pennebaker 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
Jan 25 2013
prev sibling parent reply "Oleg Kuporosov" <Oleg.Kuporosov gmail.com> writes:
On Friday, 25 January 2013 at 19:37:43 UTC, Johannes Pfau wrote:

 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.


Good overview and job Johannes, thanks!

Just a note, may be somebody are not aware.
Even DMD can be used to play with Android! There are already 
Intel based
smartphones in Europe and Asia, like Motorola RAZR I and some 
telcos-branded. Atom and Core tablets will be there soon starting 
with Windows 8 and then I hope Android too. It may simplify RT 
porting efforts a lot.

Oleg.
Jan 25 2013
parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Saturday, 26 January 2013 at 05:33:17 UTC, Oleg Kuporosov 
wrote:

 On Friday, 25 January 2013 at 19:37:43 UTC, Johannes Pfau wrote:

 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.


 Good overview and job Johannes, thanks!

 Just a note, may be somebody are not aware.
 Even DMD can be used to play with Android! There are already 
 Intel based
 smartphones in Europe and Asia, like Motorola RAZR I and some 
 telcos-branded. Atom and Core tablets will be there soon 
 starting with Windows 8 and then I hope Android too. It may 
 simplify RT porting efforts a lot.

 Oleg.


I'm typing this on an Intel AZ210 right now,  branded as an 
Orange San Diego. It would be really cool to be able to write 
apps in D for it!
Jan 26 2013
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-01-25 00:24, Andrew Pennebaker 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?


In general, not good. DMD cannot compile for ARM. You do have other 
options like GDC and LDC which are supposed to be able to compile for 
ARM. Don't know the state of the runtime on ARM for these compilers.

Except for the above, for iOS you would want to interact with 
Objective-C, which is kind of a pain in the ass. The correct solution is 
to make D ABI compatible with Objective-C. Michel Fortin has been 
working on this, he released an alpha version of his DMD fork that is 
usable. But unfortunately he has not worked on it for a couple of years. 
That was also only for Mac OS X, not for iOS.

http://michelf.ca/projects/d-objc/

Another option is to use the Objective-C runtime functions (which are in 
plain C) and use them manually or with the help of a bridge. That has 
its own problems, like a Hello World application (desktop) taking around 
60MB due to code bloat.

Objective-C bridge: http://www.dsource.org/projects/dstep

-- 
/Jacob Carlborg
Jan 24 2013
prev sibling next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Thursday, 24 January 2013 at 23:24:32 UTC, Andrew Pennebaker 
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?



concerns compiled languages.
Jan 25 2013
prev sibling parent reply "angel" <andrey.gelman gmail.com> writes:
Take into account that generating ARM binary is not all the story.
For example, Android applications run in a virtual machine 
targetted by (a dialect of) Java. These Java applications can be 
bound to native code via JNI interface, that also does not target 
D, and even a plain C application would have to be ported, as 
they use some kind of Android-specific version of C standard 
library.
To summarize, possibly you could port a D application to Android 
with reasonable investment of sweat and blood, but ... you know, 
everyone can fall out of a window, but this cannot be considered 
the most convenient way to get to the street.
Possibly the upcoming Ubuntu phone will be able to provide a 
friendlier platform ...
Jan 25 2013
parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Friday, 25 January 2013 at 11:59:38 UTC, angel wrote:

 Take into account that generating ARM binary is not all the 
 story.
 For example, Android applications run in a virtual machine 
 targetted by (a dialect of) Java. These Java applications can 
 be bound to native code via JNI interface, that also does not 
 target D, and even a plain C application would have to be 
 ported, as they use some kind of Android-specific version of C 
 standard library.
 To summarize, possibly you could port a D application to 
 Android with reasonable investment of sweat and blood, but ... 
 you know, everyone can fall out of a window, but this cannot be 
 considered the most convenient way to get to the street.
 Possibly the upcoming Ubuntu phone will be able to provide a 
 friendlier platform ...


Additionally both Google and Microsoft see the plain C and C++ 
environment as meant for games only, a way to make use of 
"legacy" code or for common code across platforms.
Jan 25 2013
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Fri, 25 Jan 2013 15:07:06 +0100
"Paulo Pinto" <pjmlp progtools.org> wrote:

 
 Additionally both Google and Microsoft see the plain C and C++ 
 environment as meant for games only, a way to make use of 
 "legacy" code or for common code across platforms.
 


And also for a lot of their *own* code. But just not for code
*other* people write to run on MS/Google's C/C++-written platforms.
Jan 25 2013
parent Paulo Pinto <pjmlp progtools.org> writes:
Am 25.01.2013 20:16, schrieb Nick Sabalausky:

 On Fri, 25 Jan 2013 15:07:06 +0100
 "Paulo Pinto" <pjmlp progtools.org> wrote:

 Additionally both Google and Microsoft see the plain C and C++
 environment as meant for games only, a way to make use of
 "legacy" code or for common code across platforms.


 And also for a lot of their *own* code. But just not for code
 *other* people write to run on MS/Google's C/C++-written platforms.


Well, if you look at the Android source code, the majority of the code
is really Java.

The C and C++ source code are mostly what is coming from Linux kernel 
and drivers.

--
Paulo
Jan 25 2013