www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - First working Win64 program!

reply Walter Bright <newshound2 digitalmars.com> writes:
No, it ain't much, some of it is jury rigged, and there's a heluva lot more
work 
to do. But we've got liftoff!

-------------------------------------
import core.stdc.stdio;

extern (C) int main()
{
     puts("hello world\n");
     return 0;
}
-------------------------------------

   dmd -c -m64 hello.d
   cl hello.obj
   hello

hello world!
Aug 11 2012
next sibling parent reply =?ISO-8859-1?Q?S=F6nke_Ludwig?= <sludwig outerproduct.org> writes:
Am 11.08.2012 10:16, schrieb Walter Bright:
 No, it ain't much, some of it is jury rigged, and there's a heluva lot
 more work to do. But we've got liftoff!

 -------------------------------------
 import core.stdc.stdio;

 extern (C) int main()
 {
      puts("hello world\n");
      return 0;
 }
 -------------------------------------

    dmd -c -m64 hello.d
    cl hello.obj
    hello

 hello world!

Yeehaa! Best news of the last years and even two news that is :-)
Aug 11 2012
parent "Michael" <pr m1xa.com> writes:
   dmd -c -m64 hello.d
   cl hello.obj
   hello

 hello world!

Yeehaa! Best news of the last years and even two news that is :-)

Cool!!!!!!!!11111
Aug 11 2012
prev sibling next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Saturday, 11 August 2012 at 08:17:13 UTC, Walter Bright wrote:
 No, it ain't much, some of it is jury rigged, and there's a 
 heluva lot more work to do. But we've got liftoff!

 -------------------------------------
 import core.stdc.stdio;

 extern (C) int main()
 {
     puts("hello world\n");
     return 0;
 }
 -------------------------------------

   dmd -c -m64 hello.d
   cl hello.obj
   hello

 hello world!

HURRAY! Congratulations. -- Paulo
Aug 11 2012
prev sibling next sibling parent =?UTF-8?B?IuaLlueLl+aVo+atpSI=?= <djj shumtn.com> writes:
On Saturday, 11 August 2012 at 08:17:13 UTC, Walter Bright wrote:
 No, it ain't much, some of it is jury rigged, and there's a 
 heluva lot more work to do. But we've got liftoff!

 -------------------------------------
 import core.stdc.stdio;

 extern (C) int main()
 {
     puts("hello world\n");
     return 0;
 }
 -------------------------------------

   dmd -c -m64 hello.d
   cl hello.obj
   hello

 hello world!

Congratulations! But the possibility of acceding to generate so files?
Aug 11 2012
prev sibling next sibling parent "Bernard Helyer" <b.helyer gmail.com> writes:
On Saturday, 11 August 2012 at 14:04:39 UTC, 拖狗散步 wrote:
 On Saturday, 11 August 2012 at 08:17:13 UTC, Walter Bright 
 wrote:
 No, it ain't much, some of it is jury rigged, and there's a 
 heluva lot more work to do. But we've got liftoff!

 -------------------------------------
 import core.stdc.stdio;

 extern (C) int main()
 {
    puts("hello world\n");
    return 0;
 }
 -------------------------------------

  dmd -c -m64 hello.d
  cl hello.obj
  hello

 hello world!


Congratulations! :D
 Congratulations!
 But the possibility of acceding to generate so files?

GDC already can. The .so thing is more of a druntime issue than it is a compiler issue, AFAIK.
Aug 11 2012
prev sibling next sibling parent kraybourne <stdin kraybourne.com> writes:
On 8/11/12 10:16 , Walter Bright wrote:
 No, it ain't much, some of it is jury rigged, and there's a heluva lot
 more work to do. But we've got liftoff!

 -------------------------------------
 import core.stdc.stdio;

 extern (C) int main()
 {
 puts("hello world\n");
 return 0;
 }
 -------------------------------------

 dmd -c -m64 hello.d
 cl hello.obj
 hello

 hello world!

\o/ sweet!!!
Aug 11 2012
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 8/11/12 4:16 AM, Walter Bright wrote:
 No, it ain't much, some of it is jury rigged, and there's a heluva lot
 more work to do. But we've got liftoff!

 -------------------------------------
 import core.stdc.stdio;

 extern (C) int main()
 {
 puts("hello world\n");
 return 0;
 }
 -------------------------------------

 dmd -c -m64 hello.d
 cl hello.obj
 hello

 hello world!

Cool, but the correct implementation should be ------------------------------------- import core.stdc.stdio; extern (C) int main() { return puts("hello world\n") < 0; } ------------------------------------- :o) Andrei
Aug 11 2012
prev sibling next sibling parent "F i L" <witte2008 gmail.com> writes:
On Saturday, 11 August 2012 at 08:17:13 UTC, Walter Bright wrote:
 No, it ain't much, some of it is jury rigged, and there's a 
 heluva lot more work to do. But we've got liftoff!

 -------------------------------------
 import core.stdc.stdio;

 extern (C) int main()
 {
     puts("hello world\n");
     return 0;
 }
 -------------------------------------

   dmd -c -m64 hello.d
   cl hello.obj
   hello

 hello world!

Awesome!
Aug 11 2012
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-08-11 10:16, Walter Bright wrote:
 No, it ain't much, some of it is jury rigged, and there's a heluva lot
 more work to do. But we've got liftoff!

 -------------------------------------
 import core.stdc.stdio;

 extern (C) int main()
 {
      puts("hello world\n");
      return 0;
 }
 -------------------------------------

    dmd -c -m64 hello.d
    cl hello.obj
    hello

 hello world!

That's great news. -- /Jacob Carlborg
Aug 11 2012
prev sibling next sibling parent "nazriel" <spam dzfl.pl> writes:
On Saturday, 11 August 2012 at 08:17:13 UTC, Walter Bright wrote:
 No, it ain't much, some of it is jury rigged, and there's a 
 heluva lot more work to do. But we've got liftoff!

 -------------------------------------
 import core.stdc.stdio;

 extern (C) int main()
 {
     puts("hello world\n");
     return 0;
 }
 -------------------------------------

   dmd -c -m64 hello.d
   cl hello.obj
   hello

 hello world!

