www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - 64-bit DMD for windows?

reply dmd.20.browseruk xoxy.net writes:
Hi,

Is there a 64-bit version of DMD for windows?

The download page offers only an x86 version. Or am I reading too much  
into that?

Cheers, buk
Dec 14 2011
next sibling parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Wednesday, 14 December 2011 at 18:20:04 UTC, 
dmd.20.browseruk xoxy.net wrote:
 Hi,

 Is there a 64-bit version of DMD for windows?

 The download page offers only an x86 version. Or am I reading 
 too much into that?

 Cheers, buk

Hi! DMD currently does not target 64-bit Windows. You may have some luck with GDC (there is a 64-bit build from July in Downloads): https://bitbucket.org/goshawk/gdc
Dec 14 2011
prev sibling next sibling parent reply torhu <no spam.invalid> writes:
On 14.12.2011 12:54, dmd.20.browseruk xoxy.net wrote:
 Hi,

 Is there a 64-bit version of DMD for windows?

 The download page offers only an x86 version. Or am I reading too much
 into that?

 Cheers, buk

There's not much you would need a 64-bit compiler for on Windows. What are you going to use it for?
Dec 15 2011
next sibling parent =?ISO-8859-15?Q?Alex_R=F8nne_Petersen?= <xtzgzorex gmail.com> writes:
On 15-12-2011 11:47, torhu wrote:
 On 14.12.2011 12:54, dmd.20.browseruk xoxy.net wrote:
 Hi,

 Is there a 64-bit version of DMD for windows?

 The download page offers only an x86 version. Or am I reading too much
 into that?

 Cheers, buk

There's not much you would need a 64-bit compiler for on Windows. What are you going to use it for?

Um, to build 64-bit programs? What else... - Alex
Dec 15 2011
prev sibling parent reply captaindet <2krnk gmx.net> writes:
On 2011-12-15 04:47, torhu wrote:
 On 14.12.2011 12:54, dmd.20.browseruk xoxy.net wrote:
 Hi,

 Is there a 64-bit version of DMD for windows?

 The download page offers only an x86 version. Or am I reading too
 much into that?

 Cheers, buk

There's not much you would need a 64-bit compiler for on Windows. What are you going to use it for?

now what is this for a strange comment? you need 64bit for windows for the same reasons than for any other platform: accessing loads of mem. yes, for some this is really important! for me it is actually a dealbreaker - i'd love to use D for my scientific programming, but my datasets often reach several GB... my computer has 16GB and i intend to make use of them. det
Dec 15 2011
next sibling parent reply Mehrdad <wfunction hotmail.com> writes:
On 12/15/2011 3:20 PM, Trass3r wrote:
 dealbreaker - i'd love to use D for my scientific programming, but my 
 datasets often reach several GB...

 my computer has 16GB and i intend to make use of them.

Scientific programming on Windoze? You can't be serious :P

lol, that's not even the only issue. 32-bit programs can't show 64-bit dialogs. So "Open this file..." actually shows the SysWOW64 folder instead of the System32 folder, and there's _no way_ to bypass this unless you build a 64-bit app.
Dec 15 2011
parent reply torhu <no spam.invalid> writes:
On 16.12.2011 00:35, Mehrdad wrote:
 On 12/15/2011 3:20 PM, Trass3r wrote:
  dealbreaker - i'd love to use D for my scientific programming, but my
  datasets often reach several GB...

  my computer has 16GB and i intend to make use of them.

Scientific programming on Windoze? You can't be serious :P

lol, that's not even the only issue. 32-bit programs can't show 64-bit dialogs. So "Open this file..." actually shows the SysWOW64 folder instead of the System32 folder, and there's _no way_ to bypass this unless you build a 64-bit app.

Most people are not actually doing scientific programming. And they don't actually need to open an open file dialog to access files that are in the "real" System32. But if they do, there are several easy solutions.[1] Another reason for needing a 64-bit program on Windows would be if you are creating a shell extension. TortoiseSVN comes in both 32-bit and 64-bit flavors for this reason. People coming from Linux are accustomed to a running only 64-bit programs if they have a 64-bit OS. That's simply because Linux is usually distributed through downloading. To limit the download size, they leave out the 32-bit versions of libraries. Which means you can't actually run 32-bit programs without downloading and installing the packages containing those libraries first. At least that's my understanding. This issue doesn't exist on Windows. Probably not on OS X either, but I'm not too familiar with that system. So when people ask for 64-bit versions without stating why they need it, I always have to ask what features they want that the 32-bit version doesn't have. [1] http://www.ghisler.ch/wiki/index.php/Some_Files_and_Folders_Shown_by_Windows_Explorer_Are_Not_Shown_by_Total_Commander!#Solutions
Dec 16 2011
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2011-12-16 10:10, torhu wrote:
 On 16.12.2011 00:35, Mehrdad wrote:
 On 12/15/2011 3:20 PM, Trass3r wrote:
 dealbreaker - i'd love to use D for my scientific programming, but my
 datasets often reach several GB...

 my computer has 16GB and i intend to make use of them.

Scientific programming on Windoze? You can't be serious :P

lol, that's not even the only issue. 32-bit programs can't show 64-bit dialogs. So "Open this file..." actually shows the SysWOW64 folder instead of the System32 folder, and there's _no way_ to bypass this unless you build a 64-bit app.

Most people are not actually doing scientific programming. And they don't actually need to open an open file dialog to access files that are in the "real" System32. But if they do, there are several easy solutions.[1] Another reason for needing a 64-bit program on Windows would be if you are creating a shell extension. TortoiseSVN comes in both 32-bit and 64-bit flavors for this reason. People coming from Linux are accustomed to a running only 64-bit programs if they have a 64-bit OS. That's simply because Linux is usually distributed through downloading. To limit the download size, they leave out the 32-bit versions of libraries. Which means you can't actually run 32-bit programs without downloading and installing the packages containing those libraries first. At least that's my understanding. This issue doesn't exist on Windows. Probably not on OS X either, but I'm not too familiar with that system.

Mac OS X has universal binaries, that is, libraries and executables containing code for multiple architectures. All system libraries bundled with the OS are compiled (at least) both for 32 and 64bit. This makes it no problem running either 32 or 64bit applications, the user don't have to know or care. -- /Jacob Carlborg
Dec 16 2011
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/16/2011 1:17 AM, Jacob Carlborg wrote:
 On 2011-12-16 10:10, torhu wrote:
 People coming from Linux are accustomed to a running only 64-bit
 programs if they have a 64-bit OS. That's simply because Linux is
 usually distributed through downloading. To limit the download size,
 they leave out the 32-bit versions of libraries. Which means you can't
 actually run 32-bit programs without downloading and installing the
 packages containing those libraries first. At least that's my
 understanding.

 This issue doesn't exist on Windows. Probably not on OS X either, but
 I'm not too familiar with that system.

Mac OS X has universal binaries, that is, libraries and executables containing code for multiple architectures. All system libraries bundled with the OS are compiled (at least) both for 32 and 64bit. This makes it no problem running either 32 or 64bit applications, the user don't have to know or care.

The Mac "universal" binaries are simply the 32 bit and 64 bit versions concatenated into one file. It doesn't save on download size.
Dec 16 2011
parent Jacob Carlborg <doob me.com> writes:
On 2011-12-16 10:24, Walter Bright wrote:
 On 12/16/2011 1:17 AM, Jacob Carlborg wrote:
 On 2011-12-16 10:10, torhu wrote:
 People coming from Linux are accustomed to a running only 64-bit
 programs if they have a 64-bit OS. That's simply because Linux is
 usually distributed through downloading. To limit the download size,
 they leave out the 32-bit versions of libraries. Which means you can't
 actually run 32-bit programs without downloading and installing the
 packages containing those libraries first. At least that's my
 understanding.

 This issue doesn't exist on Windows. Probably not on OS X either, but
 I'm not too familiar with that system.

