www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - D1 & D2 alpha's for Win64

reply Walter Bright <newshound2 digitalmars.com> writes:
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!
Oct 14 2012
next sibling parent Benjamin Thaut <code benjamin-thaut.de> writes:
Am 14.10.2012 21:54, 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!

Nice, did any of the known issues get fixed or is the list still the same? Kind Regards Benjamin Thaut
Oct 14 2012
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Walter Bright:
 http://ftp.digitalmars.com/dmd2beta.zip

 Be the first kid on your block to build a dmd Win64 app!

The changelog section is not in good state, it misses parts and newlines. Bye, bearophile
Oct 14 2012
prev sibling next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 10/14/12, Walter Bright <newshound2 digitalmars.com> wrote:
 Be the first kid on your block to build a dmd Win64 app!

But this is without Phobos support? D:\DMD\dmd2\windows\bin\..\..\src\phobos\std\algorithm.d(317): Error: module string is in file 'std\c\string.d' which cannot be read I can't test much if Phobos can't be used. :)
Oct 14 2012
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/14/2012 3:27 PM, Andrej Mitrovic wrote:
 D:\DMD\dmd2\windows\bin\..\..\src\phobos\std\algorithm.d(317): Error:
 module string is in file 'std\c\string.d' which cannot be read

Fixed.
Oct 14 2012
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/14/2012 6:08 PM, Andrej Mitrovic wrote:
 Ok so we're only supposed to compile with -c when using -m64? I don't
 suppose DMD could automatically invoke the VC linker?

It does automatically invoke the VC linker. You'll need to set the VCINSTALLDIR environment variable. I set it with sc.ini as: --------------------- [Environment] LIB=c:\cbx\mars\phobos;c:\cbx\mars\druntime\lib;c:\dm\lib\;c:\curl\lib DDFLAGS=-Ic:\cbx\mars\phobos DFLAGS=-Ic:\cbx\mars\phobos;c:\cbx\mars\druntime\import #LINKCMD=c:\dm\bin\link.exe VCINSTALLDIR=C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\ WindowsSdkDir=C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\ ----------------------
Oct 14 2012
parent Rainer Schuetze <r.sagitario gmx.de> writes:
On 10/15/2012 3:44 AM, Walter Bright wrote:
 On 10/14/2012 6:08 PM, Andrej Mitrovic wrote:
  > Ok so we're only supposed to compile with -c when using -m64? I don't
  > suppose DMD could automatically invoke the VC linker?
  >

 It does automatically invoke the VC linker.

 You'll need to set the VCINSTALLDIR environment variable. I set it with
 sc.ini as:

 ---------------------
 [Environment]
 LIB=c:\cbx\mars\phobos;c:\cbx\mars\druntime\lib;c:\dm\lib\;c:\curl\lib
 DDFLAGS=-Ic:\cbx\mars\phobos
 DFLAGS=-Ic:\cbx\mars\phobos;c:\cbx\mars\druntime\import
 #LINKCMD=c:\dm\bin\link.exe
 VCINSTALLDIR=C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\
 WindowsSdkDir=C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\
 ----------------------

I guess there should be different environments for each architecture specified in sc.ini. Especially the LIB variable will never mix because the windows sdk libraries are called the same on both architectures. A problem with that is the DFLAGS variable: it is read before the command line, so you don't know whether -m32 or -m64 is passed (and it might even specify the switch itself), so you don't know which architecture to use. A solution might be to have additional environment blocks [Environment32] and [Environment64] that are evaluated after the command line processing.
Oct 15 2012
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 10/15/12, Walter Bright <newshound2 digitalmars.com> wrote:
 On 10/14/2012 3:27 PM, Andrej Mitrovic wrote:
 D:\DMD\dmd2\windows\bin\..\..\src\phobos\std\algorithm.d(317): Error:
 module string is in file 'std\c\string.d' which cannot be read

Fixed.

