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 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 next 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 "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 reply 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
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 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
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
next sibling parent reply 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
parent Andrea Fontana <advmail katamail.com> writes:
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.


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


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


 the=20

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


en if=20

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


d=20

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


at=20

 sort of stuff.
=20
 - Jonathan M Davis
Dec 16 2011
prev sibling parent reply 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
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 parent Andrea Fontana <advmail katamail.com> writes:
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.


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


=20
 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 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 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 parent reply =?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
parent reply 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
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 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
next sibling 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 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 reply 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
parent reply 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
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 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 parent reply 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
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 "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
parent reply "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
parent reply "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
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 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
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
parent reply "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
parent reply "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
parent reply 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
next sibling parent reply "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
parent "Kagamin" <spam here.lot> writes:
On Tuesday, 13 May 2014 at 16:43:26 UTC, Daniel Murphy wrote:

 long is 32 bits.


64
http://dlang.org/type
May 13 2014
prev sibling parent reply "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
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 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
parent reply "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
next sibling parent reply "Temtaime" <temtaime gmail.com> writes:
Windows is out of favor for DMD's developers.
May 20 2014
parent reply 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
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 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 parent reply "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
parent reply "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
parent reply "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
parent reply "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
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 parent reply 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
next sibling parent reply "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
next sibling parent reply 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
parent reply 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
parent reply "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
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
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 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 parent reply "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
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
parent reply "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


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.
May 21 2014
next sibling parent reply 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
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 reply "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


 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?
May 22 2014
next sibling parent reply "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
parent reply "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
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 parent reply 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


 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?


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
parent reply "Trass3r" <un known.com> writes:
Is there a PR now?
Jul 30 2014
parent Rainer Schuetze <r.sagitario gmx.de> writes:
On 30.07.2014 21:46, Trass3r wrote:

 Is there a PR now?


There is now: https://github.com/D-Programming-Language/dmd/pull/3843
Aug 02 2014
prev 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