Mac OS X has universal binaries, that is, libraries and executables containing code for multiple architectures. All system libraries bundled with the OS are compiled (at least) both for 32 and 64bit. This makes it no problem running either 32 or 64bit applications, the user don't have to know or care.

The Mac "universal" binaries are simply the 32 bit and 64 bit versions concatenated into one file. It doesn't save on download size.

Exactly, I didn't say anything else. -- /Jacob Carlborg
Dec 16 2011
prev sibling parent torhu <no spam.invalid> writes:
On 16.12.2011 10:17, Jacob Carlborg wrote:
 On 2011-12-16 10:10, torhu wrote:
  On 16.12.2011 00:35, Mehrdad wrote:
  On 12/15/2011 3:20 PM, Trass3r wrote:
  dealbreaker - i'd love to use D for my scientific programming, but my
  datasets often reach several GB...

  my computer has 16GB and i intend to make use of them.

Scientific programming on Windoze? You can't be serious :P

lol, that's not even the only issue. 32-bit programs can't show 64-bit dialogs. So "Open this file..." actually shows the SysWOW64 folder instead of the System32 folder, and there's _no way_ to bypass this unless you build a 64-bit app.

Most people are not actually doing scientific programming. And they don't actually need to open an open file dialog to access files that are in the "real" System32. But if they do, there are several easy solutions.[1] Another reason for needing a 64-bit program on Windows would be if you are creating a shell extension. TortoiseSVN comes in both 32-bit and 64-bit flavors for this reason. People coming from Linux are accustomed to a running only 64-bit programs if they have a 64-bit OS. That's simply because Linux is usually distributed through downloading. To limit the download size, they leave out the 32-bit versions of libraries. Which means you can't actually run 32-bit programs without downloading and installing the packages containing those libraries first. At least that's my understanding. This issue doesn't exist on Windows. Probably not on OS X either, but I'm not too familiar with that system.

Mac OS X has universal binaries, that is, libraries and executables containing code for multiple architectures. All system libraries bundled with the OS are compiled (at least) both for 32 and 64bit. This makes it no problem running either 32 or 64bit applications, the user don't have to know or care.

I know that much, but I wasn't sure why they were so keen on having 64 bit versions of apps. Maybe just to accelerate the switch to 64-bits by making it easier for developers to support both. And now they have started to leave things like Carbon behind in 32-bit land. At least you can't say that Apple isn't moving forward.
Dec 16 2011
prev sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Jonathan M Davis" <jmdavisProg gmx.com> wrote in message 
news:mailman.1595.1324029407.24802.digitalmars-d puremagic.com...
 And considering that there are no x86 chips sold these days which aren't
 x86_64, I find it rather baffling that Microsoft even sells a 32-bit 
 version of
 Windows.

(Chips sold) != (Chips in use) Why would MS want to give a big F.U. to someone who wants to give MS money but isn't buying new hardware? Wouldn't make any sense.
Dec 16 2011
parent reply "Nick Sabalausky" <a a.a> writes:
"Nick Sabalausky" <a a.a> wrote in message 
news:jcg0q8$145v$1 digitalmars.com...
 "Jonathan M Davis" <jmdavisProg gmx.com> wrote in message 
 news:mailman.1595.1324029407.24802.digitalmars-d puremagic.com...
 And considering that there are no x86 chips sold these days which aren't
 x86_64, I find it rather baffling that Microsoft even sells a 32-bit 
 version of
 Windows.

(Chips sold) != (Chips in use) Why would MS want to give a big F.U. to someone who wants to give MS money but isn't buying new hardware? Wouldn't make any sense.

Also, the 64-bit versions can't run 16-bit software, and yes, I know that's getting *really*, *really* old, but I wouldn't be surprised if there are people out there (companies, especially) that are still relying on something 16-bit. (In case anyone's wondering, and I'm sure some people are ;) : No, I'm not personally using Windows's 16-bit compatability for anything.)
Dec 16 2011
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/16/2011 9:59 AM, Nick Sabalausky wrote:
 Also, the 64-bit versions can't run 16-bit software, and yes, I know that's
 getting *really*, *really* old, but I wouldn't be surprised if there are
 people out there (companies, especially) that are still relying on something
 16-bit. (In case anyone's wondering, and I'm sure some people are ;) : No,
 I'm not personally using Windows's 16-bit compatability for anything.)

I still have some customers using DMC for 16 bit work, and I still run DMC through all those tests.
Dec 16 2011
parent "Nick Sabalausky" <a a.a> writes:
"Walter Bright" <newshound2 digitalmars.com> wrote in message 
news:jcg1k1$15kk$2 digitalmars.com...
 On 12/16/2011 9:59 AM, Nick Sabalausky wrote:
 Also, the 64-bit versions can't run 16-bit software, and yes, I know 
 that's
 getting *really*, *really* old, but I wouldn't be surprised if there are
 people out there (companies, especially) that are still relying on 
 something
 16-bit. (In case anyone's wondering, and I'm sure some people are ;) : 
 No,
 I'm not personally using Windows's 16-bit compatability for anything.)

I still have some customers using DMC for 16 bit work, and I still run DMC through all those tests.

See, everyone! There's people (plural, apparently!) even more anachronistic than me! ;)
Dec 16 2011
prev sibling parent reply torhu <no spam.invalid> writes:
On 17.12.2011 04:26, Trass3r wrote:
  My girlfriend is interviewing for a job at a major government company
  here in Norway, and was told that she'd need to use DOS at work. Likely
  some ancient software that no-one's ever wanted to try and upgrade.

What is wrong with this world? ;)

DOS software can be more productive, since it's often keyboard-only. It all depends, of course. Might be a FoxPro app or something.
Dec 17 2011
parent reply torhu <no spam.invalid> writes:
On 17.12.2011 16:37, Trass3r wrote:
  DOS software can be more productive, since it's often keyboard-only.

How is that different from a Windows console app?

From an interface point of view, it's basically the same thing. They both support character graphics (like ncurses). Internally, they wouldn't have anything in common at all.
Dec 17 2011
parent torhu <no spam.invalid> writes:
On 17.12.2011 17:59, torhu wrote:
 On 17.12.2011 16:37, Trass3r wrote:
   DOS software can be more productive, since it's often keyboard-only.

How is that different from a Windows console app?

From an interface point of view, it's basically the same thing. They both support character graphics (like ncurses). Internally, they wouldn't have anything in common at all.

The only commercial application I can think of that runs in the Windows console and uses character graphics is Far Manager. 20 years there were lots of applications like that, but they ran on top of DOS instead of Windows.
Dec 17 2011
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/18/11 5:11 PM, dmd.20.browseruk xoxy.net wrote:
 On Thu, 15 Dec 2011 23:20:50 -0000, Trass3r - un known.com
 <+dmd+browseruk+31526d5b7d.un#known.com spamgourmet.com> wrote:

 It's a shame that

 a) you guys apparently cannot imagine a use for a 64-bit D on Windows.

I don't think that argument has been seriously aired. Our trouble with Win64 generation is purely technological. Our toolchain would need major rework to approach that.
 b) the interfaces to this newsgroup are virtually impossible to use.

The NNTP interface works as well as NNTP itself works, so I think it the generalization is unfair. Most people including myself agree that the current web bridge sucks, and Vladimir Panteleev actually did something about it: http://dfeed.kimsufi.thecybershadow.net/discussion/group/digitalmars.D. We plan to integrate that after the holiday season.
 c) The only response from Mr Bright on the subject is "people are still
 using 16-bit".

That was but a side discussion. The situation is rather well known - accommodating Win64's object file format would be difficult.
 I've been following along with for must be close to 5 years now, waiting
 for it to mature into a usable, production quality product.
 I see I am once again too early.

Unfortunately I wouldn't be able to say Win64 generation will be done soon, or when it will be done. But this is not an issue of attitude of carelessness. Thanks, Andrei
Dec 18 2011
prev sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 5/12/2014 2:04 PM, steven kladitis wrote:
 On Monday, 12 May 2014 at 17:46:21 UTC, Kapps wrote:
 On Monday, 12 May 2014 at 16:47:21 UTC, steven kladitis wrote:
 It is NOT just for memory addressing , wchi is very simple under 64
 bit, but also 64 bit registers, 16 of them , not just 8 32 bit.  I
 think there should be a 64 bit version.