Fuck yea! Great news. Good job Walter!
Aug 11 2012
prev sibling next sibling parent reply "Adam Wilson" <flyboynw gmail.com> writes:
On Sat, 11 Aug 2012 01:16:37 -0700, Walter Bright  
<newshound2 digitalmars.com> wrote:

 No, it ain't much, some of it is jury rigged, and there's a heluva lot  
 more work to do. But we've got liftoff!

 -------------------------------------
 import core.stdc.stdio;

 extern (C) int main()
 {
      puts("hello world\n");
      return 0;
 }
 -------------------------------------

    dmd -c -m64 hello.d
    cl hello.obj
    hello

 hello world!

This is a glorious day indeed! -- Adam Wilson IRC: LightBender Project Coordinator The Horizon Project http://www.thehorizonproject.org/
Aug 11 2012
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 8/11/2012 6:28 PM, Adam Wilson wrote:
 This is a glorious day indeed!

I see everyone likes this direction we're going. Great!
Aug 11 2012
parent Walter Bright <newshound2 digitalmars.com> writes:
On 8/11/2012 8:29 PM, "拖狗散步" wrote:
 Walter Bright They say you're an old man, I think your avatar is really so
young?

Every night, I drink the blood of unborn children.
Aug 11 2012
prev sibling next sibling parent =?UTF-8?B?IuaLlueLl+aVo+atpSI=?= <djj shumtn.com> writes:
On Sunday, 12 August 2012 at 01:52:08 UTC, Walter Bright wrote:
 On 8/11/2012 6:28 PM, Adam Wilson wrote:
 This is a glorious day indeed!

I see everyone likes this direction we're going. Great!

Walter Bright They say you're an old man, I think your avatar is really so young?
Aug 11 2012
prev sibling next sibling parent "Adam Wilson" <flyboynw gmail.com> writes:
On Sat, 11 Aug 2012 21:18:17 -0700, Walter Bright  =

<newshound2 digitalmars.com> wrote:

 On 8/11/2012 8:29 PM, "=E6=8B=96=E7=8B=97=E6=95=A3=E6=AD=A5" wrote:
 Walter Bright They say you're an old man, I think your avatar is real=


 so young?

Every night, I drink the blood of unborn children.

Actively working at scaring them off now, ehh? ;-) -- = Adam Wilson IRC: LightBender Project Coordinator The Horizon Project http://www.thehorizonproject.org/
Aug 11 2012
prev sibling next sibling parent Jordi Sayol <g.sayol yahoo.es> writes:
Al 12/08/12 06:18, En/na Walter Bright ha escrit:
 On 8/11/2012 8:29 PM, "=E6=8B=96=E7=8B=97=E6=95=A3=E6=AD=A5" wrote:
 Walter Bright They say you're an old man, I think your avatar is reall=


=20
 Every night, I drink the blood of unborn children.
=20

Now I understand many many things... :-) --=20 Jordi Sayol
Aug 11 2012
prev sibling next sibling parent reply =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <alex lycus.org> writes:
On 11-08-2012 10:16, Walter Bright wrote:
 No, it ain't much, some of it is jury rigged, and there's a heluva lot
 more work to do. But we've got liftoff!

 -------------------------------------
 import core.stdc.stdio;

 extern (C) int main()
 {
      puts("hello world\n");
      return 0;
 }
 -------------------------------------

    dmd -c -m64 hello.d
    cl hello.obj
    hello

 hello world!

This is fabulous news! One question: Will the 32-bit tool chain also be able to use the MSVC runtime and linker eventually? It would make things /a lot/ easier if both bitnesses used the same tool chain. -- Alex Rnne Petersen alex lycus.org http://lycus.org
Aug 12 2012
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 8/12/2012 1:38 AM, Alex Rnne Petersen wrote:
 One question: Will the 32-bit tool chain also be able to use the MSVC runtime
 and linker eventually?

It's not the current plan. Frankly, I think 32 bits is rapidly becoming irrelevant on the desktop.
Aug 12 2012
next sibling parent reply Sean Cavanaugh <WorksOnMyMachine gmail.com> writes:
On 8/12/2012 4:12 PM, Walter Bright wrote:
 On 8/12/2012 1:38 AM, Alex Rnne Petersen wrote:
 One question: Will the 32-bit tool chain also be able to use the MSVC
 runtime
 and linker eventually?

It's not the current plan. Frankly, I think 32 bits is rapidly becoming irrelevant on the desktop.

Post windows 8 launch we should start seeing mainstream games shipping 32 and 64 bit binaries together in the same box. We already have moved off of 32 bit in house for our editors and tools. The biggest hangup is Microsoft keeps shipping 32 bit OSes, and we still have to support XP at least through the end of the year. With a little luck Win8 will be the last 32 bit one.
Aug 12 2012
parent reply torhu <no spam.invalid> writes:
On 12.08.2012 23:21, Sean Cavanaugh wrote:
 Post windows 8 launch we should start seeing mainstream games shipping
 32 and 64 bit binaries together in the same box.  We already have moved
 off of 32 bit in house for our editors and tools.  The biggest hangup is
 Microsoft keeps shipping 32 bit OSes, and we still have to support XP at
 least through the end of the year.  With a little luck Win8 will be the
 last 32 bit one.

Can I ask, what are the reasons you want to move to 64 bits on the Windows platform? Is it higher memory requirements or something else? The game with the highest memory use I've got installed is AFAIK Starcraft II, still at only about one GB. And as you know, 64 bit apps can have lower performance than 32 bits in some cases. So I'm curious to know what the reasons are in your case.
Aug 12 2012
parent reply Sean Cavanaugh <WorksOnMyMachine gmail.com> writes:
On 8/12/2012 6:43 PM, torhu wrote:
 On 12.08.2012 23:21, Sean Cavanaugh wrote:
 Post windows 8 launch we should start seeing mainstream games shipping
 32 and 64 bit binaries together in the same box. We already have moved
 off of 32 bit in house for our editors and tools. The biggest hangup is
 Microsoft keeps shipping 32 bit OSes, and we still have to support XP at
 least through the end of the year. With a little luck Win8 will be the
 last 32 bit one.

