www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Poll of the week: main OS and compiler

reply "Marco Leise" <Marco.Leise gmx.de> writes:
Since everyone loves polls, and the question comes up now and then: What is
your main development platform for D ?

http://www.easypolls.net/poll.html?p=4f4f7d25c2e1b0e40b0ac494
Mar 01 2012
next sibling parent reply Manu <turkeyman gmail.com> writes:
Windows leads. Amazing!

COFF + 64bit plz! ;)

On 1 March 2012 16:40, Marco Leise <Marco.Leise gmx.de> wrote:


 Since everyone loves polls, and the question comes up now and then: What
 is your main development platform for D ?

 http://www.easypolls.net/poll.**html?p=**4f4f7d25c2e1b0e40b0ac494<http://www.easypolls.net/poll.html?p=4f4f7d25c2e1b0e40b0ac494>
Mar 01 2012
parent "Marco Leise" <Marco.Leise gmx.de> writes:
Am 01.03.2012, 17:10 Uhr, schrieb Manu <turkeyman gmail.com>:


 Windows leads. Amazing!

 COFF + 64bit plz! ;)


You would have gotten it by tomorrow, but unfortunately now the *nix systems
lead by a few % so this feature must obviously be postponed to next year.
Mar 01 2012
prev sibling next sibling parent Kevin Cox <kevincox.ca gmail.com> writes:
On Mar 1, 2012 11:11 AM, "Manu" <turkeyman gmail.com> wrote:

 Windows leads. Amazing!

 COFF + 64bit plz! ;)


 On 1 March 2012 16:40, Marco Leise <Marco.Leise gmx.de> wrote:

 Since everyone loves polls, and the question comes up now and then: What




is your main development platform for D ?

 http://www.easypolls.net/poll.html?p=4f4f7d25c2e1b0e40b0ac494




Right now its tired between BSD/Linux and windoze.
Mar 01 2012
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2012-03-01 15:40, Marco Leise wrote:

 Since everyone loves polls, and the question comes up now and then: What
 is your main development platform for D ?

 http://www.easypolls.net/poll.html?p=4f4f7d25c2e1b0e40b0ac494


Why bundle Linux and FreeBSD in one option?

-- 
/Jacob Carlborg
Mar 01 2012
next sibling parent Gour <gour atmarama.net> writes:
On Thu, 01 Mar 2012 21:26:59 +0100
Jacob Carlborg <doob me.com> wrote:


 Why bundle Linux and FreeBSD in one option?


To make it harder for Windows to win. :-}


Sincerely,
Gour


--=20
The spirit soul bewildered by the influence of false ego thinks=20
himself the doer of activities that are in actuality carried out=20
by the three modes of material nature.

http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810
Mar 01 2012
prev sibling parent reply "Marco Leise" <Marco.Leise gmx.de> writes:
Am 01.03.2012, 21:26 Uhr, schrieb Jacob Carlborg <doob me.com>:


 On 2012-03-01 15:40, Marco Leise wrote:

 Since everyone loves polls, and the question comes up now and then: What
 is your main development platform for D ?

 http://www.easypolls.net/poll.html?p=4f4f7d25c2e1b0e40b0ac494


 Why bundle Linux and FreeBSD in one option?


I considered the two 'similar enough' from a point of view of architecture and
organization to merge them (aka Unix-like). I admit, that I never used FreeBSD
though.
Anyway the numbers nicely show, that neither Windows nor Linux(-compatible) are
underrepresented in the D community. My personal opinion is that the number of
Windows users is actually low, considering its market share and other surveys
like this: http://redmonk.com/sogrady/2010/10/27/developer-os-preferences/
Mar 01 2012
next sibling parent Manu <turkeyman gmail.com> writes:
On 2 March 2012 09:47, Marco Leise <Marco.Leise gmx.de> wrote:


 Am 01.03.2012, 21:26 Uhr, schrieb Jacob Carlborg <doob me.com>:


  On 2012-03-01 15:40, Marco Leise wrote:

 Since everyone loves polls, and the question comes up now and then: What
 is your main development platform for D ?

 http://www.easypolls.net/poll.**html?p=**4f4f7d25c2e1b0e40b0ac494<http://www.easypolls.net/poll.html?p=4f4f7d25c2e1b0e40b0ac494>


 Why bundle Linux and FreeBSD in one option?


 I considered the two 'similar enough' from a point of view of architecture
 and organization to merge them (aka Unix-like). I admit, that I never used
 FreeBSD though.
 Anyway the numbers nicely show, that neither Windows nor
 Linux(-compatible) are underrepresented in the D community. My personal
 opinion is that the number of Windows users is actually low, considering
 its market share and other surveys like this: http://redmonk.com/sogrady/*
 *2010/10/27/developer-os-**preferences/<http://redmonk.com/sogrady/2010/10/27/developer-os-preferences/>


But we knew that already, because most of the D devs are linux guys, and D
does not present a good experience to Windows users. I can personally point
to numerous friends/colleagues who tried out D and turned away within a few
hours because the Windows experience was so weak.
Windows support should be prioritised BECAUSE Windows numbers are low, not
because there's perceived to be no demand on that platform.
Mar 02 2012
prev sibling next sibling parent Brad Roberts <braddr puremagic.com> writes:
On 3/2/2012 12:25 AM, Manu wrote:

 But we knew that already, because most of the D devs are linux guys, and D
does not present a good experience to Windows
 users. I can personally point to numerous friends/colleagues who tried out D
and turned away within a few hours because
 the Windows experience was so weak.
 Windows support should be prioritized BECAUSE Windows numbers are low, not
because there's perceived to be no demand on
 that platform.


I'm fairly your assertion is incorrect, if by "d devs" you mean the guys that
are building dmd/druntime/phobos.  I think
we actually have more contributors that are windows based than linux based.  At
a minimum the numbers are well balanced,
not wildly lopsided towards linux.