This topic is 3 years old, DMD can already generate 64-bit programs on Windows (although I don't think DMD itself is 64-bit).

I still only see 32 bit version for Windows. I admit I have a 32 bit laptop , over 10 years old :) . All other laptops and pcs I have are 64 bit processors. If anyone out there has a 64 bit; version 2.065 , for windows let me know.

You don't need a 64-bit version: Compiling 64-bit programs doesn't require a 64-bit compiler. Just install VC++, use the DMD 2.065 Win installer, and then toss in the -m64 flag when compiling. Works fine. Doesn't matter if DMD itself is 32-bit.
May 12 2014
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 5/12/2014 5:01 PM, Andrej Mitrovic via Digitalmars-d wrote:
 On 5/12/14, Nick Sabalausky via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:
 You don't need a 64-bit version: Compiling 64-bit programs doesn't
 require a 64-bit compiler. Just install VC++, use the DMD 2.065 Win
 installer, and then toss in the -m64 flag when compiling. Works fine.
 Doesn't matter if DMD itself is 32-bit.

As Vladimir in IRC reminded me, there is one use-case: You may need it for some intensive CTFE stuff (excessive memory allocations and no freeing by the compiler). That is, if you need more than 3/4 gigs.

Right, there's certainly that. But that has nothing to do with whether you're trying to build a 64-bit or 32-bit program, and (at least for Windows) it isn't even an issue at all unless you actually are hitting that limit (unlikely for a newcomer to D). It sounded like steven kladitis was worried about just being able to create 64-bit programs. For that, it makes no difference if the compiler itself is a 32- or 64-bit build.
May 12 2014
next sibling parent "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Manu via Digitalmars-d"  wrote in message 
news:mailman.678.1399989216.2907.digitalmars-d puremagic.com...

 Pointers are 64bits.
 int is 32 bits, long is 64 bits.
 size_t is 64 bits.

long is 32 bits.
May 13 2014
prev sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 5/14/2014 2:28 PM, steven kladitis wrote:
 On Tuesday, 13 May 2014 at 13:53:36 UTC, Manu via Digitalmars-d wrote:
 On 13 May 2014 23:24, steven kladitis via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:
 if the -m64 lets the compiled code use 64 bit registers and ints are
 now 64
 bit then great! What is VC++, is it free?

Pointers are 64bits. int is 32 bits, long is 64 bits. size_t is 64 bits. VC++ is Microsoft's compiler, DMD-x64 uses the de-facto standard Microsoft linker, since OPTLINK doesn't support 64bit. It is available for free.

I have installed it and am still unable to compile a 64 bit D program. C:\d\dmd2\samples\d>dmd wc.d C:\d\dmd2\samples\d>dmd -m64 wc.d --- errorlevel -1073741515

If you use the Windows Installer for DMD after you've installed VC++, then it should automatically set everything up for you (I haven't tried it personally, but I know the DMD Win Installer people went to a lot of effort to make it work, so it should work). Oh, I forgot to mention, you'll also need to install the Microsoft's Windows SDK (not sure if that's automatically done when installing VC++ or not.) So after VC++ and the WinSDK are installed, then run DMD's Windows installer, and you should be good. Or you can manually setup DMD's sc.ini with the right paths to VC++ and the WinSDK (that's what I did), but it's probably easier to just run the DMD Windows Installer again after all the MS stuff is installed.
May 14 2014
next sibling parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 21.05.2014 14:17, Brad Anderson wrote:
 On Wednesday, 21 May 2014 at 03:15:34 UTC, Manu via Digitalmars-d
 wrote:
 On 21 May 2014 05:15, Temtaime via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:
 Sorry i misunderstood you.
 Yes dmd supports x64 on windows but it doesn't work without external
 tools.
 It's a main trouble i think.

MSVC is the de facto standard toolset for Windows. How do you interoperate with any other conventional windows libraries if DMD is not MSVC compatible? This is the key development of DMD for Win64, and it's the only reason D is practically useful on Windows at all. I pine for the day that 32bit will get the same treatment.

I believe Rainer did some work on extending COFF support to 32-bit. I'm not sure how far along he got.

I recently considered making a pull request, but noticed an include dependency that failed to work for another PR, and got distracted. The updated compiler patches are here: https://github.com/rainers/dmd/tree/coff32
May 21 2014
next sibling parent Rainer Schuetze <r.sagitario gmx.de> writes:
On 22.05.2014 09:04, Manu via Digitalmars-d wrote:
 On 22 May 2014 16:28, Joakim via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:
 On Thursday, 22 May 2014 at 06:16:54 UTC, Rainer Schuetze wrote:
 I recently considered making a pull request, but noticed an include
 dependency that failed to work for another PR, and got distracted. The
 updated compiler patches are here:
 https://github.com/rainers/dmd/tree/coff32

I think this is a really important pull for win32 support, still the most widely used platform on which D is available. Not everybody has the source for outside libraries or the time and inclination to recompile it to OMF using the Digital Mars toolchain. I think it would really help D to get this pull in soon.

Yeah, it's a gigantic hole, and your work looks like it's almost there. Do you have any idea about the x64 SSE support and supporting that on x86 as well? Difficult? Practical?

I don't know, will have to look into that. I always wondered why it isn't supported by x86 to start with.
May 22 2014
prev sibling parent Rainer Schuetze <r.sagitario gmx.de> writes:
On 22.05.2014 09:45, Kagamin wrote:
 On Thursday, 22 May 2014 at 06:28:14 UTC, Joakim wrote:
 On Thursday, 22 May 2014 at 06:16:54 UTC, Rainer Schuetze wrote:
 I recently considered making a pull request, but noticed an include
 dependency that failed to work for another PR, and got distracted.
 The updated compiler patches are here:
 https://github.com/rainers/dmd/tree/coff32

most widely used platform on which D is available. Not everybody has the source for outside libraries or the time and inclination to recompile it to OMF using the Digital Mars toolchain. I think it would really help D to get this pull in soon.

How would it work? Will it link D code with snn, msvcrt or both?

It is supposed to link against MSVCRT. The druntime/phobos patches are here, though I'm expecting some discussions about used version identifiers: https://github.com/rainers/druntime/tree/coff32 https://github.com/rainers/phobos/tree/coff32
May 22 2014
prev sibling parent Bruno Medeiros <bruno.do.medeiros+dng gmail.com> writes:
On 21/05/2014 05:34, Manu via Digitalmars-d wrote:
 On 21 May 2014 13:45, Temtaime via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:
 Yes, DMD uses ld on linux. It's OK because there is no other
 linker. And it's system's default. Everybody(almost) have GCC.

 But on windows.. MSVS is external IDE and toolset. Some people
 yes they uses MinGW.
 Why ? MSVS has some disadvantages for me for example it's poor
 C++11 support. So it's useless in my work.

 So for compile 64 app with DMD one must download dmd(~20 MB) and
 install MSVS(~2 GB).
 I think dmd should work out of the box isn't it ?

It's still the standard on the platform. Interoperation with other libraries/code typically demands MSVC compatibility. I don't know how any large-scale Windows developers can avoid this practical reality? On the plus side, there is a recent push to get Clang/LLVM properly compatible with MSVC. When that happens, we should be able to rely on Clang+LDC for all windows needs.
 And what about other compilers ?
 Latest LDC for example uses 064 frontend.

 It's outdated for me because of bugs. I cannot ever compile my
 app now with it.
 With GDC it's alto difficult to get luck.

Poke the GDC/LDC guys? It would certainly be nice if those toolchains were more reliably up-to-date, but the sad truth is, those who use MinGW on windows are in the severe minority, so there's probably not so much motivation.