Can I ask, what are the reasons you want to move to 64 bits on the Windows platform? Is it higher memory requirements or something else? The game with the highest memory use I've got installed is AFAIK Starcraft II, still at only about one GB. And as you know, 64 bit apps can have lower performance than 32 bits in some cases. So I'm curious to know what the reasons are in your case.

32 bit Windows games are capped at around 1.3 GB due to WinXP support. You can get closer to 1.7 GB of address space out of your 32 bit apps when run under 64 bit windows, but thats about it, without playing with /3GB LARGEADDRESSAWARE flags etc. Games that push 1.3 GB or more run the risk of crashing due to both address space fragmentation and running out of memory from the heap. In XP, you also run the risk of crashing when alt-tabing out of the game and back. The video card's address space gets unmapped while you are away, and the app might have fragmented your nice 512 MB of contiguous while processing in the background, which causes the driver to fail to map the device back into your address space when you alt-tab crash, in a pretty much unrecoverable error. Vista fixed this by mapping the resources to the address space when you lock the resources, instead of a huge chunk of the video card when the app had an open and valid (not-lost) device context. Also, having the full address space opens up the ability to store game data into memory mapped files, which can greatly simplify loading data. Halo was designed this way for the XBOX, though for the PC version we had to modify the code to handle loading to alternate addresses with patched fixups if some random dll had taken the prefered load address at startup. Since it was done in 32 bits each level had the same load address, but in 64 bits you could give each environment its own address range, which makes it very nice for getting a new area loaded while you are playing in the previous one (run a separate thread to touch all the new pages etc).
Aug 12 2012
next sibling parent Sean Cavanaugh <WorksOnMyMachine gmail.com> writes:
On 8/12/2012 8:15 PM, Andrej Mitrovic wrote:
 On 8/13/12, Sean Cavanaugh<WorksOnMyMachine gmail.com>  wrote:
 we had to modify the code

Sure enough I've found your name: http://www.microsoft.com/games/mgsgamecatalog/halopccredits.aspx I noticed you before here but never realized you worked on Halo. It's cool to see people of your caliber having interest in D! :)

I have a theory that game development accelerates the rate at which you learn to hate C++
Aug 12 2012
prev sibling parent reply torhu <no spam.invalid> writes:
On 13.08.2012 02:59, Sean Cavanaugh wrote:
 On 8/12/2012 6:43 PM, torhu wrote:
 On 12.08.2012 23:21, Sean Cavanaugh wrote:
 Post windows 8 launch we should start seeing mainstream games shipping
 32 and 64 bit binaries together in the same box. We already have moved
 off of 32 bit in house for our editors and tools. The biggest hangup is
 Microsoft keeps shipping 32 bit OSes, and we still have to support XP at
 least through the end of the year. With a little luck Win8 will be the
 last 32 bit one.

Can I ask, what are the reasons you want to move to 64 bits on the Windows platform? Is it higher memory requirements or something else? The game with the highest memory use I've got installed is AFAIK Starcraft II, still at only about one GB. And as you know, 64 bit apps can have lower performance than 32 bits in some cases. So I'm curious to know what the reasons are in your case.

32 bit Windows games are capped at around 1.3 GB due to WinXP support. You can get closer to 1.7 GB of address space out of your 32 bit apps when run under 64 bit windows, but thats about it, without playing with /3GB LARGEADDRESSAWARE flags etc. Games that push 1.3 GB or more run the risk of crashing due to both address space fragmentation and running out of memory from the heap.

Ok, so using LARGEADDRESSAWARE doesn't improve the situation on XP 64? What about on Vista 64?
Aug 12 2012
parent Sean Cavanaugh <WorksOnMyMachine gmail.com> writes:
On 8/12/2012 8:22 PM, torhu wrote:
 Ok, so using LARGEADDRESSAWARE doesn't improve the situation on XP 64?
 What about on Vista 64?

On XP64 it would help some, but the video adapter is still mapped to a huge contiguous range due to the XP driver model. Basically you get 1 extra GB (2.3GB effective usable instead of 1.3). Under 64 bit Vista/7 32 bit LAA apps get almost a full 4 GB to play with, and if they change their textures to default pool or use D3D10 or newer can get their texture data out of the app's address space as well, which is a huge percentage of a game's memory usage.
Aug 12 2012
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 8/12/2012 9:44 PM, Nick Sabalausky wrote:
 Walter Bright <newshound2 digitalmars.com> wrote:
 Frankly, I think 32 bits is rapidly
 becoming irrelevant on the desktop.

Bullshit. There will always be plenty of things that don't need 64-bits and/or will only incur unnecessary bloat with 64-bit.

You could say the same about 16 bit code. 16 bit programs are tiny relative to their 32 bit equivalents.
Aug 12 2012
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 8/12/2012 10:50 PM, Nick Sabalausky wrote:
 Even still, it's a far cry to compare ditching 16-bit with
 (effectively) shunning 32-bit. Yes, 64-bit is bocoming more and more
 important, and yes, 32-bit is becoming less and less important, but I
 still think you're very much jumping the gun here.

We'll see. It has already happened on OSX.
Aug 12 2012
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 8/12/2012 11:29 PM, Jonathan M Davis wrote:
 On Sunday, August 12, 2012 23:21:48 Walter Bright wrote:
 On 8/12/2012 10:50 PM, Nick Sabalausky wrote:
 Even still, it's a far cry to compare ditching 16-bit with
 (effectively) shunning 32-bit. Yes, 64-bit is bocoming more and more
 important, and yes, 32-bit is becoming less and less important, but I
 still think you're very much jumping the gun here.

We'll see. It has already happened on OSX.

OSX has a lot less backwards compatibility to worry about.

I fully understand that is why they are a first mover in leaving 32 bits behind.
 While D is primarily going to be used for writing new programs (and therefore
 can choose to be 64-bit), it's a huge impediment to adding D into an existing
 code base for it not be able to link with Microsoft's 32-bit linker. How much
 that will ultimately matter, I don't know, but I think that it's pretty much a
 guarante that we're losing quite a bit in the short term by not having
 compatability with 32-bit Microsoft C/C+ on Windows.