No one has ever claimed that there's no demand for windows support.  What's
been asserted is that it's easier to support
linux/bsd/osx.  And indeed that was backed up by how much time was spent on the
platform specific parts vs the generic
parts while implementing 64 bit support.  Windows will get 64 bit support at
some point.  That's not even a question.
What is a question is when, and there isn't a good answer for that right now.

There's a clear need to focus/prioritize limited resources.  It's not a hard
choice to decide to defer spending many
months working on win64 and other platform specific support issues when there's
still language level issues that cross
every platform.  That said, as always, if someone wants to scratch that itch
and contribute to improving the windows
specific parts, help will be welcomed with open arms and lots of encouragement.

Later,
Brad
Mar 02 2012
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-03-02 08:47, Marco Leise wrote:

 Am 01.03.2012, 21:26 Uhr, schrieb Jacob Carlborg <doob me.com>:


 On 2012-03-01 15:40, Marco Leise wrote:

 Since everyone loves polls, and the question comes up now and then: What
 is your main development platform for D ?

 http://www.easypolls.net/poll.html?p=4f4f7d25c2e1b0e40b0ac494


 Why bundle Linux and FreeBSD in one option?


 I considered the two 'similar enough' from a point of view of
 architecture and organization to merge them (aka Unix-like). I admit,
 that I never used FreeBSD though.
 Anyway the numbers nicely show, that neither Windows nor
 Linux(-compatible) are underrepresented in the D community. My personal
 opinion is that the number of Windows users is actually low, considering
 its market share and other surveys like this:
 http://redmonk.com/sogrady/2010/10/27/developer-os-preferences/


It depends on how you see it. Both FreeBSD and Mac OS X are built on a 
BSD foundation but Linux is not. On the other hand FreeBSD and Linux 
uses ELF binaries but Mac OS X use Mach-O.

-- 
/Jacob Carlborg
Mar 02 2012
prev sibling parent reply Manu <turkeyman gmail.com> writes:
On 2 March 2012 11:09, Brad Roberts <braddr puremagic.com> wrote:


 On 3/2/2012 12:25 AM, Manu wrote:

 But we knew that already, because most of the D devs are linux guys, and


 D does not present a good experience to Windows

 users. I can personally point to numerous friends/colleagues who tried


 out D and turned away within a few hours because

 the Windows experience was so weak.
 Windows support should be prioritized BECAUSE Windows numbers are low,


 not because there's perceived to be no demand on

 that platform.


 I'm fairly your assertion is incorrect, if by "d devs" you mean the guys
 that are building dmd/druntime/phobos.  I think
 we actually have more contributors that are windows based than linux
 based.  At a minimum the numbers are well balanced,
 not wildly lopsided towards linux.

 No one has ever claimed that there's no demand for windows support.
  What's been asserted is that it's easier to support
 linux/bsd/osx.  And indeed that was backed up by how much time was spent
 on the platform specific parts vs the generic
 parts while implementing 64 bit support.  Windows will get 64 bit support
 at some point.  That's not even a question.
 What is a question is when, and there isn't a good answer for that right
 now.

 There's a clear need to focus/prioritize limited resources.  It's not a
 hard choice to decide to defer spending many
 months working on win64 and other platform specific support issues when
 there's still language level issues that cross
 every platform.  That said, as always, if someone wants to scratch that
 itch and contribute to improving the windows
 specific parts, help will be welcomed with open arms and lots of
 encouragement.


I wonder what the loss in potential contributors adds up to from those that
turn away on account of incomplete windows support?
Is it possible that loss of potential manpower is significant enough to
justify the time spent?