LDC on MingW doesn't seem to support debugging at all, and that's because of a LLVM issue, not LDC, so it doesn't matter how much LDC is up to date or not. According to Kai, "LLVM on MinGW is not very well tested." I had better hopes for GDC, and did poke the GDC guys (even put a bounty up - not that I think that amount of money would make any significant difference - it was more to show I really cared about this issue). But it seems GDC on Windows is not properly supported either (news://news.digitalmars.com:119/lkdnrr$j43$1 digitalmars.com). It's not just an issue of build scripts and compiling binary releases, as I initially thought. Like you said, those like me, who use MinGW on Windows seem to be a severe minority. Having Clang/LLVM support MSVC toolchain would be great. And it would be *magnificent* if that included LLDB support! The reason I prefer MinGW on Windows is so that I can use a half-decent, open-source debugger. -- Bruno Medeiros https://twitter.com/brunodomedeiros
May 22 2014
prev sibling next sibling parent "F i L" <witte2008 gmail.com> writes:
On Thursday, 15 December 2011 at 21:05:05 UTC, captaindet wrote:
 On 2011-12-15 04:47, torhu wrote:
 On 14.12.2011 12:54, dmd.20.browseruk xoxy.net wrote:
 Hi,

 Is there a 64-bit version of DMD for windows?

 The download page offers only an x86 version. Or am I reading 
 too
 much into that?

 Cheers, buk

There's not much you would need a 64-bit compiler for on Windows. What are you going to use it for?

now what is this for a strange comment? you need 64bit for windows for the same reasons than for any other platform: accessing loads of mem. yes, for some this is really important! for me it is actually a dealbreaker - i'd love to use D for my scientific programming, but my datasets often reach several GB... my computer has 16GB and i intend to make use of them. det

Use Linux.. it's better for your health ;p jk, I'm eagerly awaiting a Win64 DMD as well.
Dec 15 2011
prev sibling next sibling parent Trass3r <un known.com> writes:
 dealbreaker - i'd love to use D for my scientific programming, but my  
 datasets often reach several GB...

 my computer has 16GB and i intend to make use of them.

Scientific programming on Windoze? You can't be serious :P
Dec 15 2011
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday, December 16, 2011 10:10:57 torhu wrote:
 On 16.12.2011 00:35, Mehrdad wrote:
 On 12/15/2011 3:20 PM, Trass3r wrote:
  dealbreaker - i'd love to use D for my scientific programming, but
  my
  datasets often reach several GB...
  
  my computer has 16GB and i intend to make use of them.

Scientific programming on Windoze? You can't be serious :P

lol, that's not even the only issue. 32-bit programs can't show 64-bit dialogs. So "Open this file..." actually shows the SysWOW64 folder instead of the System32 folder, and there's _no way_ to bypass this unless you build a 64-bit app.

Most people are not actually doing scientific programming. And they don't actually need to open an open file dialog to access files that are in the "real" System32. But if they do, there are several easy solutions.[1] Another reason for needing a 64-bit program on Windows would be if you are creating a shell extension. TortoiseSVN comes in both 32-bit and 64-bit flavors for this reason. People coming from Linux are accustomed to a running only 64-bit programs if they have a 64-bit OS. That's simply because Linux is usually distributed through downloading. To limit the download size, they leave out the 32-bit versions of libraries. Which means you can't actually run 32-bit programs without downloading and installing the packages containing those libraries first. At least that's my understanding.

On Linux, there's frequently no point in having 32-bit libraries installed. Everything is built for the native architecture, so why bother having the 32- bit libraries if they're not needed? There are the occasional exception - such as if you want to run wine in 32-bit mode, but even that can be in 64-bit now (though the risk of it not being appropriately compatible with Windows programs is greater in 64-bit, since it's newer). I would fully expect Windows to run 32-bit programs, but I would also think that 64-bit programs would become the norm such that there would eventually be no reason to have 32-bit programs aside from legacy stuff which isn't rebuilt. And considering that there are no x86 chips sold these days which aren't x86_64, I find it rather baffling that Microsoft even sells a 32-bit version of Windows. As long as the 64-bit versions runs the 32-bit programs properly, I don't see any point in having a 32-bit version of the OS - especially computers increasingly have too much memory to be able to use it all with a 32-bit OS. - Jonathan M Davis
Dec 16 2011
prev sibling next sibling parent reply "Jakob Ovrum" <jakobovrum gmail.com> writes:
On Friday, 16 December 2011 at 09:56:47 UTC, Jonathan M Davis 
wrote:
 considering that there are no x86 chips sold these days which 
 aren't x86_64, I find it rather baffling that Microsoft even 
 sells a 32-bit version of Windows.

This is simply not true. I don't know about processors sold separately, but many netbooks and laptops still come with 32 bit processors.
Dec 16 2011
parent a <a a.com> writes:
Jakob Ovrum Wrote:

 On Friday, 16 December 2011 at 09:56:47 UTC, Jonathan M Davis 
 wrote:
 considering that there are no x86 chips sold these days which 
 aren't x86_64, I find it rather baffling that Microsoft even 
 sells a 32-bit version of Windows.

This is simply not true. I don't know about processors sold separately, but many netbooks and laptops still come with 32 bit processors.

New laptops and netbooks don't. Even recent (less than two years old) versions of intel atom are x86_64.
Dec 16 2011
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday, December 16, 2011 11:09:25 Jakob Ovrum wrote:
 On Friday, 16 December 2011 at 09:56:47 UTC, Jonathan M Davis
 
 wrote:
 considering that there are no x86 chips sold these days which
 aren't x86_64, I find it rather baffling that Microsoft even
 sells a 32-bit version of Windows.

This is simply not true. I don't know about processors sold separately, but many netbooks and laptops still come with 32 bit processors.

Hmm. That's the first I've heard of 32-bit x86 processors in ages. All of the ones that I've seen or heard about for quite a while have been x86_64, even if they're running 32-bit Windows. The only 32-bit processors that I've heard about are ARM processors. I guess that I don't pay enough attention to that sort of stuff. - Jonathan M Davis
Dec 16 2011
prev sibling next sibling parent Andrea Fontana <advmail katamail.com> writes:
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Some intel atoms still use 32-bit architecture.

Il giorno ven, 16/12/2011 alle 02.48 -0800, Jonathan M Davis ha scritto:

 On Friday, December 16, 2011 11:09:25 Jakob Ovrum wrote:
 On Friday, 16 December 2011 at 09:56:47 UTC, Jonathan M Davis
=20
 wrote:
 considering that there are no x86 chips sold these days which
 aren't x86_64, I find it rather baffling that Microsoft even
 sells a 32-bit version of Windows.

This is simply not true. I don't know about processors sold separately, but many netbooks and laptops still come with 32 bit processors.

Hmm. That's the first I've heard of 32-bit x86 processors in ages. All of=

 ones that I've seen or heard about for quite a while have been x86_64, ev=

 they're running 32-bit Windows. The only 32-bit processors that I've hear=

 about are ARM processors. I guess that I don't pay enough attention to th=

 sort of stuff.
=20
 - Jonathan M Davis

Dec 16 2011
prev sibling next sibling parent "Jakob Ovrum" <jakobovrum gmail.com> writes:
On Friday, 16 December 2011 at 12:14:50 UTC, a wrote:
 Jakob Ovrum Wrote:

 On Friday, 16 December 2011 at 09:56:47 UTC, Jonathan M Davis 
 wrote:
 considering that there are no x86 chips sold these days 
 which aren't x86_64, I find it rather baffling that 
 Microsoft even sells a 32-bit version of Windows.

This is simply not true. I don't know about processors sold separately, but many netbooks and laptops still come with 32 bit processors.

New laptops and netbooks don't. Even recent (less than two years old) versions of intel atom are x86_64.

The keyword here is "sold", and besides, IA32 is still extremely common on cheap netbooks and laptops, even some recent models. The Atom line having 64 bit models doesn't mean a whole lot for the present reality. 32-bit x86 is definitely disappearing, but there is a long road ahead and 32 bit x86 is still ubiquitous. And I bet if you counted all the offices using Windows around the world, you'd find the vast majority of them using 32-bit hardware. There's no reason Microsoft shouldn't offer upgrade opportunities for that userbase as long as their new OS' work fine on old hardware.
Dec 16 2011
prev sibling next sibling parent Andrea Fontana <advmail katamail.com> writes:
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Il giorno ven, 16/12/2011 alle 07.14 -0500, a ha scritto:

 Jakob Ovrum Wrote:
=20
 On Friday, 16 December 2011 at 09:56:47 UTC, Jonathan M Davis=20
 wrote:
 considering that there are no x86 chips sold these days which=20
 aren't x86_64, I find it rather baffling that Microsoft even=20
 sells a 32-bit version of Windows.

This is simply not true. I don't know about processors sold=20 separately, but many netbooks and laptops still come with 32 bit=20 processors.

New laptops and netbooks don't. Even recent (less than two years old)=20 versions of intel atom are x86_64.

It says "instruction set" 32 bit. Released on Q2 2011...=20 http://ark.intel.com/products/55663/
Dec 16 2011
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Friday, 16 December 2011 at 18:01:21 UTC, Nick Sabalausky 
wrote:
 No, I'm not personally using Windows's 16-bit compatability for 
 anything.)

