Jump to page: 1 2 3
Thread overview
Windows 8 Metro support
Apr 09, 2012
Sönke Ludwig
Apr 09, 2012
Dmitry Olshansky
Apr 09, 2012
Sönke Ludwig
Apr 09, 2012
Michel Fortin
Apr 09, 2012
Jacob Carlborg
Apr 10, 2012
bls
Apr 09, 2012
Jacob Carlborg
Apr 09, 2012
Sönke Ludwig
Apr 09, 2012
Jacob Carlborg
Apr 10, 2012
Sönke Ludwig
Apr 10, 2012
Jacob Carlborg
Apr 10, 2012
Sönke Ludwig
Apr 10, 2012
Jacob Carlborg
Apr 10, 2012
Sönke Ludwig
Apr 10, 2012
John Chapman
Apr 10, 2012
Sönke Ludwig
Apr 09, 2012
Nick Sabalausky
Apr 09, 2012
Sönke Ludwig
Apr 09, 2012
Michel Fortin
Apr 10, 2012
Jacob Carlborg
Apr 10, 2012
Nick Sabalausky
Apr 10, 2012
Jonathan M Davis
Apr 10, 2012
Nick Sabalausky
Apr 10, 2012
Jacob Carlborg
Apr 10, 2012
Sönke Ludwig
Apr 10, 2012
mist
Apr 10, 2012
simendsjo
Apr 10, 2012
mist
April 09, 2012
(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
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
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
"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
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
>
> 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
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
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
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
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