"Sönke Ludwig" <slud...@outerproduct.org> wrote in message news:jlv3c2$10rn$1...@digitalmars.com... > (IMO) one of the biggest obstacles for truly broad adoption of D currently > is the weak platform support on end user platforms. The two mobile > platforms that came up recently (iOS and Android) are two examples. And > indeed I think that support for mobile platforms could be a real stepping > stone because of D's extraordinary convenience and language power - the > alternatives to C/C++ are pretty thin here and cross-platform development > in general has come to a grinding halt recently with all the proprietary > languages and APIs. If D could step up here... > > But mobile platforms aside, Windows support is something that in general > has always been neglected a bit, especially regarding 64-bit support. > Starting with Windows 8 there will arise additional problems because Metro > application will only be able/allowed to use the COM based WinRT and the > VisualStudio runtime. DMD with its use of snn.lib is out of the game here, > just as the any other runtime library. > > Right now, if we don't catch up here, D will slowly degrade to a pure > server and command line application language which surely wouldn't do it > justice. > > In consequence this means that there is one more reason to raise the > priority of COFF output from DMD (together with 64-bit codegen) - or > possibly the alternative to make OptLink COFF-capable to at least be able > to somehow link against the VS runtime. > > Another such thing - although this can be worked around - would be direct > support for Objective-C classes like in Michel Fortin's dmd modification. > I think these GUI application related functionalities are by far the most > important things for D's mass adoption. And personally, I would even be > willing to donate a (for me) considerable amount of money to help bringing > this forward because many things I would like to realize with D are > currently (almost) impossible.
Speaking of platform support problems, this 64-bit data corruption issue has been sitting around for months, and basically fubars most (all?) programs on 64-bit that use old-style varargs (such as std.string.format): http://d.puremagic.com/issues/show_bug.cgi?id=6983