One of the reasons I like Digital Mars is the compiler still targets 16 bit. (That was hugely important as a newb, and I don't use it much anymore, but it's very nice to have when I still want it.) When I tried college round two, assembly language class did 16 bit DOS programs too, running on Windows, of course. This was... I think 2007.
Dec 16 2011
prev sibling next sibling parent "Robert Jacques" <sandford jhu.edu> writes:
On Thu, 15 Dec 2011 05:47:54 -0500, torhu <no spam.invalid> wrote:

 On 14.12.2011 12:54, dmd.20.browseruk xoxy.net wrote:
 Hi,

 Is there a 64-bit version of DMD for windows?

 The download page offers only an x86 version. Or am I reading too much
 into that?

 Cheers, buk

There's not much you would need a 64-bit compiler for on Windows. What are you going to use it for?

Linking to 64-bit programs. Also, I work on GPGPU medical imaging problems and I have run my 3GB Tesla card out of ram on occasion.
Dec 16 2011
prev sibling next sibling parent =?utf-8?Q?Simen_Kj=C3=A6r=C3=A5s?= <simen.kjaras gmail.com> writes:
On Fri, 16 Dec 2011 18:59:43 +0100, Nick Sabalausky <a a.a> wrote:

 "Nick Sabalausky" <a a.a> wrote in message
 news:jcg0q8$145v$1 digitalmars.com...
 "Jonathan M Davis" <jmdavisProg gmx.com> wrote in message
 news:mailman.1595.1324029407.24802.digitalmars-d puremagic.com...
 And considering that there are no x86 chips sold these days which  
 aren't
 x86_64, I find it rather baffling that Microsoft even sells a 32-bit
 version of
 Windows.

(Chips sold) != (Chips in use) Why would MS want to give a big F.U. to someone who wants to give MS money but isn't buying new hardware? Wouldn't make any sense.

Also, the 64-bit versions can't run 16-bit software, and yes, I know that's getting *really*, *really* old, but I wouldn't be surprised if there are people out there (companies, especially) that are still relying on something 16-bit.

My girlfriend is interviewing for a job at a major government company here in Norway, and was told that she'd need to use DOS at work. Likely some ancient software that no-one's ever wanted to try and upgrade.
Dec 16 2011
prev sibling next sibling parent Trass3r <un known.com> writes:
 My girlfriend is interviewing for a job at a major government company
 here in Norway, and was told that she'd need to use DOS at work. Likely
 some ancient software that no-one's ever wanted to try and upgrade.

What is wrong with this world? ;)
Dec 16 2011
prev sibling next sibling parent reply Trass3r <un known.com> writes:
 DOS software can be more productive, since it's often keyboard-only.

How is that different from a Windows console app?
Dec 17 2011
parent reply Bane <branimir.milosavljevic gmail.com> writes:
Trass3r Wrote:

 DOS software can be more productive, since it's often keyboard-only.

How is that different from a Windows console app?

No Solitare, Facebook... much more productive!
Dec 17 2011
next sibling parent torhu <no spam.invalid> writes:
On 17.12.2011 19:05, Andrej Mitrovic wrote:
 Windows still ships with edit, which has more features than notepad. Heheh.

 cmd.exe /c edit

Makes me wonder what it's for, can you run a Windows server without the GUI?
Dec 17 2011
prev sibling parent torhu <no spam.invalid> writes:
On 17.12.2011 18:21, Bane wrote:
 Trass3r Wrote:

  >  DOS software can be more productive, since it's often keyboard-only.

  How is that different from a Windows console app?

No Solitare, Facebook... much more productive!

Most likely they're running the DOS app in a window in Windows, but that's a good point.
Dec 17 2011
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
Windows still ships with edit, which has more features than notepad. Heheh.

cmd.exe /c edit
Dec 17 2011
prev sibling next sibling parent "Adam Wilson" <flyboynw gmail.com> writes:
On Sat, 17 Dec 2011 11:14:51 -0800, torhu <no spam.invalid> wrote:

 On 17.12.2011 19:05, Andrej Mitrovic wrote:
 Windows still ships with edit, which has more features than notepad.  
 Heheh.

 cmd.exe /c edit

Makes me wonder what it's for, can you run a Windows server without the GUI?

Starting with Windows Server 2008 there is something called the Server Core role, which has no GUI. And they've been improving it ever since. MS is having a back-to-the-basics push internally right now. -- Adam Wilson Project Coordinator The Horizon Project http://www.thehorizonproject.org/
Dec 17 2011
prev sibling next sibling parent dmd.20.browseruk xoxy.net writes:
On Thu, 15 Dec 2011 23:20:50 -0000, Trass3r - un known.com  
<+dmd+browseruk+31526d5b7d.un#known.com spamgourmet.com> wrote:

It's a shame that

    a) you guys apparently cannot imagine a use for a 64-bit D on Windows.
    b) the interfaces to this newsgroup are virtually impossible to use.
    c) The only response from Mr Bright on the subject is "people are still  
using 16-bit".

I've been following along with for must be close to 5 years now, waiting  
for it to mature into a usable, production quality product.
I see I am once again too early.

buk
Dec 18 2011
prev sibling next sibling parent "steven kladitis" <steven_kladitis yahoo.com> writes:
On Thursday, 15 December 2011 at 21:05:05 UTC, captaindet wrote:
 On 2011-12-15 04:47, torhu wrote:
 On 14.12.2011 12:54, dmd.20.browseruk xoxy.net wrote:
 Hi,

 Is there a 64-bit version of DMD for windows?

 The download page offers only an x86 version. Or am I reading 
 too
 much into that?

 Cheers, buk

There's not much you would need a 64-bit compiler for on Windows. What are you going to use it for?

now what is this for a strange comment? you need 64bit for windows for the same reasons than for any other platform: accessing loads of mem. yes, for some this is really important! for me it is actually a dealbreaker - i'd love to use D for my scientific programming, but my datasets often reach several GB... my computer has 16GB and i intend to make use of them. det

It is NOT just for memory addressing , wchi is very simple under 64 bit, but also 64 bit registers, 16 of them , not just 8 32 bit. I think there should be a 64 bit version.
May 12 2014
prev sibling next sibling parent "Kapps" <opantm2+spam gmail.com> writes:
On Monday, 12 May 2014 at 16:47:21 UTC, steven kladitis wrote:
 It is NOT just for memory addressing , wchi is very simple 
 under 64 bit, but also 64 bit registers, 16 of them , not just 
 8 32 bit.  I think there should be a 64 bit version.