64 bits is far more important. We don't have arrows for every target, we have to pick the juiciest ones.
Aug 13 2012
parent Walter Bright <newshound2 digitalmars.com> writes:
On 8/13/2012 3:55 AM, d_follower wrote:
 Does that mean that we get x64 support on Windows (without legacy OMF support)?
 Linking with MSVC-produced libraries will work, too?

Yes.
Aug 13 2012
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2012-08-13 08:21, Walter Bright wrote:

 We'll see. It has already happened on OSX.

The good think on Mac OS X is that basically all system libraries are universal binaries (both 32 and 64bit) meaning it really doesn't matter for the user if an application is 32 or 64bit. BTW, around 6.6% of my currently running processes are 32bit. Mac OS X 10.7 Lion. -- /Jacob Carlborg
Aug 13 2012
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 8/13/2012 6:23 AM, Jacob Carlborg wrote:
 On 2012-08-13 08:21, Walter Bright wrote:

 We'll see. It has already happened on OSX.

The good think on Mac OS X is that basically all system libraries are universal binaries (both 32 and 64bit) meaning it really doesn't matter for the user if an application is 32 or 64bit. BTW, around 6.6% of my currently running processes are 32bit. Mac OS X 10.7 Lion.

True, but consider that dmd is a 64 bit app, and nobody either complains about it or notices, and dmd by default produces a 64 bit app, and as far as I can tell, nobody has noticed that either.
Aug 13 2012
parent reply Jacob Carlborg <doob me.com> writes:
On 2012-08-13 20:29, Walter Bright wrote:

 True, but consider that dmd is a 64 bit app, and nobody either complains
 about it or notices, and dmd by default produces a 64 bit app, and as
 far as I can tell, nobody has noticed that either.

I was agreeing with you :) One thing that we do notice is when interfacing with C libraries. I'm thinking of the bug where DMD doesn't pass structs correctly on 64bit. What's the status of that BTW? -- /Jacob Carlborg
Aug 14 2012
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 8/14/2012 7:30 AM, Jacob Carlborg wrote:
 I was agreeing with you :) One thing that we do notice is when interfacing with
 C libraries. I'm thinking of the bug where DMD doesn't pass structs correctly
on
 64bit. What's the status of that BTW?

It does pass them correctly to D functions, just not to C ones if the struct contains a mix of floating and integer types.
Aug 14 2012
parent reply Jacob Carlborg <doob me.com> writes:
On 2012-08-14 23:05, Walter Bright wrote:

 It does pass them correctly to D functions, just not to C ones if the
 struct contains a mix of floating and integer types.

Ok, so if my structs don't contain any floating point types I will be fine? All other types are ok? Is this in the 2.060 release or do I have get the latest sources from github? -- /Jacob Carlborg
Aug 15 2012
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 8/15/2012 3:28 AM, Jacob Carlborg wrote:
 On 2012-08-14 23:05, Walter Bright wrote:

 It does pass them correctly to D functions, just not to C ones if the
 struct contains a mix of floating and integer types.

Ok, so if my structs don't contain any floating point types I will be fine?

Yes.
 All other types are ok?

Yes.
 Is this in the 2.060 release

Yes.
 or do I have get the latest sources from github?

No.
Aug 15 2012
parent Jacob Carlborg <doob me.com> writes:
On 2012-08-15 21:48, Walter Bright wrote:

 Ok, so if my structs don't contain any floating point types I will be
 fine?

Yes.
 All other types are ok?

Yes.
 Is this in the 2.060 release

Yes.
 or do I have get the latest sources from github?

No.

Thank you. -- /Jacob Carlborg
Aug 15 2012
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-08-13 09:04, Russel Winder wrote:

 <semi-rant>
 Apple's strategy appears to be that computers are non-upgradable,
 non-repairable, disposable items that last until the next release:
 everyone is supposed buy the latest version as soon as it comes out and
 so be on the latest kit(*).

But their products last a lot longer than that. I have had my MacBook since around 2006. I had to change battery and I've upgraded the RAM, except from that everything is working great.
 Therefore Apple don't care about backward
 compatibility in the way some other manufacturers do, e.g. JDK for the
 last 17 years. Of course sometimes this backfires, cf. many white
 MacBooks which have 64-bit processors but 32-bit boot PROMs. OSX detects
 this and will not boot 64-bit. This leads to extraordinary problems
 trying to compile some codes where the compiler detects 64-bit processor
 and assumes a 64-bit kernel API. To build some applications I first have
 to build the whole compiler toolchain so as to deal with this mixed
 chaos.

I never had any problems with 32 vs 64bit on Mac OS X. All system libraries ship with universal binaries (32 and 64bit) and it's dead easy to compile for multiple architectures. -- /Jacob Carlborg
Aug 13 2012
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 8/13/2012 12:41 PM, Sean Kelly wrote:
 Strangely,libc on OSX is very backwards-compatible. To the point where buggy
 functions were preserved as-is and updated versions exported via weird labels
 linked by the compiler using some evil macro code. Needless to say, D
 unfortunalely links to the buggy versions because there's no way to express
 the new symbols in-language. I suppose I should try to sort something out
 using string mixins and inline assembler.

An easy way is to write a .c file for druntime that accepts the call to the buggy function and calls the un-buggy one. That way the magic macros will work. I've thought many times about adding a D feature that allows one to specify "use this random character string instead of the identifier as the symbol name when writing the object file", but never got around to it.
Aug 13 2012
next sibling parent reply =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <alex lycus.org> writes:
On 13-08-2012 23:34, Walter Bright wrote:
 On 8/13/2012 12:41 PM, Sean Kelly wrote:
 Strangely,libc on OSX is very backwards-compatible. To the point where
 buggy
 functions were preserved as-is and updated versions exported via weird
 labels
 linked by the compiler using some evil macro code. Needless to say, D
 unfortunalely links to the buggy versions because there's no way to
 express
 the new symbols in-language. I suppose I should try to sort something out
 using string mixins and inline assembler.

An easy way is to write a .c file for druntime that accepts the call to the buggy function and calls the un-buggy one. That way the magic macros will work. I've thought many times about adding a D feature that allows one to specify "use this random character string instead of the identifier as the symbol name when writing the object file", but never got around to it.

