April 09, 2012
On 2012-04-09 21:23, Sönke Ludwig wrote:
>>
>> It's possible to use D with WinRT, as someone posted in an other thread:
>>
>> http://www.reddit.com/tb/ow7qc
>>
>
> But that does not suffice to make a Metro app. For desktop apps there
> shouldn't be a problem, but the Metro side poses more restrictions on
> the app.

Aha, ok. Don't know about that. BTW, have you seen this: http://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2012/The-Windows-Runtime

He's encouraging other language developers to bring their languages to Windows 8 and be compatible with WinRT.

-- 
/Jacob Carlborg
April 10, 2012
"Sönke Ludwig" <sludwig@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


April 10, 2012
On Monday, April 09, 2012 23:58:26 Nick Sabalausky wrote:
> 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

Oh, that's easy to top. Passing structs to C functions in 64-bit doesn't work:

http://d.puremagic.com/issues/show_bug.cgi?id=5570

- Jonathan M Davis
April 10, 2012
"Jonathan M Davis" <jmdavisProg@gmx.com> wrote in message news:mailman.1567.1334031023.4860.digitalmars-d@puremagic.com...
> On Monday, April 09, 2012 23:58:26 Nick Sabalausky wrote:
>> 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
>
> Oh, that's easy to top. Passing structs to C functions in 64-bit doesn't work:
>
> http://d.puremagic.com/issues/show_bug.cgi?id=5570
>

Ouch! And that one's over a year old.


April 10, 2012
On 2012-04-09 21:51, Michel Fortin wrote:
> On 2012-04-09 16:39:30 +0000, Sönke Ludwig <sludwig@outerproduct.org> said:

>> 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.
>
> I'd love to take your money to free some of my time so I can continue
> working on this project. But I'm not too confident it will ever reach a
> satisfactory state without a huge time investment on my part. And I
> can't spare that investment myself, hence why the project is stalled.

A too familiar situation for D projects.

-- 
/Jacob Carlborg
April 10, 2012
Am 09.04.2012 22:32, schrieb Jacob Carlborg:
> On 2012-04-09 21:23, Sönke Ludwig wrote:
>>>
>>> It's possible to use D with WinRT, as someone posted in an other thread:
>>>
>>> http://www.reddit.com/tb/ow7qc
>>>
>>
>> But that does not suffice to make a Metro app. For desktop apps there
>> shouldn't be a problem, but the Metro side poses more restrictions on
>> the app.
>
> Aha, ok. Don't know about that. BTW, have you seen this:
> http://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2012/The-Windows-Runtime
>
>
> He's encouraging other language developers to bring their languages to
> Windows 8 and be compatible with WinRT.
>

Haven't seen it before. Unfortunately, he doesn't talk about the language runtime in detail, but he does talk about how the standard library needs to be adjusted to use Metro style libraries so I guess the same would apply to the language RT.

At the end he gives some links and this one might be interesting:
http://channel9.msdn.com/Events/BUILD/BUILD2011/PLAT-875T
I'll try to watch that later today.
April 10, 2012
On 2012-04-10 06:09, Jonathan M Davis wrote:
> On Monday, April 09, 2012 23:58:26 Nick Sabalausky wrote:
>> 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
>
> Oh, that's easy to top. Passing structs to C functions in 64-bit doesn't work:
>
> http://d.puremagic.com/issues/show_bug.cgi?id=5570
>
> - Jonathan M Davis

Can that be the case why some of my projects built for 64bit doesn't work and behaves very strangely.

-- 
/Jacob Carlborg
April 10, 2012
On 2012-04-10 08:50, Sönke Ludwig wrote:

> Haven't seen it before. Unfortunately, he doesn't talk about the
> language runtime in detail, but he does talk about how the standard
> library needs to be adjusted to use Metro style libraries so I guess the
> same would apply to the language RT.
>
> At the end he gives some links and this one might be interesting:
> http://channel9.msdn.com/Events/BUILD/BUILD2011/PLAT-875T
> I'll try to watch that later today.

The thing is, as I understand it, you should be able to use the native types and standard library types/functions through the WinRT API. So you would basically build, for example, a (or a couple of) WinRT range(s)to be able to iterate D collections.

I'm not sure if the language runtime needs to be changed. It depends on what's expected from the WinRT API.

-- 
/Jacob Carlborg
April 10, 2012
Am 10.04.2012 08:55, schrieb Jacob Carlborg:
> On 2012-04-10 08:50, Sönke Ludwig wrote:
>
>> Haven't seen it before. Unfortunately, he doesn't talk about the
>> language runtime in detail, but he does talk about how the standard
>> library needs to be adjusted to use Metro style libraries so I guess the
>> same would apply to the language RT.
>>
>> At the end he gives some links and this one might be interesting:
>> http://channel9.msdn.com/Events/BUILD/BUILD2011/PLAT-875T
>> I'll try to watch that later today.
>
> The thing is, as I understand it, you should be able to use the native
> types and standard library types/functions through the WinRT API. So you
> would basically build, for example, a (or a couple of) WinRT range(s)to
> be able to iterate D collections.
>
> I'm not sure if the language runtime needs to be changed. It depends on
> what's expected from the WinRT API.
>

Okay, I would agree to the first part. This would make the interaction with WinRT bidirectional and more or less seemless. But one thing in particular, that you are not allowed to do is to use kernel32.dll (at least I was told). So you still have to rewrite all the C-library functions (such as fopen(), malloc() and so on) and anything that the D runtime or Phobos uses from kernel32 or similar libraries; I gues the same applies to ws2_32 and so on.
April 10, 2012
Am 10.04.2012 06:09, schrieb Jonathan M Davis:
> On Monday, April 09, 2012 23:58:26 Nick Sabalausky wrote:
>> 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
>
> Oh, that's easy to top. Passing structs to C functions in 64-bit doesn't work:
>
> http://d.puremagic.com/issues/show_bug.cgi?id=5570
>
> - Jonathan M Davis

I know I've suffered quite a bit from that one, especially because it can be quite hidden and required modifying and maintaining external C libraries that expect structs by value.