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.

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

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.

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.

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: […]
>> 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>

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.

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.

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.

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

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.

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.