I've wanted a feature like that on several occasions (mostly when interfacing with non-C/C++ languages). How hard it would it be to implement? Theoretically, it sounds simple enough. -- Alex Rønne Petersen alex lycus.org http://lycus.org
Aug 13 2012
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 8/13/2012 2:37 PM, Alex Rønne Petersen wrote:
 I've wanted a feature like that on several occasions (mostly when interfacing
 with non-C/C++ languages). How hard it would it be to implement? Theoretically,
 it sounds simple enough.

You could do it with a pragma or something. It's always going to look ugly, though.
Aug 13 2012
parent =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <alex lycus.org> writes:
On 13-08-2012 23:43, Walter Bright wrote:
 On 8/13/2012 2:37 PM, Alex Rønne Petersen wrote:
 I've wanted a feature like that on several occasions (mostly when
 interfacing
 with non-C/C++ languages). How hard it would it be to implement?
 Theoretically,
 it sounds simple enough.

You could do it with a pragma or something. It's always going to look ugly, though.

With some help from Iain, I managed to hack something together: https://github.com/D-Programming-Language/dmd/pull/1085 -- Alex Rønne Petersen alex lycus.org http://lycus.org
Aug 14 2012
prev sibling parent reply "Daniel Murphy" <yebblies nospamgmail.com> writes:
"Alex Rnne Petersen" <alex lycus.org> wrote in message 
news:k0bs29$1bpl$1 digitalmars.com...
 On 13-08-2012 23:34, Walter Bright wrote:
 On 8/13/2012 12:41 PM, Sean Kelly wrote:

 I've thought many times about adding a D feature that allows one to
 specify "use this random character string instead of the identifier as
 the symbol name when writing the object file", but never got around to 
 it.

I've wanted a feature like that on several occasions (mostly when interfacing with non-C/C++ languages). How hard it would it be to implement? Theoretically, it sounds simple enough.

Pretty easy. I can't remember why I wanted this in the first place, maybe trying to interface with c longs? It probably needs updating (being over a year old) but the code is trivial. https://github.com/yebblies/dmd/pull/new/pragma_mangle
Aug 14 2012
parent =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <alex lycus.org> writes:
On 14-08-2012 14:00, Daniel Murphy wrote:
 "Alex Rnne Petersen" <alex lycus.org> wrote in message
 news:k0bs29$1bpl$1 digitalmars.com...
 On 13-08-2012 23:34, Walter Bright wrote:
 On 8/13/2012 12:41 PM, Sean Kelly wrote:

 I've thought many times about adding a D feature that allows one to
 specify "use this random character string instead of the identifier as
 the symbol name when writing the object file", but never got around to
 it.

I've wanted a feature like that on several occasions (mostly when interfacing with non-C/C++ languages). How hard it would it be to implement? Theoretically, it sounds simple enough.

Pretty easy. I can't remember why I wanted this in the first place, maybe trying to interface with c longs? It probably needs updating (being over a year old) but the code is trivial. https://github.com/yebblies/dmd/pull/new/pragma_mangle

Thanks for the link! I hacked something together before I saw your post and it looks surprisingly similar (though my version is a bit more lenient in what it allows in symbol names and how many declarations it can affect): https://github.com/D-Programming-Language/dmd/pull/1085 -- Alex Rnne Petersen alex lycus.org http://lycus.org
Aug 14 2012
prev sibling parent reply =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <alex lycus.org> writes:
On 13-08-2012 23:58, Andrej Mitrovic wrote:
 On 8/13/12, Walter Bright <newshound2 digitalmars.com> wrote:
 I've thought many times about adding a D feature that allows one to specify
 "use
 this random character string instead of the identifier as the symbol name
 when
 writing the object file", but never got around to it.

Isn't that what .def files are for? Or maybe this is only used for DLLs?

That's a Windows-ism. -- Alex Rnne Petersen alex lycus.org http://lycus.org
Aug 13 2012
parent =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <alex lycus.org> writes:
On 14-08-2012 09:25, Paulo Pinto wrote:
 On Monday, 13 August 2012 at 22:07:51 UTC, Alex Rønne Petersen wrote:
 On 13-08-2012 23:58, Andrej Mitrovic wrote:
 On 8/13/12, Walter Bright <newshound2 digitalmars.com> wrote:
 I've thought many times about adding a D feature that allows one to
 specify
 "use
 this random character string instead of the identifier as the symbol
 name
 when
 writing the object file", but never got around to it.

Isn't that what .def files are for? Or maybe this is only used for DLLs?

That's a Windows-ism.

Actually it existed already in VMS and Aix before Windows adopted it.

Fair enough, though the point I wanted to make was more that it's too platform-specific to be a general tool for achieving this. -- Alex Rønne Petersen alex lycus.org http://lycus.org
Aug 14 2012
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 8/13/2012 4:05 PM, Nick Sabalausky wrote:
 Well, not *exactly* the same boat. I always, perhaps mistakenly, assumed
 the OMF issue would eventually get addressed. To see it pretty much
 verified that it *won't* be happening is very discouraging and
 frustrating. The existence of GDC and LDC doesn't solve the problem
 either.

There's only so much I can do with my time. But if someone else wants to do the work, all things are possible.
Aug 14 2012
parent Walter Bright <newshound2 digitalmars.com> writes:
On 8/14/2012 2:44 AM, Bernard Helyer wrote:
 Clearly the solution is to look into cloning technologies.

There can be only one.
Aug 15 2012
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 8/13/12, Sean Cavanaugh <WorksOnMyMachine gmail.com> wrote:
 we had to modify the code

Sure enough I've found your name: http://www.microsoft.com/games/mgsgamecatalog/halopccredits.aspx I noticed you before here but never realized you worked on Halo. It's cool to see people of your caliber having interest in D! :)
Aug 12 2012
prev sibling next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Monday, 13 August 2012 at 01:18:14 UTC, Sean Cavanaugh wrote:
 On 8/12/2012 8:15 PM, Andrej Mitrovic wrote:
 On 8/13/12, Sean Cavanaugh<WorksOnMyMachine gmail.com>  wrote:
 we had to modify the code

Sure enough I've found your name: http://www.microsoft.com/games/mgsgamecatalog/halopccredits.aspx I noticed you before here but never realized you worked on Halo. It's cool to see people of your caliber having interest in D! :)