This topic is 3 years old, DMD can already generate 64-bit programs on Windows (although I don't think DMD itself is 64-bit).
May 12 2014
prev sibling next sibling parent "steven kladitis" <steven_kladitis yahoo.com> writes:
On Monday, 12 May 2014 at 17:46:21 UTC, Kapps wrote:
 On Monday, 12 May 2014 at 16:47:21 UTC, steven kladitis wrote:
 It is NOT just for memory addressing , wchi is very simple 
 under 64 bit, but also 64 bit registers, 16 of them , not just 
 8 32 bit.  I think there should be a 64 bit version.

This topic is 3 years old, DMD can already generate 64-bit programs on Windows (although I don't think DMD itself is 64-bit).

I still only see 32 bit version for Windows. I admit I have a 32 bit laptop , over 10 years old :) . All other laptops and pcs I have are 64 bit processors. If anyone out there has a 64 bit; version 2.065 , for windows let me know.
May 12 2014
prev sibling next sibling parent Andrej Mitrovic via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 5/12/14, Nick Sabalausky via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 You don't need a 64-bit version: Compiling 64-bit programs doesn't
 require a 64-bit compiler. Just install VC++, use the DMD 2.065 Win
 installer, and then toss in the -m64 flag when compiling. Works fine.
 Doesn't matter if DMD itself is 32-bit.

As Vladimir in IRC reminded me, there is one use-case: You may need it for some intensive CTFE stuff (excessive memory allocations and no freeing by the compiler). That is, if you need more than 3/4 gigs.
May 12 2014
prev sibling next sibling parent "steven kladitis" <steven_kladitis yahoo.com> writes:
On Monday, 12 May 2014 at 23:21:28 UTC, Nick Sabalausky wrote:
 On 5/12/2014 5:01 PM, Andrej Mitrovic via Digitalmars-d wrote:
 On 5/12/14, Nick Sabalausky via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:
 You don't need a 64-bit version: Compiling 64-bit programs 
 doesn't
 require a 64-bit compiler. Just install VC++, use the DMD 
 2.065 Win
 installer, and then toss in the -m64 flag when compiling. 
 Works fine.
 Doesn't matter if DMD itself is 32-bit.

As Vladimir in IRC reminded me, there is one use-case: You may need it for some intensive CTFE stuff (excessive memory allocations and no freeing by the compiler). That is, if you need more than 3/4 gigs.

Right, there's certainly that. But that has nothing to do with whether you're trying to build a 64-bit or 32-bit program, and (at least for Windows) it isn't even an issue at all unless you actually are hitting that limit (unlikely for a newcomer to D). It sounded like steven kladitis was worried about just being able to create 64-bit programs. For that, it makes no difference if the compiler itself is a 32- or 64-bit build.

dmd -m64 ( windows ) says \bin\link not found :)
May 13 2014
prev sibling next sibling parent "steven kladitis" <steven_kladitis yahoo.com> writes:
On Tuesday, 13 May 2014 at 13:16:50 UTC, steven kladitis wrote:
 On Monday, 12 May 2014 at 23:21:28 UTC, Nick Sabalausky wrote:
 On 5/12/2014 5:01 PM, Andrej Mitrovic via Digitalmars-d wrote:
 On 5/12/14, Nick Sabalausky via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:
 You don't need a 64-bit version: Compiling 64-bit programs 
 doesn't
 require a 64-bit compiler. Just install VC++, use the DMD 
 2.065 Win
 installer, and then toss in the -m64 flag when compiling. 
 Works fine.
 Doesn't matter if DMD itself is 32-bit.

As Vladimir in IRC reminded me, there is one use-case: You may need it for some intensive CTFE stuff (excessive memory allocations and no freeing by the compiler). That is, if you need more than 3/4 gigs.

Right, there's certainly that. But that has nothing to do with whether you're trying to build a 64-bit or 32-bit program, and (at least for Windows) it isn't even an issue at all unless you actually are hitting that limit (unlikely for a newcomer to D). It sounded like steven kladitis was worried about just being able to create 64-bit programs. For that, it makes no difference if the compiler itself is a 32- or 64-bit build.

dmd -m64 ( windows ) says \bin\link not found :)

if the -m64 lets the compiled code use 64 bit registers and ints are now 64 bit then great! What is VC++, is it free?
May 13 2014
prev sibling next sibling parent Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 13 May 2014 23:24, steven kladitis via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 On Tuesday, 13 May 2014 at 13:16:50 UTC, steven kladitis wrote:
 On Monday, 12 May 2014 at 23:21:28 UTC, Nick Sabalausky wrote:
 On 5/12/2014 5:01 PM, Andrej Mitrovic via Digitalmars-d wrote:
 On 5/12/14, Nick Sabalausky via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:
 You don't need a 64-bit version: Compiling 64-bit programs doesn't
 require a 64-bit compiler. Just install VC++, use the DMD 2.065 Win
 installer, and then toss in the -m64 flag when compiling. Works fine.
 Doesn't matter if DMD itself is 32-bit.

As Vladimir in IRC reminded me, there is one use-case: You may need it for some intensive CTFE stuff (excessive memory allocations and no freeing by the compiler). That is, if you need more than 3/4 gigs.

Right, there's certainly that. But that has nothing to do with whether you're trying to build a 64-bit or 32-bit program, and (at least for Windows) it isn't even an issue at all unless you actually are hitting that limit (unlikely for a newcomer to D). It sounded like steven kladitis was worried about just being able to create 64-bit programs. For that, it makes no difference if the compiler itself is a 32- or 64-bit build.

dmd -m64 ( windows ) says \bin\link not found :)

if the -m64 lets the compiled code use 64 bit registers and ints are now 64 bit then great! What is VC++, is it free?

Pointers are 64bits. int is 32 bits, long is 64 bits. size_t is 64 bits. VC++ is Microsoft's compiler, DMD-x64 uses the de-facto standard Microsoft linker, since OPTLINK doesn't support 64bit. It is available for free.
May 13 2014
prev sibling next sibling parent "Kagamin" <spam here.lot> writes:
On Tuesday, 13 May 2014 at 16:43:26 UTC, Daniel Murphy wrote:
 long is 32 bits.

http://dlang.org/type
May 13 2014
prev sibling next sibling parent "steven kladitis" <steven_kladitis yahoo.com> writes:
On Tuesday, 13 May 2014 at 13:53:36 UTC, Manu via Digitalmars-d 
wrote:
 On 13 May 2014 23:24, steven kladitis via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:
 On Tuesday, 13 May 2014 at 13:16:50 UTC, steven kladitis wrote:
 On Monday, 12 May 2014 at 23:21:28 UTC, Nick Sabalausky wrote:
 On 5/12/2014 5:01 PM, Andrej Mitrovic via Digitalmars-d 
 wrote:
 On 5/12/14, Nick Sabalausky via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:
 You don't need a 64-bit version: Compiling 64-bit programs 
 doesn't
 require a 64-bit compiler. Just install VC++, use the DMD 
 2.065 Win
 installer, and then toss in the -m64 flag when compiling. 
 Works fine.
 Doesn't matter if DMD itself is 32-bit.

As Vladimir in IRC reminded me, there is one use-case: You may need it for some intensive CTFE stuff (excessive memory allocations and no freeing by the compiler). That is, if you need more than 3/4 gigs.

Right, there's certainly that. But that has nothing to do with whether you're trying to build a 64-bit or 32-bit program, and (at least for Windows) it isn't even an issue at all unless you actually are hitting that limit (unlikely for a newcomer to D). It sounded like steven kladitis was worried about just being able to create 64-bit programs. For that, it makes no difference if the compiler itself is a 32- or 64-bit build.

dmd -m64 ( windows ) says \bin\link not found :)

if the -m64 lets the compiled code use 64 bit registers and ints are now 64 bit then great! What is VC++, is it free?

Pointers are 64bits. int is 32 bits, long is 64 bits. size_t is 64 bits. VC++ is Microsoft's compiler, DMD-x64 uses the de-facto standard Microsoft linker, since OPTLINK doesn't support 64bit. It is available for free.

