www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Windows 8 Metro support

reply =?ISO-8859-15?Q?S=F6nke_Ludwig?= <sludwig outerproduct.org> writes:
(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.
Apr 09 2012
next sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
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
Apr 09 2012
next sibling parent reply =?ISO-8859-15?Q?S=F6nke_Ludwig?= <sludwig outerproduct.org> writes:
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.
Apr 09 2012
next sibling parent Michel Fortin <michel.fortin michelf.com> writes:
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/
Apr 09 2012
prev sibling parent Jacob Carlborg <doob me.com> writes:
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
Apr 09 2012
prev sibling parent bls <bizprac orange.fr> writes:
On 04/09/2012 10:12 AM, Dmitry Olshansky wrote:

 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.


And some details at :
http://www.codeproject.com/Articles/262151/Visual-Cplusplus-and-WinRT-Metro-Some-fundamentals

Since WinRT programming in C++ is such a pain, I think we can see this 
as a chance for D2.
Apr 09 2012
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
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
Apr 09 2012
parent reply =?ISO-8859-15?Q?S=F6nke_Ludwig?= <sludwig outerproduct.org> writes:
 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.
Apr 09 2012
parent reply Jacob Carlborg <doob me.com> writes:
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
Apr 09 2012
parent reply =?ISO-8859-15?Q?S=F6nke_Ludwig?= <sludwig outerproduct.org> writes:
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.
Apr 09 2012
parent reply Jacob Carlborg <doob me.com> writes:
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
Apr 09 2012
parent reply =?ISO-8859-15?Q?S=F6nke_Ludwig?= <sludwig outerproduct.org> writes:
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.
Apr 10 2012
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2012-04-10 09:24, Sönke Ludwig wrote:


 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.


That doesn't sound like a good idea, to force every language to rewrite 
their runtime and standard library.

-- 
/Jacob Carlborg
Apr 10 2012
parent =?ISO-8859-15?Q?S=F6nke_Ludwig?= <sludwig outerproduct.org> writes:
Am 10.04.2012 09:30, schrieb Jacob Carlborg:

 On 2012-04-10 09:24, Sönke Ludwig wrote:


 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.


 That doesn't sound like a good idea, to force every language to rewrite
 their runtime and standard library.


... or they use the VisualStudio C/C++ runtime as their base, which is 
already adapted.

But since this is all just theory and guesswork, some real tests are 
probably in order - maybe I can do that tomorrow but unfortunately, my 
time is currently extremely limited.
Apr 10 2012
prev sibling parent reply "John Chapman" <johnch_atms hotmail.com> writes:
On Tuesday, 10 April 2012 at 07:24:09 UTC, Sönke Ludwig wrote:

 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.


Not strictly true. Here's the subset of the Win32 API that can be 
used in Metro apps: 
http://msdn.microsoft.com/en-us/library/windows/apps/br205757.aspx
Apr 10 2012
parent =?UTF-8?B?IlPDtm5rZQ==?= Ludwig" <sludwig_ _outerproduct.org> writes:
On Tuesday, 10 April 2012 at 07:58:57 UTC, John Chapman wrote:

 On Tuesday, 10 April 2012 at 07:24:09 UTC, Sönke Ludwig wrote:

 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.


 Not strictly true. Here's the subset of the Win32 API that can 
 be used in Metro apps: 
 http://msdn.microsoft.com/en-us/library/windows/apps/br205757.aspx


Great! I was looking for such a list, thanks.

So since you have at least HeapAlloc and some other functions, it 
looks like a doable task to just adjust the existing runtime. 
Just many functions like CreateFile would need to be changed to 
their allowed counterparts as it looks.

But the question is still if that snn.lib or what else is beeing 
linked in can be adjusted or still needs to be replaced.
Apr 10 2012
prev sibling next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"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.
Apr 09 2012
parent =?ISO-8859-15?Q?S=F6nke_Ludwig?= <sludwig outerproduct.org> writes:
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.
Apr 09 2012
prev sibling next sibling parent reply Michel Fortin <michel.fortin michelf.com> writes:
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/
Apr 09 2012
parent Jacob Carlborg <doob me.com> writes:
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
Apr 09 2012
prev sibling parent reply "Nick Sabalausky" <a a.a> writes:
"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
Apr 09 2012
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
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
Apr 09 2012
next sibling parent "Nick Sabalausky" <a a.a> writes:
"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.
Apr 09 2012
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
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
Apr 09 2012
prev sibling next sibling parent =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig outerproduct.org> writes:
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.
Apr 10 2012
prev sibling parent reply "mist" <none none.none> writes:
Oh, crap.
I wish your message could have appeared a week or two earlier. 
Almost smashed my head against the wall trying to figure the hell 
out of x64 seg fault.
Apr 10 2012
parent reply simendsjo <simendsjo gmail.com> writes:
On Tue, 10 Apr 2012 15:02:15 +0200, mist <none none.none> wrote:


 Oh, crap.
 I wish your message could have appeared a week or two earlier. Almost  
 smashed my head against the wall trying to figure the hell out of x64  
 seg fault.


I hit it a couple of weeks ago and posted in .learn :)
My head was quite bloody by the time someone referenced that bug too
Apr 10 2012
parent "mist" <none none.none> writes:
Ugh, my spare time is rather hindered by trying to follow all 
messages in D.announce and D groups ( and googling for all 
unknown stuff cool guys are talking about ) - I am afraid that 
adding D.learn to this everyday list would have made me a goner.. 
and you have just named a reason why it should be done! :)
Apr 10 2012