I have a theory that game development accelerates the rate at which you learn to hate C++

On the other hand, you get to learn lots of stuff to write "Game Programming Gems" chapters about. :)
Aug 13 2012
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Monday, 13 August 2012 at 04:44:43 UTC, Nick Sabalausky wrote:
 It's not the current plan. Frankly, I think 32 bits is rapidly
 becoming irrelevant on the desktop.

Bullshit.

While I agree with the sentiment (in fact, one of my newest computers is 32 bit; I got a mini laptop - not quite netbook, but not regular laptop either - that is 32 bit), it is worth noting that 32 bit D isn't going away. We're going to be in the same boat we're in now, which does work.
Aug 13 2012
prev sibling next sibling parent "Chris Nicholson-Sauls" <ibisbasenji gmail.com> writes:
On Monday, 13 August 2012 at 18:29:13 UTC, Walter Bright wrote:
 On 8/13/2012 6:23 AM, Jacob Carlborg wrote:
 On 2012-08-13 08:21, Walter Bright wrote:

 We'll see. It has already happened on OSX.

The good think on Mac OS X is that basically all system libraries are universal binaries (both 32 and 64bit) meaning it really doesn't matter for the user if an application is 32 or 64bit. BTW, around 6.6% of my currently running processes are 32bit. Mac OS X 10.7 Lion.

True, but consider that dmd is a 64 bit app, and nobody either complains about it or notices, and dmd by default produces a 64 bit app, and as far as I can tell, nobody has noticed that either.

I noticed! But it hasn't been a problem. One of the things I've actually been using D for is writing simple tools for work, to be executed while in livedisc environments (diagnostics and the like), so I have to keep both 32b and 64b versions of everything, and the only missing component was 64b for Windows. So yeah, I'm pretty stoked about this.
Aug 13 2012
prev sibling next sibling parent "Bernard Helyer" <b.helyer gmail.com> writes:
On Tuesday, 14 August 2012 at 08:28:45 UTC, Walter Bright wrote:
 On 8/13/2012 4:05 PM, Nick Sabalausky wrote:
 Well, not *exactly* the same boat. I always, perhaps 
 mistakenly, assumed
 the OMF issue would eventually get addressed. To see it pretty 
 much
 verified that it *won't* be happening is very discouraging and
 frustrating. The existence of GDC and LDC doesn't solve the 
 problem
 either.

There's only so much I can do with my time. But if someone else wants to do the work, all things are possible.

Clearly the solution is to look into cloning technologies.
Aug 14 2012
prev sibling next sibling parent "F i L" <witte2008 gmail.com> writes:
Bernard Helyer wrote:
 Clearly the solution is to look into cloning technologies.

Nah, we just need to write a software sophisticated enough that it can write software itself. Then we'll need to write software simple enough to enjoy micro-managing that software to keep it on task.
Aug 14 2012
prev sibling next sibling parent "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
On Tue, 14 Aug 2012 11:44:43 +0200, Bernard Helyer <b.helyer gmail.com>  
wrote:

 On Tuesday, 14 August 2012 at 08:28:45 UTC, Walter Bright wrote:
 On 8/13/2012 4:05 PM, Nick Sabalausky wrote:
 Well, not *exactly* the same boat. I always, perhaps mistakenly,  
 assumed
 the OMF issue would eventually get addressed. To see it pretty much
 verified that it *won't* be happening is very discouraging and
 frustrating. The existence of GDC and LDC doesn't solve the problem
 either.

There's only so much I can do with my time. But if someone else wants to do the work, all things are possible.

Clearly the solution is to look into cloning technologies.

But wouldn't that create a soulless abomination[1]? [1]: http://dilbert.com/fast/2001-09-28/ -- Simen
Aug 14 2012
prev sibling next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Tuesday, 14 August 2012 at 14:41:20 UTC, F i L wrote:
 [...]

 Then we'll need to write software simple enough to enjoy 
 micro-managing that software to keep it on task.

Can I get it for the offshoring projects I work on? :)
Aug 14 2012
prev sibling next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Wednesday, 15 August 2012 at 10:28:15 UTC, Jacob Carlborg 
wrote:
 On 2012-08-14 23:05, Walter Bright wrote:

 It does pass them correctly to D functions, just not to C ones 
 if the
 struct contains a mix of floating and integer types.

Ok, so if my structs don't contain any floating point types I will be fine? All other types are ok? Is this in the 2.060 release or do I have get the latest sources from github?

Does this not required that the D and C compiler are in sync about data layout? Small sizes structs are often kept in registers. -- Paulo
Aug 15 2012
prev sibling parent "David Nadlinger" <see klickverbot.at> writes:
On Wednesday, 15 August 2012 at 11:15:35 UTC, Paulo Pinto wrote:
 Does this not required that the D and C compiler are in sync 
 about data layout?

 Small sizes structs are often kept in registers.

Yes, extern(C) is intended to be fully ABI-compatible with the respective C ABI on the host system. On *nix systems, this means that the System V AMD64 ABI is followed for parameter passing. The DMD implementation of it, however, still has bugs in the cases mentioned above, as the register assignment scheme is difficult to implement in Walter's backend. The current state _is_ self-consistent, though, so the problems only surface when interfacing with C code. David
Aug 15 2012
prev sibling next sibling parent "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
On Sat, 11 Aug 2012 10:16:37 +0200, Walter Bright  
<newshound2 digitalmars.com> wrote:

 No, it ain't much, some of it is jury rigged, and there's a heluva lot  
 more work to do. But we've got liftoff!

 -------------------------------------
 import core.stdc.stdio;

 extern (C) int main()
 {
      puts("hello world\n");
      return 0;
 }
 -------------------------------------

    dmd -c -m64 hello.d
    cl hello.obj
    hello

 hello world!

Sweet! Congratulations! -- Simen
Aug 12 2012
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Sun, 12 Aug 2012 14:12:43 -0700
Walter Bright <newshound2 digitalmars.com> wrote:

 On 8/12/2012 1:38 AM, Alex R=F8nne Petersen wrote:
 One question: Will the 32-bit tool chain also be able to use the
 MSVC runtime and linker eventually?

It's not the current plan. Frankly, I think 32 bits is rapidly becoming irrelevant on the desktop.