I have installed it and am still unable to compile a 64 bit D program. C:\d\dmd2\samples\d>dmd wc.d C:\d\dmd2\samples\d>dmd -m64 wc.d --- errorlevel -1073741515
May 14 2014
prev sibling next sibling parent "Joakim" <dlang joakim.airpost.net> writes:
On Wednesday, 14 May 2014 at 18:28:09 UTC, steven kladitis wrote:
 On Tuesday, 13 May 2014 at 13:53:36 UTC, Manu via Digitalmars-d 
 wrote:
 VC++ is Microsoft's compiler, DMD-x64 uses the de-facto 
 standard
 Microsoft linker, since OPTLINK doesn't support 64bit.
 It is available for free.

I have installed it and am still unable to compile a 64 bit D program. C:\d\dmd2\samples\d>dmd wc.d C:\d\dmd2\samples\d>dmd -m64 wc.d --- errorlevel -1073741515

64-bit compilation on Windows doesn't work out of the box, because it uses the Microsoft linker and that requires its own setup. Here's how I did it: http://forum.dlang.org/thread/CALBgG1WH95Ysi-25AYL9WKn9TDnSUH2iGnX9tJSkFxYO87KBiQ mail.gmail.com#post-hvdyyutbgehlefluvsup:40forum.dlang.org
May 14 2014
prev sibling next sibling parent "steven kladitis" <steven_kladitis yahoo.com> writes:
On Wednesday, 14 May 2014 at 20:10:29 UTC, Nick Sabalausky wrote:
 On 5/14/2014 2:28 PM, steven kladitis wrote:
 On Tuesday, 13 May 2014 at 13:53:36 UTC, Manu via 
 Digitalmars-d wrote:
 On 13 May 2014 23:24, steven kladitis via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:
 if the -m64 lets the compiled code use 64 bit registers and 
 ints are
 now 64
 bit then great! What is VC++, is it free?

Pointers are 64bits. int is 32 bits, long is 64 bits. size_t is 64 bits. VC++ is Microsoft's compiler, DMD-x64 uses the de-facto standard Microsoft linker, since OPTLINK doesn't support 64bit. It is available for free.

I have installed it and am still unable to compile a 64 bit D program. C:\d\dmd2\samples\d>dmd wc.d C:\d\dmd2\samples\d>dmd -m64 wc.d --- errorlevel -1073741515

If you use the Windows Installer for DMD after you've installed VC++, then it should automatically set everything up for you (I haven't tried it personally, but I know the DMD Win Installer people went to a lot of effort to make it work, so it should work). Oh, I forgot to mention, you'll also need to install the Microsoft's Windows SDK (not sure if that's automatically done when installing VC++ or not.) So after VC++ and the WinSDK are installed, then run DMD's Windows installer, and you should be good. Or you can manually setup DMD's sc.ini with the right paths to VC++ and the WinSDK (that's what I did), but it's probably easier to just run the DMD Windows Installer again after all the MS stuff is installed.

I see that this thread is over 3 years old. I am totally enjoying D. I love assembler programming. I am just dissapointed that there is simple way to compile 64 bit code as of 2014 in windows. I am still unable to compile 64 bit in windows 7 or 8.
May 19 2014
prev sibling next sibling parent "Temtaime" <temtaime gmail.com> writes:
Windows is out of favor for DMD's developers.
May 20 2014
prev sibling next sibling parent "David Nadlinger" <code klickverbot.at> writes:
On Monday, 19 May 2014 at 17:59:43 UTC, steven kladitis wrote:
 I see that this thread is over 3 years old.  I am totally 
 enjoying D. I love assembler programming.  I am just 
 dissapointed that there is simple way to compile 64 bit code as 
 of 2014 in windows.  I am still unable to compile 64 bit in 
 windows 7 or 8.

How does the current 64 bit version of DMD fall short of your needs? David
May 20 2014
prev sibling next sibling parent Andrej Mitrovic via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 5/20/14, Temtaime via Digitalmars-d <digitalmars-d puremagic.com> wrote:
 Windows is out of favor for DMD's developers.

Please stop spreading misinformation.
May 20 2014
prev sibling next sibling parent "Temtaime" <temtaime gmail.com> writes:
Why mis ?
For example.

Linux :
DMD can use GCC libs.
DMD can compile and link 64 bit app.

Windows :
DMD cannot use both MSVC and MinGW libs.
DMD cannot link 64 apps without installed MSVS.

And it's stays there for a long time.
May 20 2014
prev sibling next sibling parent "Temtaime" <temtaime gmail.com> writes:
Please don't ask useful-less questions.
One can tell all the advantages of 64 bits or you can use the 
Wikipedia.
May 20 2014
prev sibling next sibling parent "David Nadlinger" <code klickverbot.at> writes:
On Tuesday, 20 May 2014 at 18:47:46 UTC, Temtaime wrote:
 Please don't ask useful-less questions.
 One can tell all the advantages of 64 bits or you can use the 
 Wikipedia.

You might want to read my response again. I specifically asked "How does the current 64 bit version of DMD fall short of your needs?". To put it in simpler terms: DMD is available for x64 Windows right now. What else do you want? David
May 20 2014
prev sibling next sibling parent "rumbu" <rumbu rumbu.ro> writes:
On Tuesday, 20 May 2014 at 16:29:27 UTC, Andrej Mitrovic via 
Digitalmars-d wrote:
 On 5/20/14, Temtaime via Digitalmars-d 
 <digitalmars-d puremagic.com> wrote:
 Windows is out of favor for DMD's developers.

Please stop spreading misinformation.

- std.c.windows seriously outdated; third party libraries also outdated. - WinRT support non-existent, D language lacks the necessary constructs (automatic reference counting, asynchronous calls). ARM compiler not available. - 64 bit linker unavailable without Visual Studio; - Run-time library loading on Windows is bugs prone. - There is no consensus about how a GUI application must be built. Windows is by definition a GUI OS. You cannot say that you support Windows by limiting developers to build console applications only. Using third party libraries makes you think in anti-D patterns and results in big size executable files. D must first define some guidelines about a GUI application design and implement it for each OS. The Delphi or Lazarus approach can be used as a starting point.
May 20 2014
prev sibling next sibling parent "Temtaime" <temtaime gmail.com> writes:
Sorry i misunderstood you.
Yes dmd supports x64 on windows but it doesn't work without 
external tools.
It's a main trouble i think.
May 20 2014
prev sibling next sibling parent "David Nadlinger" <code klickverbot.at> writes:
On Tuesday, 20 May 2014 at 19:15:59 UTC, Temtaime wrote:
 Yes dmd supports x64 on windows but it doesn't work without 
 external tools.

DMD on Linux doesn't work without external tools (system GCC/ld) either. Microsoft provides the required tools for free and they are not difficult to install, so that shouldn't really be an argument. Maybe we need to improve on the related documentation, though. Best, David
May 20 2014
prev sibling next sibling parent Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 21 May 2014 05:15, Temtaime via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 Sorry i misunderstood you.
 Yes dmd supports x64 on windows but it doesn't work without external tools.
 It's a main trouble i think.

MSVC is the de facto standard toolset for Windows. How do you interoperate with any other conventional windows libraries if DMD is not MSVC compatible? This is the key development of DMD for Win64, and it's the only reason D is practically useful on Windows at all. I pine for the day that 32bit will get the same treatment. The Microsoft linker is freely available, it produces debug output that's compatible with the majority of windows tooling, and it's generally good. If you argue that your environment is exclusive of MSVC (how so? do you use MinGW or something?), then surely the obvious thing to do is to NOT use DMD. Use GDC or LDC, which are better compilers, and link happily against MinGW code/libs. The only deficit I see in the Windows world is not having a useful Win32 compiler.
May 20 2014
prev sibling next sibling parent "Temtaime" <temtaime gmail.com> writes:
Yes, DMD uses ld on linux. It's OK because there is no other
linker. And it's system's default. Everybody(almost) have GCC.

But on windows.. MSVS is external IDE and toolset. Some people
yes they uses MinGW.
Why ? MSVS has some disadvantages for me for example it's poor
C++11 support. So it's useless in my work.