Ok so we're only supposed to compile with -c when using -m64? I don't suppose DMD could automatically invoke the VC linker?
Oct 14 2012
prev sibling next sibling parent reply "Michael" <pr m1xa.com> writes:
On Sunday, 14 October 2012 at 19:55:20 UTC, Walter Bright wrote:
 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!

On Win 2008 R2: 1. Path for VS 11: C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\bin\x86_amd64 Simple can be renamed to ..\amd64 2. mspdb110.dll not found: In cmd: C:\dmd2\windows\bin>path=%path%;C:\Program Files (x86)\Microsoft Visual Studio 1 1.0\Common7\IDE 3. C:\dmd2\windows\bin>dmd -m64 t64.d Microsoft (R) Incremental Linker Version 11.00.50727.1 Copyright (C) Microsoft Corporation. All rights reserved. LINK : fatal error LNK1104: cannot open file 'phobos64.lib' --- errorlevel 1104 If phobos.lib renamed to phobos64.lib Microsoft (R) Incremental Linker Version 11.00.50727.1 Copyright (C) Microsoft Corporation. All rights reserved. .\..\lib\phobos64.lib : warning LNK4003: invalid library format; library ignored t64.obj : error LNK2001: unresolved external symbol main ...
Oct 15 2012
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/15/2012 1:27 PM, Michael wrote:
 LINK : fatal error LNK1104: cannot open file 'phobos64.lib'
 --- errorlevel 1104

Fixed.
Oct 15 2012
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/15/2012 2:21 PM, Michael wrote:> On Monday, 15 October 2012 at 20:39:14 
UTC, Walter Bright wrote:
 On 10/15/2012 1:27 PM, Michael wrote:
 LINK : fatal error LNK1104: cannot open file 'phobos64.lib'
 --- errorlevel 1104

Fixed.

dmd -m64 t64.d -- import std.stdio; void main() { writeln("Win 64!"); } --

You should be linking with the VC libraries, not the 32 bit dmc ones. Try disabling the LIB path in sc.ini.
 .\..\lib\shell32.lib : warning LNK4003: invalid library format; library ignored
 .\..\lib\kernel32.lib : warning LNK4003: invalid library format; library
ignored
 .\..\lib\shell32.lib : warning LNK4003: invalid library format; library ignored
 .\..\lib\kernel32.lib : warning LNK4003: invalid library format; library
ignored
 LIBCMT.lib(a_map.obj) : error LNK2019: unresolved external symbol
 __imp_WideCharToMultiByte referenced in function "int __cdecl
 __crtLCMapStringA_stat(struct localeinfo_struct *,wchar_t const *,unsigned
 long,char const *,int,char *,int,int,int)"
 (?__crtLCMapStringA_stat  YAHPEAUlocaleinfo_struct  PEB_WKPEBDHPEADHHH Z)
 LIBCMT.lib(a_loc.obj) : error LNK2001: unresolved external symbol
 __imp_WideCharToMultiByte
 phobos64.lib(dmain2_4a7_1a5.obj) : error LNK2001: unresolved external symbol
 __imp_WideCharToMultiByte
 LIBCMT.lib(a_env.obj) : error LNK2001: unresolved external symbol
 __imp_WideCharToMultiByte
 LIBCMT.lib(wctomb.obj) : error LNK2001: unresolved external symbol
 __imp_WideCharToMultiByte
 LIBCMT.lib(write.obj) : error LNK2001: unresolved external symbol
 __imp_WideCharToMultiByte
 phobos64.lib(dmain2_4a7_1a5.obj) : error LNK2019: unresolved external symbol
 IsDebuggerPresent referenced in function main
 phobos64.lib(dmain2_4a7_1a5.obj) : error LNK2019: unresolved external symbol
 LocalFree referenced in function main
 phobos64.lib(dmain2_4a7_1a5.obj) : error LNK2019: unresolved external symbol
 GetCommandLineW referenced in function main
 phobos64.lib(dmain2_4a7_1a5.obj) : error LNK2019: unresolved external symbol
 CommandLineToArgvW referenced in function main
 phobos64.lib(thread_1b9_21c.obj) : error LNK2001: unresolved external symbol
 __imp_InitializeCriticalSection
 phobos64.lib(mutex_335_213.obj) : error LNK2001: unresolved external symbol
 __imp_InitializeCriticalSection
 phobos64.lib(monitor__519_6fd.obj) : error LNK2019: unresolved external symbol
 __imp_InitializeCriticalSection referenced in function _d_monitor_create


 and ... ... ...