Also, does it represent a loss to D in terms of marketing? Some genuinely
interested parties who turn away because they couldn't begin working with
the language effectively may then relay that negative experience to other
potential developers (I've witnessed this, and had to argue myself that D
is not actually shit, it's just an unfinished implementation).

Personally, I just want to be able to link like a normal windows developer.
My code is C/C++, built with VC, and I want to link my D app against those
libs using the VC linker, and debug with Visual Studio. This is the
workflow I think the vast majority of Windows devs will expect, and it
sounds simple enough. This is the only thing standing between me using D
for any major projects, and just experimenting with the language for
evaluation, or just academic interest.
64bit is far less important to me personally, VisualC linker compatibility
is the big one. I just want to link against my C code without jumping
through lots of hoops.
Mar 02 2012
next sibling parent reply "Bernard Helyer" <b.helyer gmail.com> writes:
On Friday, 2 March 2012 at 11:53:56 UTC, Manu wrote:

 Personally, I just want to be able to link like a normal 
 windows developer.
 My code is C/C++, built with VC, and I want to link my D app 
 against those
 libs using the VC linker, and debug with Visual Studio. This is 
 the
 workflow I think the vast majority of Windows devs will expect, 
 and it
 sounds simple enough. This is the only thing standing between 
 me using D
 for any major projects, and just experimenting with the 
 language for
 evaluation, or just academic interest.
 64bit is far less important to me personally, VisualC linker 
 compatibility
 is the big one. I just want to link against my C code without 
 jumping
 through lots of hoops.


No one thinks that's a bad idea. The trouble is the amount of 
developers that actually understand the backend enough to 
implement another object format (which is what's needed to 
support the VisualC linker) is very small.

What's needed is someone to take the time to learn it then do it. 
Someone motivated, and smart. Not unlike yourself! :P
Mar 02 2012
next sibling parent Manu <turkeyman gmail.com> writes:
On 2 March 2012 23:16, Bernard Helyer <b.helyer gmail.com> wrote:


 On Friday, 2 March 2012 at 11:53:56 UTC, Manu wrote:


 Personally, I just want to be able to link like a normal windows
 developer.
 My code is C/C++, built with VC, and I want to link my D app against those
 libs using the VC linker, and debug with Visual Studio. This is the
 workflow I think the vast majority of Windows devs will expect, and it
 sounds simple enough. This is the only thing standing between me using D
 for any major projects, and just experimenting with the language for
 evaluation, or just academic interest.
 64bit is far less important to me personally, VisualC linker compatibility
 is the big one. I just want to link against my C code without jumping
 through lots of hoops.


 No one thinks that's a bad idea. The trouble is the amount of developers
 that actually understand the backend enough to implement another object
 format (which is what's needed to support the VisualC linker) is very small.

 What's needed is someone to take the time to learn it then do it. Someone
 motivated, and smart. Not unlike yourself! :P


Haha, ohhh, I see what you did there.
Well played...
Mar 03 2012
prev sibling parent reply "Daniel Murphy" <yebblies nospamgmail.com> writes:
"Bernard Helyer" <b.helyer gmail.com> wrote in message 
news:nlzougvwvlvnmjbufwgi forum.dlang.org...

 No one thinks that's a bad idea. The trouble is the amount of developers 
 that actually understand the backend enough to implement another object 
 format (which is what's needed to support the VisualC linker) is very 
 small.

 What's needed is someone to take the time to learn it then do it. Someone 
 motivated, and smart. Not unlike yourself! :P


The problem isn't really the backend - there are currently _three_ full 
object file generators in dmd and it should be possible to use the same 
interfaces these do without caring what most of the backend is really doing.

Generating Microsoft coff objects means deciphering the spec to see what 
everything should look like, generating every kind of entry with msvc to see 
what it _actually_ does, then translating all the record/fixup/section types 
from omf to the coff equivalents.  With this (and maybe updates to the 
runtime to use msvc's instead of dmc's c runtime) you have 32 bit coff on 
windows.

To get from there to 64bit, you need the following:
- 64 bit coff (I think these are closely related)
- 64 bit c runtime (just use microsofts?)
- 64 bit d runtime (eh, io with a different runtime, etc)
- 64 bit codegen (hopefully not much more than some calling convention 
stuff)
- 64 bit linker (Again, just use ms?)

Just generating coff is a pretty big step, it requires learning how object 
formats work (I don't think many people already have the depth of 
understanding required), how coff works and how dmd generates object files 
(which probably means understanding omf/elf/mach).

The only person I can think of who would even know how long it would take to 
learn all this is Walter, and considering that he's hasn't done it already, 
I'd guess it's quite a huge task.

Walter, how big is it really?  Small enough to be done as, say, a gsoc 
project?  Would you be interested in mentoring such a project?
Mar 03 2012
next sibling parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 3/3/2012 12:44 PM, Daniel Murphy wrote:

 "Bernard Helyer"<b.helyer gmail.com>  wrote in message
 news:nlzougvwvlvnmjbufwgi forum.dlang.org...

 No one thinks that's a bad idea. The trouble is the amount of developers
 that actually understand the backend enough to implement another object
 format (which is what's needed to support the VisualC linker) is very
 small.

 What's needed is someone to take the time to learn it then do it. Someone
 motivated, and smart. Not unlike yourself! :P


 The problem isn't really the backend - there are currently _three_ full
 object file generators in dmd and it should be possible to use the same
 interfaces these do without caring what most of the backend is really doing.


A good step forward would be a better separation of the object file 
format from the target OS and the host OS. Removing that preprocessor 
hell is needed anyway if you want to switch between object file formats 
by a command line switch.
In addition, it would be pretty nice if you could at least compile with 
predefined version OSX, even if you are working on Windows.


 Generating Microsoft coff objects means deciphering the spec to see what
 everything should look like, generating every kind of entry with msvc to see
 what it _actually_ does, then translating all the record/fixup/section types
 from omf to the coff equivalents.  With this (and maybe updates to the
 runtime to use msvc's instead of dmc's c runtime) you have 32 bit coff on
 windows.


Don't forget debug info: as far as I can tell, the Microsoft linker 
accepts codeview debug info in the object file, you don't have to write 
pdb files. From my experience with cv2pdb, the debug records are a 
straight forward extension of the debug info currently written by dmd.
Mar 03 2012
parent "Daniel Murphy" <yebblies nospamgmail.com> writes:
"Rainer Schuetze" <r.sagitario gmx.de> wrote in message 
news:jit3hk$tgb$1 digitalmars.com...

 A good step forward would be a better separation of the object file format 
 from the target OS and the host OS. Removing that preprocessor hell is 
 needed anyway if you want to switch between object file formats by a 
 command line switch.
 In addition, it would be pretty nice if you could at least compile with 
 predefined version OSX, even if you are working on Windows.


Yeah, this would be nice.


 Generating Microsoft coff objects means deciphering the spec to see what
 everything should look like, generating every kind of entry with msvc to 
 see
 what it _actually_ does, then translating all the record/fixup/section 
 types
 from omf to the coff equivalents.  With this (and maybe updates to the
 runtime to use msvc's instead of dmc's c runtime) you have 32 bit coff on
 windows.


 Don't forget debug info: as far as I can tell, the Microsoft linker 
 accepts codeview debug info in the object file, you don't have to write 
 pdb files. From my experience with cv2pdb, the debug records are a 
 straight forward extension of the debug info currently written by dmd.


(I did forget it) But that's great!  Not having to add a new debug info 
format can only be a good thing.
Mar 03 2012
prev sibling parent reply "David Nadlinger" <see klickverbot.at> writes:
On Saturday, 3 March 2012 at 11:44:54 UTC, Daniel Murphy wrote:

 Walter, how big is it really?  Small enough to be done as, say, 
 a gsoc
 project?  Would you be interested in mentoring such a project?


I don't know whether it would really be a problem from a legal 
(Google) point of view, but having a GSoC student work on 
non-Open Source software seems strange at least.

David
Mar 08 2012
next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Thursday, March 08, 2012 09:45:34 David Nadlinger wrote:

 On Saturday, 3 March 2012 at 11:44:54 UTC, Daniel Murphy wrote:

 Walter, how big is it really?  Small enough to be done as, say,
 a gsoc
 project?  Would you be interested in mentoring such a project?


 
 I don't know whether it would really be a problem from a legal
 (Google) point of view, but having a GSoC student work on
 non-Open Source software seems strange at least.


I though that GSoC had a list of licenses which were acceptable for GSoC 
projects - all of which are open source license of one variety or another.

- Jonathan M Davis
Mar 08 2012
parent reply "Bernard Helyer" <b.helyer gmail.com> writes:
On Thursday, 8 March 2012 at 09:25:19 UTC, Jonathan M Davis wrote:

 On Thursday, March 08, 2012 09:45:34 David Nadlinger wrote:

 On Saturday, 3 March 2012 at 11:44:54 UTC, Daniel Murphy wrote:

 Walter, how big is it really?  Small enough to be done as, 
 say,
 a gsoc
 project?  Would you be interested in mentoring such a 
 project?


 
 I don't know whether it would really be a problem from a legal
 (Google) point of view, but having a GSoC student work on
 non-Open Source software seems strange at least.


 I though that GSoC had a list of licenses which were acceptable 
 for GSoC
 projects - all of which are open source license of one variety 
 or another.

 - Jonathan M Davis


That's his point; the backend isn't open source.
Mar 08 2012
parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Thursday, March 08, 2012 11:20:03 Bernard Helyer wrote:

 On Thursday, 8 March 2012 at 09:25:19 UTC, Jonathan M Davis wrote:

 On Thursday, March 08, 2012 09:45:34 David Nadlinger wrote:

 On Saturday, 3 March 2012 at 11:44:54 UTC, Daniel Murphy wrote:

 Walter, how big is it really? Small enough to be done as,
 say,
 a gsoc
 project? Would you be interested in mentoring such a
 project?


 
 I don't know whether it would really be a problem from a legal
 (Google) point of view, but having a GSoC student work on
 non-Open Source software seems strange at least.


 
 I though that GSoC had a list of licenses which were acceptable
 for GSoC
 projects - all of which are open source license of one variety
 or another.
 
 - Jonathan M Davis


 
 That's his point; the backend isn't open source.


?? David doesn't seem to making that point. He's saying that it would be 
"strange," not that it would be against the rules.

- Jonathan M Davis
Mar 08 2012
parent "David Nadlinger" <see klickverbot.at> writes:
On Thursday, 8 March 2012 at 19:13:03 UTC, Jonathan M Davis wrote:

 On Thursday, March 08, 2012 11:20:03 Bernard Helyer wrote:

 On Thursday, 8 March 2012 at 09:25:19 UTC, Jonathan M Davis 
 wrote:

 On Thursday, March 08, 2012 09:45:34 David Nadlinger wrote:

 I don't know whether it would really be a problem from a 
 legal
 (Google) point of view, but having a GSoC student work on
 non-Open Source software seems strange at least.


 
 I though that GSoC had a list of licenses which were 
 acceptable
 for GSoC
 projects - all of which are open source license of one 
 variety
 or another.
 
 - Jonathan M Davis


 
 That's his point; the backend isn't open source.


 ?? David doesn't seem to making that point. He's saying that it 
 would be
 "strange," not that it would be against the rules.


Sorry, seems like I didn't make myself clear – I meant that 
from my point of view, it would be strange to have a GSoC student 
work on the backend, which isn't Open Source. It could also be a 
problem from a formal point of view because Google IIRC requires 
the code to be released under an OSI-approved license, but I'm 
not sure about that.

David
Mar 08 2012
prev sibling parent "Daniel Murphy" <yebblies nospamgmail.com> writes:
"David Nadlinger" <see klickverbot.at> wrote in message 
news:refqfgvqmhafcmeljhcr forum.dlang.org...

 On Saturday, 3 March 2012 at 11:44:54 UTC, Daniel Murphy wrote:

 Walter, how big is it really?  Small enough to be done as, say, a gsoc
 project?  Would you be interested in mentoring such a project?


 I don't know whether it would really be a problem from a legal (Google) 
 point of view, but having a GSoC student work on non-Open Source software 
 seems strange at least.

 David


Didn't think of that... I'm not sure what the license on the object 
generation code is, the files are not in the backend folder but they are 
conceptually part of the backend, and not useful to other compilers like the 
frontend is.
Mar 08 2012
prev sibling parent reply "Mars" <- -.-> writes:
On Friday, 2 March 2012 at 11:53:56 UTC, Manu wrote:

 Personally, I just want to be able to link like a normal 
 windows developer.
 My code is C/C++, built with VC, and I want to link my D app 
 against those
 libs using the VC linker, and debug with Visual Studio. This is 
 the
 workflow I think the vast majority of Windows devs will expect, 
 and it
 sounds simple enough. This is the only thing standing between 
 me using D
 for any major projects, and just experimenting with the 
 language for
 evaluation, or just academic interest.
 64bit is far less important to me personally, VisualC linker 
 compatibility
 is the big one. I just want to link against my C code without 
 jumping
 through lots of hoops.


That's exactly my problem... and although I love D, these hurdles 
made me take a step back, to C++, while I wait for this to 
change, so I can finally use D efficiently.

I'm sure this isn't a trivial task, but the problematic isn't new 
after all. Why hasn't it been addressed yet? In my eyes this 
should be a top priority, to make it easier for new users to get 
into D. Till this poll I actually believed the problem was that D 
isn't used much by Windows users.
Mar 07 2012
next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Wednesday, March 07, 2012 23:07:11 Mars wrote:

 On Friday, 2 March 2012 at 11:53:56 UTC, Manu wrote:

 Personally, I just want to be able to link like a normal
 windows developer.
 My code is C/C++, built with VC, and I want to link my D app
 against those
 libs using the VC linker, and debug with Visual Studio. This is
 the
 workflow I think the vast majority of Windows devs will expect,
 and it
 sounds simple enough. This is the only thing standing between
 me using D
 for any major projects, and just experimenting with the
 language for
 evaluation, or just academic interest.
 64bit is far less important to me personally, VisualC linker
 compatibility
 is the big one. I just want to link against my C code without
 jumping
 through lots of hoops.


 
 That's exactly my problem... and although I love D, these hurdles
 made me take a step back, to C++, while I wait for this to
 change, so I can finally use D efficiently.
 
 I'm sure this isn't a trivial task, but the problematic isn't new
 after all. Why hasn't it been addressed yet? In my eyes this
 should be a top priority, to make it easier for new users to get
 into D. Till this poll I actually believed the problem was that D
 isn't used much by Windows users.


I don' think that Walter really views it as much of a problem - or if he does, 
he didn't used to. Remember that he's used to an environment where he doesn't 
use Visual Studio or Microsoft's C++ compiler. And his customers use dmc just 
like he does (since they're his customers), so many of the people that he 
interacts with in the C/C++ world are not necessarily particularly Microsoft-
centric on Windows.

Add to that the enormous task that it is to actually make dmd work with COFF 
or 64-bit or anything of the sort on Windows, and it's no wonder that it 
hasn't happened yet.

To be fair, there are plenty of other things that have needed to be done, and 
what we have for Windows does work, even if it's suboptimal. So, it's not all 
that unreasonable that the issue would be put off as long as it has been. And 
Walter _has_ been slowing working on porting optlink to C (the fact that it's 
written in assembly makes it really fast but hard to maintain and change), 
which would make it possible to then start porting stuff to 64-bit and 
considering COFF and stuff like that.

I expect that we'll get there eventually, but there's so much to do, and this 
particular issue is not only hard, but there's pretty much only one person 
currently qualified to do it, so it hasn't happened yet.

- Jonathan M Davis
Mar 07 2012
prev sibling parent reply Manu <turkeyman gmail.com> writes:
On 8 March 2012 00:21, Jonathan M Davis <jmdavisProg gmx.com> wrote:


 On Wednesday, March 07, 2012 23:07:11 Mars wrote:

 On Friday, 2 March 2012 at 11:53:56 UTC, Manu wrote:

 Personally, I just want to be able to link like a normal
 windows developer.
 My code is C/C++, built with VC, and I want to link my D app
 against those
 libs using the VC linker, and debug with Visual Studio. This is
 the
 workflow I think the vast majority of Windows devs will expect,
 and it
 sounds simple enough. This is the only thing standing between
 me using D
 for any major projects, and just experimenting with the
 language for
 evaluation, or just academic interest.
 64bit is far less important to me personally, VisualC linker
 compatibility
 is the big one. I just want to link against my C code without
 jumping
 through lots of hoops.


 That's exactly my problem... and although I love D, these hurdles
 made me take a step back, to C++, while I wait for this to
 change, so I can finally use D efficiently.

 I'm sure this isn't a trivial task, but the problematic isn't new
 after all. Why hasn't it been addressed yet? In my eyes this
 should be a top priority, to make it easier for new users to get
 into D. Till this poll I actually believed the problem was that D
 isn't used much by Windows users.


 I don' think that Walter really views it as much of a problem - or if he
 does,
 he didn't used to. Remember that he's used to an environment where he
 doesn't
 use Visual Studio or Microsoft's C++ compiler. And his customers use dmc
 just
 like he does (since they're his customers), so many of the people that he
 interacts with in the C/C++ world are not necessarily particularly
 Microsoft-
 centric on Windows.

 Add to that the enormous task that it is to actually make dmd work with
 COFF
 or 64-bit or anything of the sort on Windows, and it's no wonder that it
 hasn't happened yet.

 To be fair, there are plenty of other things that have needed to be done,
 and
 what we have for Windows does work, even if it's suboptimal. So, it's not
 all
 that unreasonable that the issue would be put off as long as it has been.
 And
 Walter _has_ been slowing working on porting optlink to C (the fact that
 it's
 written in assembly makes it really fast but hard to maintain and change),
 which would make it possible to then start porting stuff to 64-bit and
 considering COFF and stuff like that.


Is it possible to just fix the compiler to output COFF objects *without*
touching optlink at all?
I'm not interested in using optlink with this feature, I intend to link
with Visual Studio, that's the whole point. So ignoring optlink, that's a
major slice of work taken out of the equation...
Maybe it would be nice to support optlink in future, but it seems the
priority is backwards.




 I expect that we'll get there eventually, but there's so much to do, and
 this
 particular issue is not only hard, but there's pretty much only one person
 currently qualified to do it, so it hasn't happened yet.

 - Jonathan M Davis
Mar 08 2012
next sibling parent reply "Daniel Murphy" <yebblies nospamgmail.com> writes:
"Manu" <turkeyman gmail.com> wrote in message 
news:mailman.223.1331197934.4860.digitalmars-d puremagic.com...
On 8 March 2012 00:21, Jonathan M Davis <jmdavisProg gmx.com> wrote:

 Is it possible to just fix the compiler to output COFF objects *without* 
 touching optlink at all?
 I'm not interested in using optlink with this feature, I intend to link 
 with Visual Studio, that's the whole point. So ignoring optlink, that's a 
 major slice of work taken out of the equation...
 Maybe it would be nice to support optlink in future, but it seems the 
 priority is backwards.


Yes, it is, but then you still won't be able to link omf and coff object 
files/libraries together, meaning you need a coff version of 
druntime/phobos/any other d libraries, and you can't use the c runtime made 
by dmc etc.

Ideally everything would work together, and with a tool that can be bundled 
with D.
Mar 08 2012
parent Manu <turkeyman gmail.com> writes:
On 8 March 2012 15:55, Daniel Murphy <yebblies nospamgmail.com> wrote:


 "Manu" <turkeyman gmail.com> wrote in message
 news:mailman.223.1331197934.4860.digitalmars-d puremagic.com...
 On 8 March 2012 00:21, Jonathan M Davis <jmdavisProg gmx.com> wrote:

 Is it possible to just fix the compiler to output COFF objects *without*
 touching optlink at all?
 I'm not interested in using optlink with this feature, I intend to link
 with Visual Studio, that's the whole point. So ignoring optlink, that's a
 major slice of work taken out of the equation...
 Maybe it would be nice to support optlink in future, but it seems the
 priority is backwards.


 Yes, it is, but then you still won't be able to link omf and coff object
 files/libraries together, meaning you need a coff version of
 druntime/phobos/any other d libraries, and you can't use the c runtime made
 by dmc etc.


That's fine, I would use the mscrt (required to link with all the rest of
my code anyway), and as soon as the feature is available, you can bet your
boots that OMF will cease to exist in windows library distributions
instantly.
When was the last time you saw a closed-source windows library ship with .a
files? Windows library distributions would be VC compatible COFF objects
within days.

Ideally everything would work together, and with a tool that can be bundled

 with D.


Optlink is bundled with D, I presume OMF would remain an option as a
standalone 'complete package', but realistically, I don't think virtually
any windows users would use it once they can link with VS.
The kind of Windows user that might use OMF+optlink is the same kind of
user that would be perfectly happy, maybe even prefer to use GDC/LDC.
Mar 08 2012
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2012-03-08 10:12, Manu wrote:

 On 8 March 2012 00:21, Jonathan M Davis <jmdavisProg gmx.com
 <mailto:jmdavisProg gmx.com>> wrote:

     On Wednesday, March 07, 2012 23:07:11 Mars wrote:
      > On Friday, 2 March 2012 at 11:53:56 UTC, Manu wrote:
      > > Personally, I just want to be able to link like a normal
      > > windows developer.
      > > My code is C/C++, built with VC, and I want to link my D app
      > > against those
      > > libs using the VC linker, and debug with Visual Studio. This is
      > > the
      > > workflow I think the vast majority of Windows devs will expect,
      > > and it
      > > sounds simple enough. This is the only thing standing between
      > > me using D
      > > for any major projects, and just experimenting with the
      > > language for
      > > evaluation, or just academic interest.
      > > 64bit is far less important to me personally, VisualC linker
      > > compatibility
      > > is the big one. I just want to link against my C code without
      > > jumping
      > > through lots of hoops.
      >
      > That's exactly my problem... and although I love D, these hurdles
      > made me take a step back, to C++, while I wait for this to
      > change, so I can finally use D efficiently.
      >
      > I'm sure this isn't a trivial task, but the problematic isn't new
      > after all. Why hasn't it been addressed yet? In my eyes this
      > should be a top priority, to make it easier for new users to get
      > into D. Till this poll I actually believed the problem was that D
      > isn't used much by Windows users.

     I don' think that Walter really views it as much of a problem - or
     if he does,
     he didn't used to. Remember that he's used to an environment where
     he doesn't
     use Visual Studio or Microsoft's C++ compiler. And his customers use
     dmc just
     like he does (since they're his customers), so many of the people
     that he
     interacts with in the C/C++ world are not necessarily particularly
     Microsoft-
     centric on Windows.

     Add to that the enormous task that it is to actually make dmd work
     with COFF
     or 64-bit or anything of the sort on Windows, and it's no wonder that it
     hasn't happened yet.

     To be fair, there are plenty of other things that have needed to be
     done, and
     what we have for Windows does work, even if it's suboptimal. So,
     it's not all
     that unreasonable that the issue would be put off as long as it has
     been. And
     Walter _has_ been slowing working on porting optlink to C (the fact
     that it's
     written in assembly makes it really fast but hard to maintain and
     change),
     which would make it possible to then start porting stuff to 64-bit and
     considering COFF and stuff like that.


 Is it possible to just fix the compiler to output COFF objects *without*
 touching optlink at all?
 I'm not interested in using optlink with this feature, I intend to link
 with Visual Studio, that's the whole point. So ignoring optlink, that's
 a major slice of work taken out of the equation...
 Maybe it would be nice to support optlink in future, but it seems the
 priority is backwards.


DMD would need to be compatible with the Microsoft linker and runtime as 
well, that is, except from outputting object file in the correct format.


-- 
/Jacob Carlborg
Mar 08 2012
next sibling parent reply Manu <turkeyman gmail.com> writes:
On 8 March 2012 16:41, Jacob Carlborg <doob me.com> wrote:


 On 2012-03-08 10:12, Manu wrote:


 On 8 March 2012 00:21, Jonathan M Davis <jmdavisProg gmx.com
 <mailto:jmdavisProg gmx.com>> wrote:

    On Wednesday, March 07, 2012 23:07:11 Mars wrote:
     > On Friday, 2 March 2012 at 11:53:56 UTC, Manu wrote:
     > > Personally, I just want to be able to link like a normal
     > > windows developer.
     > > My code is C/C++, built with VC, and I want to link my D app
     > > against those
     > > libs using the VC linker, and debug with Visual Studio. This is
     > > the
     > > workflow I think the vast majority of Windows devs will expect,
     > > and it
     > > sounds simple enough. This is the only thing standing between
     > > me using D
     > > for any major projects, and just experimenting with the
     > > language for
     > > evaluation, or just academic interest.
     > > 64bit is far less important to me personally, VisualC linker
     > > compatibility
     > > is the big one. I just want to link against my C code without
     > > jumping
     > > through lots of hoops.
     >
     > That's exactly my problem... and although I love D, these hurdles
     > made me take a step back, to C++, while I wait for this to
     > change, so I can finally use D efficiently.
     >
     > I'm sure this isn't a trivial task, but the problematic isn't new
     > after all. Why hasn't it been addressed yet? In my eyes this
     > should be a top priority, to make it easier for new users to get
     > into D. Till this poll I actually believed the problem was that D
     > isn't used much by Windows users.

    I don' think that Walter really views it as much of a problem - or
    if he does,
    he didn't used to. Remember that he's used to an environment where
    he doesn't
    use Visual Studio or Microsoft's C++ compiler. And his customers use
    dmc just
    like he does (since they're his customers), so many of the people
    that he
    interacts with in the C/C++ world are not necessarily particularly
    Microsoft-
    centric on Windows.

    Add to that the enormous task that it is to actually make dmd work
    with COFF
    or 64-bit or anything of the sort on Windows, and it's no wonder that
 it
    hasn't happened yet.

    To be fair, there are plenty of other things that have needed to be
    done, and
    what we have for Windows does work, even if it's suboptimal. So,
    it's not all
    that unreasonable that the issue would be put off as long as it has
    been. And
    Walter _has_ been slowing working on porting optlink to C (the fact
    that it's
    written in assembly makes it really fast but hard to maintain and
    change),
    which would make it possible to then start porting stuff to 64-bit and
    considering COFF and stuff like that.


 Is it possible to just fix the compiler to output COFF objects *without*
 touching optlink at all?
 I'm not interested in using optlink with this feature, I intend to link
 with Visual Studio, that's the whole point. So ignoring optlink, that's
 a major slice of work taken out of the equation...
 Maybe it would be nice to support optlink in future, but it seems the
 priority is backwards.


 DMD would need to be compatible with the Microsoft linker and runtime as
 well, that is, except from outputting object file in the correct format.



By 'runtime' you mean the crt? I don't think that'll be a major headache.
Probably just a few subtle differences to deal with.
A nice side effect would be that all those horrid OMF conversions of MS
libs bundled with D wouldn't be necessary.

And what else affects linker compatibility other than object format and
mangling convention?

How is DMD actually affected by any of this other than object format? Name
mangling?
Mar 08 2012
parent Jacob Carlborg <doob me.com> writes:
On 2012-03-08 16:12, Manu wrote:

 On 8 March 2012 16:41, Jacob Carlborg <doob me.com <mailto:doob me.com>>
 wrote:

     On 2012-03-08 10:12, Manu wrote:

         On 8 March 2012 00:21, Jonathan M Davis <jmdavisProg gmx.com
         <mailto:jmdavisProg gmx.com>
         <mailto:jmdavisProg gmx.com <mailto:jmdavisProg gmx.com>>> wrote:

             On Wednesday, March 07, 2012 23:07:11 Mars wrote:
          > On Friday, 2 March 2012 at 11:53:56 UTC, Manu wrote:
          > > Personally, I just want to be able to link like a normal
          > > windows developer.
          > > My code is C/C++, built with VC, and I want to link my D app
          > > against those
          > > libs using the VC linker, and debug with Visual Studio. This is
          > > the
          > > workflow I think the vast majority of Windows devs will expect,
          > > and it
          > > sounds simple enough. This is the only thing standing between
          > > me using D
          > > for any major projects, and just experimenting with the
          > > language for
          > > evaluation, or just academic interest.
          > > 64bit is far less important to me personally, VisualC linker
          > > compatibility
          > > is the big one. I just want to link against my C code without
          > > jumping
          > > through lots of hoops.
          >
          > That's exactly my problem... and although I love D, these hurdles
          > made me take a step back, to C++, while I wait for this to
          > change, so I can finally use D efficiently.
          >
          > I'm sure this isn't a trivial task, but the problematic isn't new
          > after all. Why hasn't it been addressed yet? In my eyes this
          > should be a top priority, to make it easier for new users to get
          > into D. Till this poll I actually believed the problem was that D
          > isn't used much by Windows users.

             I don' think that Walter really views it as much of a
         problem - or
             if he does,
             he didn't used to. Remember that he's used to an environment
         where
             he doesn't
             use Visual Studio or Microsoft's C++ compiler. And his
         customers use
             dmc just
             like he does (since they're his customers), so many of the
         people
             that he
             interacts with in the C/C++ world are not necessarily
         particularly
             Microsoft-
             centric on Windows.

             Add to that the enormous task that it is to actually make
         dmd work
             with COFF
             or 64-bit or anything of the sort on Windows, and it's no
         wonder that it
             hasn't happened yet.

             To be fair, there are plenty of other things that have
         needed to be
             done, and
             what we have for Windows does work, even if it's suboptimal. So,
             it's not all
             that unreasonable that the issue would be put off as long as
         it has
             been. And
             Walter _has_ been slowing working on porting optlink to C
         (the fact
             that it's
             written in assembly makes it really fast but hard to
         maintain and
             change),
             which would make it possible to then start porting stuff to
         64-bit and
             considering COFF and stuff like that.


         Is it possible to just fix the compiler to output COFF objects
         *without*
         touching optlink at all?
         I'm not interested in using optlink with this feature, I intend
         to link
         with Visual Studio, that's the whole point. So ignoring optlink,
         that's
         a major slice of work taken out of the equation...
         Maybe it would be nice to support optlink in future, but it
         seems the
         priority is backwards.


     DMD would need to be compatible with the Microsoft linker and
     runtime as well, that is, except from outputting object file in the
     correct format.


 By 'runtime' you mean the crt? I don't think that'll be a major
 headache. Probably just a few subtle differences to deal with.
 A nice side effect would be that all those horrid OMF conversions of MS
 libs bundled with D wouldn't be necessary.


Yes, the runtime used by the Microsoft compiler.


 And what else affects linker compatibility other than object format and
 mangling convention?

 How is DMD actually affected by any of this other than object format?
 Name mangling?


Jonathan explained this very good.

-- 
/Jacob Carlborg
Mar 08 2012
prev sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Thursday, March 08, 2012 17:12:53 Manu wrote:

 On 8 March 2012 16:41, Jacob Carlborg <doob me.com> wrote:

 DMD would need to be compatible with the Microsoft linker and runtime as
 well, that is, except from outputting object file in the correct format.


 
 By 'runtime' you mean the crt? I don't think that'll be a major headache.
 Probably just a few subtle differences to deal with.
 A nice side effect would be that all those horrid OMF conversions of MS
 libs bundled with D wouldn't be necessary.
 
 And what else affects linker compatibility other than object format and
 mangling convention?
 
 How is DMD actually affected by any of this other than object format? Name
 mangling?


As I understand it, Walter used to have it so that dmc (not dmd) could 
generate code compatible with Microsoft's format, but it was such a pain to 
maintain it with the changes that Microsoft kept making that he gave up on it. 
So, I'm not at all certain that anything involved with making dmd compatible 
with COFF is easy or easy to maintain. That doesn't mean that it shouldn't be 
done (far from it), but I wouldn't assume that much of anything involved with 
it isn't a big issue (like "just a few subtle differences to deal with"). We 
_might_ be that lucky, but I wouldn't bet on it. It's a major undertaking - 
albeit an important one.

- Jonathan M Davis
Mar 08 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday, March 02, 2012 01:09:37 Brad Roberts wrote:

 On 3/2/2012 12:25 AM, Manu wrote:

 But we knew that already, because most of the D devs are linux guys, and D
 does not present a good experience to Windows users. I can personally
 point to numerous friends/colleagues who tried out D and turned away
 within a few hours because the Windows experience was so weak.
 Windows support should be prioritized BECAUSE Windows numbers are low, not
 because there's perceived to be no demand on that platform.


 
 I'm fairly your assertion is incorrect, if by "d devs" you mean the guys
 that are building dmd/druntime/phobos.  I think we actually have more
 contributors that are windows based than linux based.  At a minimum the
 numbers are well balanced, not wildly lopsided towards linux.
 
 No one has ever claimed that there's no demand for windows support.  What's
 been asserted is that it's easier to support linux/bsd/osx.  And indeed
 that was backed up by how much time was spent on the platform specific
 parts vs the generic parts while implementing 64 bit support.  Windows will
 get 64 bit support at some point.  That's not even a question. What is a
 question is when, and there isn't a good answer for that right now.
 
 There's a clear need to focus/prioritize limited resources.  It's not a hard
 choice to decide to defer spending many months working on win64 and other
 platform specific support issues when there's still language level issues
 that cross every platform.  That said, as always, if someone wants to
 scratch that itch and contribute to improving the windows specific parts,
 help will be welcomed with open arms and lots of encouragement.


It's definitely a mixture. Don and Walter are primarily Windows users, I 
believe. I think that Kenji is as well. I believe that both Andrei and Sean 
are primarily Mac users. I'm a Linux user. I believe that several others are 
Linux users as well, but I don't remember exactly who uses what platform, and 
many of us use several.

The current state of Windows support has _nothing_ to do with how many Windows 
developers we have. It has everything to do with how hard it is to further 
develop the Windows support - _especially_ when most (all?) of the Windows 
support issues are on the backend.

- Jonathan M Davis
Mar 02 2012
prev sibling next sibling parent reply "Martin Nowak" <dawg dawgfoto.de> writes:
On Thu, 01 Mar 2012 15:40:38 +0100, Marco Leise <Marco.Leise gmx.de> wrote:


 Since everyone loves polls, and the question comes up now and then: What  
 is your main development platform for D ?

 http://www.easypolls.net/poll.html?p=4f4f7d25c2e1b0e40b0ac494


Where's Emacs?
Mar 02 2012
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Mar 02, 2012 at 11:37:26AM +0100, Martin Nowak wrote:

 On Thu, 01 Mar 2012 15:40:38 +0100, Marco Leise <Marco.Leise gmx.de> wrote:
 

Since everyone loves polls, and the question comes up now and
then: What is your main development platform for D ?

http://www.easypolls.net/poll.html?p=4f4f7d25c2e1b0e40b0ac494


 
 Where's Emacs?


I thought EmacsOS died off in the last ice age? Do you mean to tell me
it has living descendants today?!

;-)


T

-- 
He who laughs last thinks slowest.
Mar 02 2012
prev sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Thursday, March 08, 2012 11:12:01 Manu wrote:

 Is it possible to just fix the compiler to output COFF objects *without*
 touching optlink at all?


I have no idea. In principle, I would think so, but I don't know. But dmd 
would have to be altered so that you could choose the object format rather 
than being simply switched over to COFF regardless. Ideally, it would be 
modular enough to be able to make it output any format you like with plugins 
or somesuch, but I have no idea how it's designed. And therein is the largest 
problem regardless. Walter is probably the only person who knows the backend 
well enough to do anything like this. So, regardless of what the situation 
with optlink is, it's almost certainly going to require Walter, who's busy 
with plenty of other stuff which is also very important.

If someone could make the changes themselves and create a pull request for it, 
then we could probably get COFF, but that would require someone knowledgeable 
enough to do that, and I don't think that anyone other than Walter really is. 
If someone other than Walter is going to do it, then they've got a lot to 
learn, and no one has taken the time to do that.

- Jonathan M Davis
Mar 08 2012