Bullshit. There will always be plenty of things that don't need 64-bits and/or will only incur unnecessary bloat with 64-bit.
Aug 12 2012
prev sibling next sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Sun, 12 Aug 2012 21:54:07 -0700
Walter Bright <newshound2 digitalmars.com> wrote:

 On 8/12/2012 9:44 PM, Nick Sabalausky wrote:
 Walter Bright <newshound2 digitalmars.com> wrote:
 Frankly, I think 32 bits is rapidly
 becoming irrelevant on the desktop.

Bullshit. There will always be plenty of things that don't need 64-bits and/or will only incur unnecessary bloat with 64-bit.

You could say the same about 16 bit code. 16 bit programs are tiny relative to their 32 bit equivalents.

Even still, it's a far cry to compare ditching 16-bit with (effectively) shunning 32-bit. Yes, 64-bit is bocoming more and more important, and yes, 32-bit is becoming less and less important, but I still think you're very much jumping the gun here.
Aug 12 2012
next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, August 12, 2012 23:21:48 Walter Bright wrote:
 On 8/12/2012 10:50 PM, Nick Sabalausky wrote:
 Even still, it's a far cry to compare ditching 16-bit with
 (effectively) shunning 32-bit. Yes, 64-bit is bocoming more and more
 important, and yes, 32-bit is becoming less and less important, but I
 still think you're very much jumping the gun here.

We'll see. It has already happened on OSX.

OSX has a lot less backwards compatibility to worry about. While D is primarily going to be used for writing new programs (and therefore can choose to be 64-bit), it's a huge impediment to adding D into an existing code base for it not be able to link with Microsoft's 32-bit linker. How much that will ultimately matter, I don't know, but I think that it's pretty much a guarante that we're losing quite a bit in the short term by not having compatability with 32-bit Microsoft C/C+ on Windows. - Jonathan M Davis
Aug 12 2012
prev sibling next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Monday, 13 August 2012 at 07:05:11 UTC, Russel Winder wrote:
 On Sun, 2012-08-12 at 23:29 -0700, Jonathan M Davis wrote:
 […]
 OSX has a lot less backwards compatibility to worry about.

Not entirely true. <semi-rant> Apple's strategy appears to be that computers are non-upgradable, non-repairable, disposable items that last until the next release: everyone is supposed buy the latest version as soon as it comes out and so be on the latest kit(*). Therefore Apple don't care about backward compatibility in the way some other manufacturers do, e.g. JDK for the last 17 years. Of course sometimes this backfires, cf. many white MacBooks which have 64-bit processors but 32-bit boot PROMs. OSX detects this and will not boot 64-bit. This leads to extraordinary problems trying to compile some codes where the compiler detects 64-bit processor and assumes a 64-bit kernel API. To build some applications I first have to build the whole compiler toolchain so as to deal with this mixed chaos. (*) And as we know there are a lot of people who actually do this, which is why there is a great market in second hand Apple kit, which is fine for me, since it is reasonable kit at a reasonable price. Unlike new kit. </semi-rant>

It is this type of issues that keeps me away from Apple products.
Aug 13 2012
prev sibling next sibling parent "d_follower" <d_follower fakemail.com> writes:
On Monday, 13 August 2012 at 09:52:05 UTC, Walter Bright wrote:

 64 bits is far more important. We don't have arrows for every 
 target, we have to pick the juiciest ones.

Does that mean that we get x64 support on Windows (without legacy OMF support)? Linking with MSVC-produced libraries will work, too?
Aug 13 2012
prev sibling next sibling parent Sean Kelly <sean invisibleduck.org> writes:
On Aug 13, 2012, at 12:04 AM, Russel Winder <russel winder.org.uk> wrote:

 On Sun, 2012-08-12 at 23:29 -0700, Jonathan M Davis wrote:
 [=E2=80=A6]
 OSX has a lot less backwards compatibility to worry about.

Not entirely true. =20 <semi-rant> Apple's strategy appears to be that computers are non-upgradable, non-repairable, disposable items that last until the next release: everyone is supposed buy the latest version as soon as it comes out and so be on the latest kit(*). Therefore Apple don't care about backward compatibility in the way some other manufacturers do, e.g. JDK for the last 17 years. Of course sometimes this backfires, cf. many white MacBooks which have 64-bit processors but 32-bit boot PROMs. OSX detects this and will not boot 64-bit. This leads to extraordinary problems trying to compile some codes where the compiler detects 64-bit processor and assumes a 64-bit kernel API. To build some applications I first have to build the whole compiler toolchain so as to deal with this mixed chaos. =20 (*) And as we know there are a lot of people who actually do this, which is why there is a great market in second hand Apple kit, which is fine for me, since it is reasonable kit at a reasonable price. Unlike new kit. </semi-rant>

Strangely,libc on OSX is very backwards-compatible. To the point where buggy= functions were preserved as-is and updated versions exported via weird labe= ls linked by the compiler using some evil macro code. Needless to say, D unf= ortunalely links to the buggy versions because there's no way to express the= new symbols in-language. I suppose I should try to sort something out using= string mixins and inline assembler.=20=
Aug 13 2012
prev sibling next sibling parent "Michael" <pr m1xa.com> writes:
No doubt that COFF 64 bits it are good and with high priority, 
though small, but support of COFF 32 bits will be a gift that 
will add popularity to dmd. Anyway I have words that add + to 64 
bit and to 32 bit tools that supports linking with ms toolset.
Aug 13 2012
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 8/13/12, Walter Bright <newshound2 digitalmars.com> wrote:
 I've thought many times about adding a D feature that allows one to specify
 "use
 this random character string instead of the identifier as the symbol name
 when
 writing the object file", but never got around to it.

Isn't that what .def files are for? Or maybe this is only used for DLLs?
Aug 13 2012
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 8/14/12, Alex R=F8nne Petersen <alex lycus.org> wrote:
 That's a Windows-ism.

I think it's technically a linker-ism. Surely LD supports a similar feature= ?
Aug 13 2012
prev sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Monday, 13 August 2012 at 22:07:51 UTC, Alex Rønne Petersen 
wrote:
 On 13-08-2012 23:58, Andrej Mitrovic wrote:
 On 8/13/12, Walter Bright <newshound2 digitalmars.com> wrote:
 I've thought many times about adding a D feature that allows 
 one to specify
 "use
 this random character string instead of the identifier as the 
 symbol name
 when
 writing the object file", but never got around to it.

