On 10/14/2012 12:54 PM, Walter Bright wrote:
> http://ftp.digitalmars.com/dmd1beta.zip
> http://ftp.digitalmars.com/dmd2beta.zip

Updated so now stack walking works in the VS debugger.

On 2012-10-17 23:32, Damian wrote:

> Although that would be great, it also means everybody who wants to use
> D2 and have COFF support would also have to get VS. That seems like the
> wrong direction to go in. Be much nicer if D2 can have this out of the box.

No point in removing the already working OMF backend. Let the user choose.

-- 
/Jacob Carlborg

On Thursday, 18 October 2012 at 06:18:02 UTC, Jacob Carlborg wrote:
> On 2012-10-17 23:32, Damian wrote:
>
>> Although that would be great, it also means everybody who wants to use
>> D2 and have COFF support would also have to get VS. That seems like the
>> wrong direction to go in. Be much nicer if D2 can have this out of the box.
>
> No point in removing the already working OMF backend. Let the user choose.

That's what I suggested. keep the existing OMF, but add option to use VC to produce COFF...

On 10/17/2012 4:50 PM, Walter Bright wrote:
> On 10/14/2012 12:54 PM, Walter Bright wrote:
>> http://ftp.digitalmars.com/dmd1beta.zip
>> http://ftp.digitalmars.com/dmd2beta.zip
>
> Updated so now stack walking works in the VS debugger.


New update implementing most of the std.math math functions.

On Friday, 19 October 2012 at 07:12:15 UTC, Walter Bright wrote:
> On 10/17/2012 4:50 PM, Walter Bright wrote:
>> On 10/14/2012 12:54 PM, Walter Bright wrote:
>>> http://ftp.digitalmars.com/dmd1beta.zip
>>> http://ftp.digitalmars.com/dmd2beta.zip
>>
>> Updated so now stack walking works in the VS debugger.
>
>
> New update implementing most of the std.math math functions.

To document my experience/setup

I only have the Windows Vista SDK installed.

sc.ini file changes:
VCINSTALLDIR=C:\Program Files\Microsoft SDKs\Windows\v6.0\VC\
WindowsSdkDir=C:\Program Files\Microsoft SDKs\Windows\v6.0\

In the VSINSTALLDIR I had to copy bin\x64 and lib\x64 as amd64

This allowed for compile/link/run of a hello world. So my next thought was to see if Juno would work. I'm still trying to figure out how to get this example to link:

    import std.stdio;

    pragma(lib, "kernel32.lib");

    extern(Windows)
    int InterlockedDecrement(ref int Addend);

    void main() {
        int i;
        auto a = InterlockedDecrement(i);
    }

test.obj : error LNK2019: unresolved external symbol InterlockedIncrement referenced in function _Dmain

It could link with say int GetLastError(ref int) which is also a kernel32 function.

Awesome work!

On 10/19/2012 9:30 PM, Jesse Phillips wrote:
> test.obj : error LNK2019: unresolved external symbol InterlockedIncrement
> referenced in function _Dmain

InterlockedIncrement is a VC compiler intrinsic, which is why it isn't in the library.

Am 10/14/2012 9:54 PM, schrieb Walter Bright:
> http://ftp.digitalmars.com/dmd1beta.zip http://ftp.digitalmars.com/dmd2beta.zip
> 
> Be the first kid on your block to build a dmd Win64 app!

I get a problem, that is not really 64-bit related, but currently keeps me from trying anything more serious:

const(T[U]) instantiates an AssociativeArray!(U, const(T)) internally
and complains about some failing assignment to a const(T) (without line
number).

I think it should rather create a const(AssociativeArray!(U, T)), which
would probably avoid that error.

Am 10/20/2012 9:20 AM, schrieb Sönke Ludwig:
> Am 10/14/2012 9:54 PM, schrieb Walter Bright:
>> http://ftp.digitalmars.com/dmd1beta.zip http://ftp.digitalmars.com/dmd2beta.zip
>>
>> Be the first kid on your block to build a dmd Win64 app!
> 
> I get a problem, that is not really 64-bit related, but currently keeps me from trying anything more serious:
> 
> const(T[U]) instantiates an AssociativeArray!(U, const(T)) internally
> and complains about some failing assignment to a const(T) (without line
> number).
> 
> I think it should rather create a const(AssociativeArray!(U, T)), which
> would probably avoid that error.
> 

It's a bit more complicated and opAssign/foreach related:

struct Test {
	void opAssign(in Test v) {}
	void opAssign(in Test[string] value){ foreach( k, v; value ){} }
}

Error: function test.Test.opAssign (const(Test) v) is not callable using
argument types (const(Test)) const
Error: cannot implicitly convert expression (p.value) of type
const(Test) to const(Test[string])

On 10/19/2012 11:19 PM, Walter Bright wrote:
> On 10/19/2012 9:30 PM, Jesse Phillips wrote:
>  > test.obj : error LNK2019: unresolved external symbol InterlockedIncrement
>  > referenced in function _Dmain
>
> InterlockedIncrement is a VC compiler intrinsic, which is why it isn't in the
> library.

Probably the best way to deal with this at the moment is to write a .c file that calls InterlockedIncrement, compile it with VC, disassemble the result, and do the same with inline asm in D.

On Saturday, 20 October 2012 at 06:20:15 UTC, Walter Bright wrote:
> On 10/19/2012 9:30 PM, Jesse Phillips wrote:
> > test.obj : error LNK2019: unresolved external symbol
> InterlockedIncrement
> > referenced in function _Dmain
>
> InterlockedIncrement is a VC compiler intrinsic, which is why it isn't in the library.

As per accidental email reply:

If this is true then I'd expect that it wouldn't link for DMD 32bit
nor would I expect the documentation to claim it is part of
kernel32.lib

http://msdn.microsoft.com/en-us/library/windows/desktop/ms683614%28v=vs.85%29.aspx

Based on results, you are correct that it isn't in the library, which
by no means would be your fault. But I'm ultimately going to need to
figure out how to replace it so Juno works with 64 bit D.

I'll have to see if I can dig up some smaller projects that should be
usable with Windows and test them out.

Thanks for the reply.