Oct 15 2012
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/16/2012 8:58 AM, Gor Gyolchanyan wrote:
 It worked fine for me at first! This is awesome!

Great!
 But is it possible to use VC linker for 32-bit architectures?

No.
Oct 16 2012
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 10/16/2012 11:36 AM, Michael wrote:
 On Tuesday, 16 October 2012 at 16:44:59 UTC, Walter Bright wrote:
 On 10/16/2012 8:58 AM, Gor Gyolchanyan wrote:
 It worked fine for me at first! This is awesome!

Great!

I tried a different lib paths, got same unresolved symbols. I have VC 10 & VC 11 Express editions. amd64 folder only in VC 11. Maybe it only work on Pro editions of VS?

Do a SET command and remove your LIB definitions. You've got to get it to search the VC lib locations first.
Oct 16 2012
prev sibling parent Jacob Carlborg <doob me.com> writes:
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
Oct 17 2012
prev sibling next sibling parent "Michael" <pr m1xa.com> writes:
But in 32 mode with same sc.ini works fine.
Oct 15 2012
prev sibling next sibling parent "Michael" <pr m1xa.com> writes:
On Monday, 15 October 2012 at 20:39:14 UTC, Walter Bright wrote:
 On 10/15/2012 1:27 PM, Michael wrote:
 LINK : fatal error LNK1104: cannot open file 'phobos64.lib'
 --- errorlevel 1104

Fixed.

dmd -m64 t64.d -- import std.stdio; void main() { writeln("Win 64!"); } -- .\..\lib\shell32.lib : warning LNK4003: invalid library format; library ignored .\..\lib\kernel32.lib : warning LNK4003: invalid library format; library ignored .\..\lib\shell32.lib : warning LNK4003: invalid library format; library ignored .\..\lib\kernel32.lib : warning LNK4003: invalid library format; library ignored LIBCMT.lib(a_map.obj) : error LNK2019: unresolved external symbol __imp_WideCharToMultiByte referenced in function "int __cdecl __crtLCMapStringA_stat(struct localeinfo_struct *,wchar_t const *,unsigned long,char const *,int,char *,int,int,int)" (?__crtLCMapStringA_stat YAHPEAUlocaleinfo_struct PEB_WKPEBDHPEADHHH Z) LIBCMT.lib(a_loc.obj) : error LNK2001: unresolved external symbol __imp_WideCharToMultiByte phobos64.lib(dmain2_4a7_1a5.obj) : error LNK2001: unresolved external symbol __imp_WideCharToMultiByte LIBCMT.lib(a_env.obj) : error LNK2001: unresolved external symbol __imp_WideCharToMultiByte LIBCMT.lib(wctomb.obj) : error LNK2001: unresolved external symbol __imp_WideCharToMultiByte LIBCMT.lib(write.obj) : error LNK2001: unresolved external symbol __imp_WideCharToMultiByte phobos64.lib(dmain2_4a7_1a5.obj) : error LNK2019: unresolved external symbol IsDebuggerPresent referenced in function main phobos64.lib(dmain2_4a7_1a5.obj) : error LNK2019: unresolved external symbol LocalFree referenced in function main phobos64.lib(dmain2_4a7_1a5.obj) : error LNK2019: unresolved external symbol GetCommandLineW referenced in function main phobos64.lib(dmain2_4a7_1a5.obj) : error LNK2019: unresolved external symbol CommandLineToArgvW referenced in function main phobos64.lib(thread_1b9_21c.obj) : error LNK2001: unresolved external symbol __imp_InitializeCriticalSection phobos64.lib(mutex_335_213.obj) : error LNK2001: unresolved external symbol __imp_InitializeCriticalSection phobos64.lib(monitor__519_6fd.obj) : error LNK2019: unresolved external symbol __imp_InitializeCriticalSection referenced in function _d_monitor_create and ... ... ...
Oct 15 2012
prev sibling next sibling parent "Gor Gyolchanyan" <gor.f.gyolchanyan gmail.com> writes:
On Monday, 15 October 2012 at 21:40:01 UTC, Walter Bright wrote:
 On 10/15/2012 2:21 PM, Michael wrote:> On Monday, 15 October 
 2012 at 20:39:14 UTC, Walter Bright wrote:
 On 10/15/2012 1:27 PM, Michael wrote:
 LINK : fatal error LNK1104: cannot open file 'phobos64.lib'
 --- errorlevel 1104