Isn't that what .def files are for? Or maybe this is only used for DLLs?

That's a Windows-ism.

Actually it existed already in VMS and Aix before Windows adopted it.
Aug 14 2012
prev sibling next sibling parent Russel Winder <russel winder.org.uk> writes:
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sun, 2012-08-12 at 23:29 -0700, Jonathan M Davis wrote:
[=E2=80=A6]
 OSX has a lot less backwards compatibility to worry about.

Not entirely true. <semi-rant> Apple's strategy appears to be that computers are non-upgradable, non-repairable, disposable items that last until the next release: everyone is supposed buy the latest version as soon as it comes out and so be on the latest kit(*). Therefore Apple don't care about backward compatibility in the way some other manufacturers do, e.g. JDK for the last 17 years. Of course sometimes this backfires, cf. many white MacBooks which have 64-bit processors but 32-bit boot PROMs. OSX detects this and will not boot 64-bit. This leads to extraordinary problems trying to compile some codes where the compiler detects 64-bit processor and assumes a 64-bit kernel API. To build some applications I first have to build the whole compiler toolchain so as to deal with this mixed chaos. (*) And as we know there are a lot of people who actually do this, which is why there is a great market in second hand Apple kit, which is fine for me, since it is reasonable kit at a reasonable price. Unlike new kit. </semi-rant> --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Aug 13 2012
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Sun, 12 Aug 2012 23:21:48 -0700
Walter Bright <newshound2 digitalmars.com> wrote:

 On 8/12/2012 10:50 PM, Nick Sabalausky wrote:
 Even still, it's a far cry to compare ditching 16-bit with
 (effectively) shunning 32-bit. Yes, 64-bit is bocoming more and more
 important, and yes, 32-bit is becoming less and less important, but
 I still think you're very much jumping the gun here.

We'll see. It has already happened on OSX.

Whaddya kidding me? That's an Apple product. Apple only makes disposable throw-away devices. "Release it. Kill it off after 2 weeks. Let the sheep shower us with more of their money. Repeat until there's no more hipster morons with money." There's "Apple" and then there's "the rest of reality".
Aug 13 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday, August 13, 2012 02:51:30 Walter Bright wrote:
 64 bits is far more important. We don't have arrows for every target, we
 have to pick the juiciest ones.

I have no idea how much mork work it is to add 32-bit COFF on top of adding 64-bit COFF, and I'm totally fine with just targeting 64-bit COFF for now. I'm just pointing out that there's a definite cost to not having 32-bit COFF support on Windows, whereas your posts seem to imply that you don't think that it's important at all. - Jonathan M Davis
Aug 13 2012
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Mon, 13 Aug 2012 11:23:09 +0200
"Paulo Pinto" <pjmlp progtools.org> wrote:

 On Monday, 13 August 2012 at 01:18:14 UTC, Sean Cavanaugh wrote:
 On 8/12/2012 8:15 PM, Andrej Mitrovic wrote:
 On 8/13/12, Sean Cavanaugh<WorksOnMyMachine gmail.com>  wrote:
 we had to modify the code

Sure enough I've found your name: http://www.microsoft.com/games/mgsgamecatalog/halopccredits.aspx I noticed you before here but never realized you worked on Halo. It's cool to see people of your caliber having interest in D! :)

I have a theory that game development accelerates the rate at which you learn to hate C++

On the other hand, you get to learn lots of stuff to write "Game Programming Gems" chapters about. :)

Good point! I mean, what would ever happen to that series if C++ died? They'd have to change it to "Game Programming...Umm...Filler Material...And Maybe a Small Gem or Two" ;) (It is a good series though.)
Aug 13 2012
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Mon, 13 Aug 2012 15:42:19 +0200
"Adam D. Ruppe" <destructionator gmail.com> wrote:

 On Monday, 13 August 2012 at 04:44:43 UTC, Nick Sabalausky wrote:
 It's not the current plan. Frankly, I think 32 bits is rapidly
 becoming irrelevant on the desktop.

Bullshit.

While I agree with the sentiment (in fact, one of my newest computers is 32 bit; I got a mini laptop - not quite netbook, but not regular laptop either - that is 32 bit), it is worth noting that 32 bit D isn't going away. We're going to be in the same boat we're in now, which does work.

Well, not *exactly* the same boat. I always, perhaps mistakenly, assumed the OMF issue would eventually get addressed. To see it pretty much verified that it *won't* be happening is very discouraging and frustrating. The existence of GDC and LDC doesn't solve the problem either.
Aug 13 2012
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Mon, 13 Aug 2012 11:25:29 +0200
"Paulo Pinto" <pjmlp progtools.org> wrote:

 On Monday, 13 August 2012 at 07:05:11 UTC, Russel Winder wrote:
 Apple's strategy appears to be that computers are 
 non-upgradable,
 non-repairable, disposable items that last until the next 
 release:

It is this type of issues that keeps me away from Apple products.

Along with what I like to call "Orwellian Hipsterism". Or maybe "Orwell-Chic". A noxious combination of intolerably large doses of "trendiness" paired with Big Brother seeping out of every millimeter of the design. And then high prices on top of all that. The idea that Apple is the same company that put out that famous "1984" commercial would be laughable if it weren't so depressing.
Aug 13 2012
prev sibling next sibling parent "Gary Willoughby" <dev kalekold.net> writes:
On Saturday, 11 August 2012 at 08:17:13 UTC, Walter Bright wrote:
 No, it ain't much, some of it is jury rigged, and there's a 
 heluva lot more work to do. But we've got liftoff!

 -------------------------------------
 import core.stdc.stdio;

 extern (C) int main()
 {
     puts("hello world\n");
     return 0;
 }
 -------------------------------------

   dmd -c -m64 hello.d
   cl hello.obj
   hello

 hello world!

Great News! Congratulations!
Aug 20 2012
prev sibling parent mta`chrono <chrono mta-international.net> writes:
yeha :-) +1
Aug 20 2012