View mode: basic / threaded / horizontal-split · Log in · Help
April 09, 2012
Windows 8 Metro support
(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.
April 09, 2012
Re: Windows 8 Metro support
On 09.04.2012 20:39, Sönke Ludwig wrote:
> (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.

Not true at all, in every talk I've seen on WinRT so far C++ CRT is 
still shipped side by side with WinRT. Basically every language has his 
own runtime. It wouldn't be Microsoft if they haven't got a solid 
reserve of backwards compatibility. Simply put WinRT is a major update 
on COM technology and even here it's backwards compatible with the old COM.
The fact that OS API is expossed through this new COM interface is just 
a nice feature. I was kind of wondering when they will finally ditch 
Win32 API.

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


-- 
Dmitry Olshansky
April 09, 2012
Re: Windows 8 Metro support
On 2012-04-09 18:39, Sönke Ludwig wrote:
> (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.

It's possible to use D with WinRT, as someone posted in an other thread:

http://www.reddit.com/tb/ow7qc

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

I agree.

-- 
/Jacob Carlborg
April 09, 2012
Re: Windows 8 Metro support
"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.

Aside from the Win8 stuff (only because I have a hard time believing Win32 
won't work on Win8), I strongly agree will all of this.
April 09, 2012
Re: Windows 8 Metro support
Am 09.04.2012 19:12, schrieb Dmitry Olshansky:

> Not true at all, in every talk I've seen on WinRT so far C++ CRT is
> still shipped side by side with WinRT. Basically every language has his
> own runtime. It wouldn't be Microsoft if they haven't got a solid
> reserve of backwards compatibility. Simply put WinRT is a major update
> on COM technology and even here it's backwards compatible with the old COM.
> The fact that OS API is expossed through this new COM interface is just
> a nice feature. I was kind of wondering when they will finally ditch
> Win32 API.
>

I've got my information directly from Microsoft Metro guys. Not totally 
sure how good their knowledge actually is, but for _Metro_ apps they 
said that because of sandboxing it is only allowed to access functions 
of the WinRT - the C++ runtime is an exception but I would guess that 
this does not apply for foreign runtimes. You also have to recompile 
C/C++ libraries with the new runtime. Also, the sandboxing model seemed 
to be a part of WinRT - so DMD executables would not be sandboxed at all.

The desktop world will of course be working exactly like it used to do 
and the Win32 API will probably live on for at least a few OS generations.
April 09, 2012
Re: Windows 8 Metro support
>
> 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.
April 09, 2012
Re: Windows 8 Metro support
Am 09.04.2012 20:21, schrieb Nick Sabalausky:
>
> Aside from the Win8 stuff (only because I have a hard time believing Win32
> won't work on Win8), I strongly agree will all of this.
>

No, sorry for the confusion, Win32 will work in general! Just Metro apps 
may not use Win32 and other libraries with the exception of the runtime 
and WinRT.
April 09, 2012
Re: Windows 8 Metro support
On 2012-04-09 19:20:49 +0000, Sönke Ludwig <sludwig@outerproduct.org> said:

> I've got my information directly from Microsoft Metro guys. Not totally 
> sure how good their knowledge actually is, but for _Metro_ apps they 
> said that because of sandboxing it is only allowed to access functions 
> of the WinRT - the C++ runtime is an exception but I would guess that 
> this does not apply for foreign runtimes. You also have to recompile 
> C/C++ libraries with the new runtime. Also, the sandboxing model seemed 
> to be a part of WinRT - so DMD executables would not be sandboxed at 
> all.
> 
> The desktop world will of course be working exactly like it used to do 
> and the Win32 API will probably live on for at least a few OS 
> generations.

Interesting.

Apple too is moving to a sandboxed model. On the Mac, the sandbox is 
only imposed (or soon will be imposed) to apps distributed through 
their App Store. On iOS, the sandbox is always active. It'd be nice to 
check that the D runtime still run fine in a sanboxed Mac app, 
otherwise it restricts even more where you can use D code. Fortunately, 
Apple's sandbox doesn't require you to use a whole different set of 
APIs, it just prevent the code from doing the things it has no 
entitlements for.

-- 
Michel Fortin
michel.fortin@michelf.com
http://michelf.com/
April 09, 2012
Re: Windows 8 Metro support
On 2012-04-09 16:39:30 +0000, Sönke Ludwig <sludwig@outerproduct.org> said:

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

I share your feeling. In fact, I'm not using D anywhere right now 
because it'd be too inconvenient for what I do most of the time.

> 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 the reason GUI apps are so important is because they're the front 
end of most back ends. If using D on the back end makes it harder to 
build the user interface because of the language barrier, then that's a 
huge downside to using D on the back end of any project where the goal 
includes a user interface. For me at least, C++ is much better choice 
for the backend of a GUI app at the moment mostly it intermixes easily 
with Objective-C.

> 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 started the D/Objective-C project, patching DMD, because after a huge 
attempt at making a bridge I found out it wasn't going to cut it. The 
need for an intermediate layer at the language level is a huge 
liability: it costs compilation time, slows down the program, bloats 
the executable size, and it increases the memory footprint.

The problem is that D/Objective-C still needs a huge investment in 
development time to become really useful. It's more a proof of concept 
as it is now. The most important blocks have been shown to work, but 
the difficulty lies in getting all the details/variants right, 
integrating with the GC, automatic reference counting, Apple's Modern 
runtime, ARM, etc.

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.

As for WinRT and the C++ extensions Microsoft has created for it, it 
looks very similar to what I've been doing to integrate Objective-C 
into D. No doubt my work could be reused to also add similar WinRT 
support.

-- 
Michel Fortin
michel.fortin@michelf.com
http://michelf.com/
April 09, 2012
Re: Windows 8 Metro support
On 2012-04-09 21:20, Sönke Ludwig wrote:

> I've got my information directly from Microsoft Metro guys. Not totally
> sure how good their knowledge actually is, but for _Metro_ apps they
> said that because of sandboxing it is only allowed to access functions
> of the WinRT - the C++ runtime is an exception but I would guess that
> this does not apply for foreign runtimes. You also have to recompile
> C/C++ libraries with the new runtime. Also, the sandboxing model seemed
> to be a part of WinRT - so DMD executables would not be sandboxed at all.
>
> The desktop world will of course be working exactly like it used to do
> and the Win32 API will probably live on for at least a few OS generations.

D is statically linked to the standard library and runtime.

-- 
/Jacob Carlborg
« First   ‹ Prev
1 2 3
Top | Discussion index | About this forum | D home