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.

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

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>
-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 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

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

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

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.

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.

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?

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

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