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

Walter Bright (3/3) Oct 14 2012 http://ftp.digitalmars.com/dmd1beta.zip

Benjamin Thaut (4/7) Oct 14 2012 Nice, did any of the known issues get fixed or is the list still the sam...
bearophile (5/7) Oct 14 2012 The changelog section is not in good state, it misses parts and
Andrej Mitrovic (5/6) Oct 14 2012 But this is without Phobos support?

Walter Bright (2/4) Oct 14 2012 Fixed.

Andrej Mitrovic (3/7) Oct 14 2012 Ok so we're only supposed to compile with -c when using -m64? I don't

Walter Bright (12/14) Oct 14 2012 It does automatically invoke the VC linker.

Rainer Schuetze (11/27) Oct 15 2012 I guess there should be different environments for each architecture

Michael (23/26) Oct 15 2012 On Win 2008 R2:

Michael (1/1) Oct 15 2012 But in 32 mode with same sc.ini works fine.
Walter Bright (2/4) Oct 15 2012 Fixed.

Michael (48/52) Oct 15 2012 dmd -m64 t64.d

Walter Bright (4/51) Oct 15 2012 You should be linking with the VC libraries, not the 32 bit dmc ones. Tr...

Gor Gyolchanyan (3/82) Oct 16 2012 It worked fine for me at first! This is awesome!

Walter Bright (3/5) Oct 16 2012 No.

Michael (4/7) Oct 16 2012 I tried a different lib paths, got same unresolved symbols.

Walter Bright (3/12) Oct 16 2012 Do a SET command and remove your LIB definitions. You've got to get it t...

Michael (1/3) Oct 17 2012 Finally it works ;) on VC 11 Desktop Express, Win 2008 R2.

Gor Gyolchanyan (6/11) Oct 17 2012 Is there a reason why it isn't possible?

Damian (7/22) Oct 17 2012 Although that would be great, it also means everybody who wants

Jacob Carlborg (4/7) Oct 17 2012 No point in removing the already working OMF backend. Let the user choos...

Gor Gyolchanyan (4/13) Oct 18 2012 That's what I suggested. keep the existing OMF, but add option to

Walter Bright (2/4) Oct 17 2012 Updated so now stack walking works in the VS debugger.

Walter Bright (2/6) Oct 19 2012 New update implementing most of the std.math math functions.

Jesse Phillips (23/30) Oct 19 2012 To document my experience/setup

Walter Bright (3/5) Oct 19 2012 InterlockedIncrement is a VC compiler intrinsic, which is why it isn't i...

Walter Bright (4/9) Oct 20 2012 Probably the best way to deal with this at the moment is to write a .c f...
Jesse Phillips (16/22) Oct 20 2012 As per accidental email reply:

Jesse Phillips (8/9) Oct 20 2012 So I didn't get through all the remarks of that page:

Benjamin Thaut (4/12) Oct 20 2012 What about core.atomic.atomicOp!"+=" ?

Jesse Phillips (6/9) Oct 21 2012 That is probably a perfect substitute. And now the program is

=?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= (8/12) Oct 20 2012 I get a problem, that is not really 64-bit related, but currently keeps

=?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= (10/26) Oct 20 2012 It's a bit more complicated and opAssign/foreach related:

Moritz Maxeiner (20/20) Dec 11 2012 To get this working with Visual Studio 2012 on Windows 8 one can

Jesse Phillips (7/12) Dec 11 2012 I think it was another thread that he said this would only be

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

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

"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

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

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

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

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

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

"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

"Michael" <pr m1xa.com> writes:

But in 32 mode with same sc.ini works fine.

Oct 15 2012

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

"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

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

"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

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


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

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

"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

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

"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

"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

"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

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

"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

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

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

"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

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

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

"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

 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.

Oct 20 2012

"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

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

"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

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

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

"Moritz Maxeiner" <moritz ucworks.org> writes:

To get this working with Visual Studio 2012 on Windows 8 one can 
use this (or a similar) sc.ini (Then it works perfectly fine, 
thank you Walter!):

[Version]
version=7.51 Build 020

[Environment]
LIB=C:\Program Files (x86)\Windows 
Kits\8.0\Lib\win8\um\x64;"% P%\..\lib";\dm\lib
DFLAGS="-I% P%\..\..\src\phobos" 
"-I% P%\..\..\src\druntime\import"
VCINSTALLDIR=C:\Program Files (x86)\Microsoft Visual Studio 
11.0\VC\
WindowsSdkDir=C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\
LINKCMD=c:\dm\bin\link.exe
LINKCMD64=%VCINSTALLDIR%bin\amd64\link.exe


One more thing: It's been asked before in this thread, but I 
haven't seen a reply by Walter yet: Is it viable to add the 
option of using the VC linker for 32bit, e.g. as something like 
"-linkvc". And I don't mean to remove optlink or anything like 
that, just as an option.

Dec 11 2012

"Jesse Phillips" <Jessekphillips+D gmail.com> writes:

On Tuesday, 11 December 2012 at 15:28:08 UTC, Moritz Maxeiner 
wrote:

 One more thing: It's been asked before in this thread, but I 
 haven't seen a reply by Walter yet: Is it viable to add the 
 option of using the VC linker for 32bit, e.g. as something like 
 "-linkvc". And I don't mean to remove optlink or anything like 
 that, just as an option.

I think it was another thread that he said this would only be 
64bit. This could change in the future but I do not believe it is 
planned at this point.

(It isn't a matter of just adding a switch, thus more work which 
he isn't planning yet)

Dec 11 2012

D Programming

C/C++ Programming

Other

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