Fixed.

dmd -m64 t64.d -- import std.stdio; void main() { writeln("Win 64!"); } --

You should be linking with the VC libraries, not the 32 bit dmc ones. Try disabling the LIB path in sc.ini.
 .\..\lib\shell32.lib : warning LNK4003: invalid library

 .\..\lib\kernel32.lib : warning LNK4003: invalid library

 .\..\lib\shell32.lib : warning LNK4003: invalid library

 .\..\lib\kernel32.lib : warning LNK4003: invalid library

 LIBCMT.lib(a_map.obj) : error LNK2019: unresolved external

 __imp_WideCharToMultiByte referenced in function "int __cdecl
 __crtLCMapStringA_stat(struct localeinfo_struct *,wchar_t

 long,char const *,int,char *,int,int,int)"
 

 LIBCMT.lib(a_loc.obj) : error LNK2001: unresolved external

 __imp_WideCharToMultiByte
 phobos64.lib(dmain2_4a7_1a5.obj) : error LNK2001: unresolved

 __imp_WideCharToMultiByte
 LIBCMT.lib(a_env.obj) : error LNK2001: unresolved external

 __imp_WideCharToMultiByte
 LIBCMT.lib(wctomb.obj) : error LNK2001: unresolved external

 __imp_WideCharToMultiByte
 LIBCMT.lib(write.obj) : error LNK2001: unresolved external

 __imp_WideCharToMultiByte
 phobos64.lib(dmain2_4a7_1a5.obj) : error LNK2019: unresolved

 IsDebuggerPresent referenced in function main
 phobos64.lib(dmain2_4a7_1a5.obj) : error LNK2019: unresolved

 LocalFree referenced in function main
 phobos64.lib(dmain2_4a7_1a5.obj) : error LNK2019: unresolved

 GetCommandLineW referenced in function main
 phobos64.lib(dmain2_4a7_1a5.obj) : error LNK2019: unresolved

 CommandLineToArgvW referenced in function main
 phobos64.lib(thread_1b9_21c.obj) : error LNK2001: unresolved

 __imp_InitializeCriticalSection
 phobos64.lib(mutex_335_213.obj) : error LNK2001: unresolved

 __imp_InitializeCriticalSection
 phobos64.lib(monitor__519_6fd.obj) : error LNK2019:

 __imp_InitializeCriticalSection referenced in function

 and ... ... ...


It worked fine for me at first! This is awesome! But is it possible to use VC linker for 32-bit architectures?
Oct 16 2012
prev sibling next sibling parent "Michael" <pr m1xa.com> writes:
On Tuesday, 16 October 2012 at 16:44:59 UTC, Walter Bright wrote:
 On 10/16/2012 8:58 AM, Gor Gyolchanyan wrote:
 It worked fine for me at first! This is awesome!

Great!

