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 
 :-)


+1
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 reply =?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
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 reply =?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
parent reply 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
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=




ly  =


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




y so young?

=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 Rønne Petersen
alex lycus.org
http://lycus.org
Aug 12 2012
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 8/12/2012 1:38 AM, Alex Rønne 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 Rønne 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 reply 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
parent reply 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
parent reply "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
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 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 parent reply 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?


=20
 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
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 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
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 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
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
next sibling parent reply "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
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 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 reply Russel Winder <russel winder.org.uk> writes:
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
next sibling parent reply "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
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 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 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 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
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 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
next sibling parent reply "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
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 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 parent reply 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.


=20
 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
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
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 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 Rønne 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 Rønne 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 Rønne Petersen
alex lycus.org
http://lycus.org
Aug 14 2012
prev sibling parent reply 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
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 Rønne Petersen
alex lycus.org
http://lycus.org
Aug 13 2012
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 reply "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
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 "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
parent reply 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
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 reply "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
next sibling parent reply "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
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 "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 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 "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 "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