So for compile 64 app with DMD one must download dmd(~20 MB) and
install MSVS(~2 GB).
I think dmd should work out of the box isn't it ?

And what about other compilers ?
Latest LDC for example uses 064 frontend.

It's outdated for me because of bugs. I cannot ever compile my
app now with it.
With GDC it's alto difficult to get luck.
May 20 2014
prev sibling next sibling parent Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 21 May 2014 13:45, Temtaime via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 Yes, DMD uses ld on linux. It's OK because there is no other
 linker. And it's system's default. Everybody(almost) have GCC.

 But on windows.. MSVS is external IDE and toolset. Some people
 yes they uses MinGW.
 Why ? MSVS has some disadvantages for me for example it's poor
 C++11 support. So it's useless in my work.

 So for compile 64 app with DMD one must download dmd(~20 MB) and
 install MSVS(~2 GB).
 I think dmd should work out of the box isn't it ?

It's still the standard on the platform. Interoperation with other libraries/code typically demands MSVC compatibility. I don't know how any large-scale Windows developers can avoid this practical reality? On the plus side, there is a recent push to get Clang/LLVM properly compatible with MSVC. When that happens, we should be able to rely on Clang+LDC for all windows needs.
 And what about other compilers ?
 Latest LDC for example uses 064 frontend.

 It's outdated for me because of bugs. I cannot ever compile my
 app now with it.
 With GDC it's alto difficult to get luck.

Poke the GDC/LDC guys? It would certainly be nice if those toolchains were more reliably up-to-date, but the sad truth is, those who use MinGW on windows are in the severe minority, so there's probably not so much motivation.
May 20 2014
prev sibling next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Wednesday, 21 May 2014 at 03:45:42 UTC, Temtaime wrote:
 Yes, DMD uses ld on linux. It's OK because there is no other
 linker. And it's system's default. Everybody(almost) have GCC.

 But on windows.. MSVS is external IDE and toolset. Some people
 yes they uses MinGW.
 Why ? MSVS has some disadvantages for me for example it's poor
 C++11 support. So it's useless in my work.

 So for compile 64 app with DMD one must download dmd(~20 MB) and
 install MSVS(~2 GB).
 I think dmd should work out of the box isn't it ?

 And what about other compilers ?
 Latest LDC for example uses 064 frontend.

 It's outdated for me because of bugs. I cannot ever compile my
 app now with it.
 With GDC it's alto difficult to get luck.

MSVC is the OS vendor's official tooling. Like XCode/clang on Mac OS X, xlc on Aix, aC++ on HP-UX, SunPro on Solaris and so forth. -- Paulo
May 21 2014
prev sibling next sibling parent "Brad Anderson" <eco gnuk.net> writes:
On Wednesday, 21 May 2014 at 03:15:34 UTC, Manu via Digitalmars-d
wrote:
 On 21 May 2014 05:15, Temtaime via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:
 Sorry i misunderstood you.
 Yes dmd supports x64 on windows but it doesn't work without 
 external tools.
 It's a main trouble i think.

MSVC is the de facto standard toolset for Windows. How do you interoperate with any other conventional windows libraries if DMD is not MSVC compatible? This is the key development of DMD for Win64, and it's the only reason D is practically useful on Windows at all. I pine for the day that 32bit will get the same treatment.

I believe Rainer did some work on extending COFF support to 32-bit. I'm not sure how far along he got.
May 21 2014
prev sibling next sibling parent "Joakim" <dlang joakim.airpost.net> writes:
On Thursday, 22 May 2014 at 06:16:54 UTC, Rainer Schuetze wrote:
 I recently considered making a pull request, but noticed an 
 include dependency that failed to work for another PR, and got 
 distracted. The updated compiler patches are here: 
 https://github.com/rainers/dmd/tree/coff32

the most widely used platform on which D is available. Not everybody has the source for outside libraries or the time and inclination to recompile it to OMF using the Digital Mars toolchain. I think it would really help D to get this pull in soon.
May 21 2014
prev sibling next sibling parent Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 22 May 2014 16:28, Joakim via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 On Thursday, 22 May 2014 at 06:16:54 UTC, Rainer Schuetze wrote:
 I recently considered making a pull request, but noticed an include
 dependency that failed to work for another PR, and got distracted. The
 updated compiler patches are here:
 https://github.com/rainers/dmd/tree/coff32

I think this is a really important pull for win32 support, still the most widely used platform on which D is available. Not everybody has the source for outside libraries or the time and inclination to recompile it to OMF using the Digital Mars toolchain. I think it would really help D to get this pull in soon.

Yeah, it's a gigantic hole, and your work looks like it's almost there. Do you have any idea about the x64 SSE support and supporting that on x86 as well? Difficult? Practical?
May 22 2014
prev sibling next sibling parent "Kagamin" <spam here.lot> writes:
On Wednesday, 21 May 2014 at 03:45:42 UTC, Temtaime wrote:
 Yes, DMD uses ld on linux. It's OK because there is no other
 linker. And it's system's default. Everybody(almost) have GCC.

It's still an external tool, without which dmd can't work.
 But on windows.. MSVS is external IDE and toolset.

Do you want the windows dmd installed to download and install msvc automatically for you?
May 22 2014
prev sibling next sibling parent "Kagamin" <spam here.lot> writes:
On Thursday, 22 May 2014 at 06:28:14 UTC, Joakim wrote:
 On Thursday, 22 May 2014 at 06:16:54 UTC, Rainer Schuetze wrote:
 I recently considered making a pull request, but noticed an 
 include dependency that failed to work for another PR, and got 
 distracted. The updated compiler patches are here: 
 https://github.com/rainers/dmd/tree/coff32

still the most widely used platform on which D is available. Not everybody has the source for outside libraries or the time and inclination to recompile it to OMF using the Digital Mars toolchain. I think it would really help D to get this pull in soon.

How would it work? Will it link D code with snn, msvcrt or both?
May 22 2014
prev sibling next sibling parent "Joakim" <dlang joakim.airpost.net> writes:
On Thursday, 22 May 2014 at 07:45:17 UTC, Kagamin wrote:
 On Thursday, 22 May 2014 at 06:28:14 UTC, Joakim wrote:
 I think this is a really important pull for win32 support, 
 still the most widely used platform on which D is available.  
 Not everybody has the source for outside libraries or the time 
 and inclination to recompile it to OMF using the Digital Mars 
 toolchain.  I think it would really help D to get this pull in 
 soon.

How would it work? Will it link D code with snn, msvcrt or both?

Why would you need snn at that point? It's an OMF library. You'd do the same as Win64, use msvcrt.
May 22 2014
prev sibling next sibling parent "Kagamin" <spam here.lot> writes:
Ah, ok, but druntime and phobos are compiled to link with snn, 
which has functions absent in msvcrt like snvprintf and long 
double math functions.
May 22 2014
prev sibling next sibling parent Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 22 May 2014 20:37, Kagamin via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 Ah, ok, but druntime and phobos are compiled to link with snn, which has
 functions absent in msvcrt like snvprintf and long double math functions.

That doesn't seem to bother Win64...
May 22 2014
prev sibling next sibling parent "Anonymous" <anon anon.com> writes:
With VS2013 installed, I had an issue with the DMD installer's
config. mspdb*.dll are located in VC/bin, not VC/bin/x86_amd64,
and using -m64 caused a linker error. Adding %VCINSTALLDIR%\bin
to sc.ini's PATH fixed the problem and produced a working hello
world with -m64.
May 22 2014
prev sibling parent Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 23 May 2014 01:45, Anonymous via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 With VS2013 installed, I had an issue with the DMD installer's
 config. mspdb*.dll are located in VC/bin, not VC/bin/x86_amd64,
 and using -m64 caused a linker error. Adding %VCINSTALLDIR%\bin
 to sc.ini's PATH fixed the problem and produced a working hello
 world with -m64.

The installer needs to be updated to be aware of VS2013's pathing. Bug it?
May 22 2014