I tried a different lib paths, got same unresolved symbols. I have VC 10 & VC 11 Express editions. amd64 folder only in VC 11. Maybe it only work on Pro editions of VS?
Oct 16 2012
prev sibling next sibling parent "Gor Gyolchanyan" <gor.f.gyolchanyan gmail.com> writes:
On Tuesday, 16 October 2012 at 16:44:59 UTC, Walter Bright wrote:
 On 10/16/2012 8:58 AM, Gor Gyolchanyan wrote:
 It worked fine for me at first! This is awesome!

Great!
 But is it possible to use VC linker for 32-bit architectures?

No.

Is there a reason why it isn't possible? If you managed to delegate the linking to 64-bit VC linker, effectively producing 64-bit COFF binaries, then what would it take to do it for 32-bit too? This would end the COFF vs OMF problem once and for all...
Oct 17 2012
prev sibling next sibling parent "Michael" <pr m1xa.com> writes:
 Do a SET command and remove your LIB definitions. You've got to 
 get it to search the VC lib locations first.

Finally it works ;) on VC 11 Desktop Express, Win 2008 R2.
Oct 17 2012
prev sibling next sibling parent "Damian" <damianday hotmail.co.uk> writes:
On Wednesday, 17 October 2012 at 10:46:37 UTC, Gor Gyolchanyan 
wrote:
 On Tuesday, 16 October 2012 at 16:44:59 UTC, Walter Bright 
 wrote:
 On 10/16/2012 8:58 AM, Gor Gyolchanyan wrote:
 It worked fine for me at first! This is awesome!

Great!
 But is it possible to use VC linker for 32-bit architectures?

No.

Is there a reason why it isn't possible? If you managed to delegate the linking to 64-bit VC linker, effectively producing 64-bit COFF binaries, then what would it take to do it for 32-bit too? This would end the COFF vs OMF problem once and for all...

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.
Oct 17 2012
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Oct 17 2012
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Oct 19 2012
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Oct 19 2012
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
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.
Oct 20 2012
prev sibling parent Benjamin Thaut <code benjamin-thaut.de> writes:
Am 20.10.2012 18:40, schrieb Jesse Phillips:
 On Saturday, 20 October 2012 at 16:26:43 UTC, Jesse Phillips wrote:
 Thanks for the reply.

So I didn't get through all the remarks of that page: "This function is implemented using a compiler intrinsic where possible. For more information, see the WinBase.h header file and _InterlockedIncrement." But that doesn't say it always is. Oh well, now I know some of the Win32 API only exists in the compiler.

What about core.atomic.atomicOp!"+=" ? Kind Regards Benjamin Thaut
Oct 20 2012
prev sibling next sibling parent "Jesse Phillips" <jessekphillips+D gmail.com> writes:
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!
Oct 19 2012
prev sibling next sibling parent "Jesse Phillips" <jessekphillips+D gmail.com> writes:
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

 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.
Oct 20 2012
prev sibling next sibling parent "Jesse Phillips" <jessekphillips+D gmail.com> writes:
On Saturday, 20 October 2012 at 16:26:43 UTC, Jesse Phillips 
wrote:
 Thanks for the reply.

So I didn't get through all the remarks of that page: "This function is implemented using a compiler intrinsic where possible. For more information, see the WinBase.h header file and _InterlockedIncrement." But that doesn't say it always is. Oh well, now I know some of the Win32 API only exists in the compiler.
Oct 20 2012
prev sibling parent "Jesse Phillips" <jessekphillips+D gmail.com> writes:
On Saturday, 20 October 2012 at 16:56:19 UTC, Benjamin Thaut 
wrote:

 What about core.atomic.atomicOp!"+=" ?

 Kind Regards
 Benjamin Thaut

That is probably a perfect substitute. And now the program is linking... it crashes when run, but it gets through the initial steps. (I expect I have failed to make all needed 64bit changes) Thanks.
Oct 21 2012
prev sibling next sibling parent "Gor Gyolchanyan" <gor.f.gyolchanyan gmail.com> writes:
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...
Oct 18 2012
prev sibling parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig outerproduct.org> writes:
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.
Oct 20 2012
parent =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig outerproduct.org> writes:
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])
Oct 20 2012