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 Manu <turkeyman gmail.com> writes:
--00248c767e9614089904ba30b396
Content-Type: text/plain; charset=UTF-8

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>

--00248c767e9614089904ba30b396 Content-Type: text/html; charset=UTF-8 Windows leads. Amazing!<div><br></div><div>COFF + 64bit plz! ;)<br><br><div class="gmail_quote">On 1 March 2012 16:40, Marco Leise <span dir="ltr">&lt;<a href="mailto:Marco.Leise gmx.de">Marco.Leise gmx.de</a>&gt;</span> wrote:<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Since everyone loves polls, and the question comes up now and then: What is your main development platform for D ?<br> <br> <a href="http://www.easypolls.net/poll.html?p=4f4f7d25c2e1b0e40b0ac494" target="_blank">http://www.easypolls.net/poll.<u></u>html?p=<u></u>4f4f7d25c2e1b0e40b0ac494</a><br> </blockquote></div><br></div> --00248c767e9614089904ba30b396--
Mar 01 2012
prev sibling next sibling parent Kevin Cox <kevincox.ca gmail.com> writes:
--0015174be3848cb5b004ba30e2b3
Content-Type: text/plain; charset=UTF-8

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


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


Right now its tired between BSD/Linux and windoze. --0015174be3848cb5b004ba30e2b3 Content-Type: text/html; charset=UTF-8 <p><br> On Mar 1, 2012 11:11 AM, &quot;Manu&quot; &lt;<a href="mailto:turkeyman gmail.com">turkeyman gmail.com</a>&gt; wrote:<br> &gt;<br> &gt; Windows leads. Amazing!<br> &gt;<br> &gt; COFF + 64bit plz! ;)<br> &gt;<br> &gt;<br> &gt; On 1 March 2012 16:40, Marco Leise &lt;<a href="mailto:Marco.Leise gmx.de">Marco.Leise gmx.de</a>&gt; wrote:<br> &gt;&gt;<br> &gt;&gt; Since everyone loves polls, and the question comes up now and then: What is your main development platform for D ?<br> &gt;&gt;<br> &gt;&gt; <a href="http://www.easypolls.net/poll.html?p=4f4f7d25c2e1b0e40b0ac494">http://www.easypolls.net/poll.html?p=4f4f7d25c2e1b0e40b0ac494</a><br> &gt;<br> &gt;</p> <p>Right now its tired between BSD/Linux and windoze.<br> </p> --0015174be3848cb5b004ba30e2b3--
Mar 01 2012
prev sibling next sibling 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 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 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 "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 "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 next sibling parent Gour <gour atmarama.net> writes:
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

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 next sibling parent "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
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--00248c6a86e26c833f04ba3e525d
Content-Type: text/plain; charset=UTF-8

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. --00248c6a86e26c833f04ba3e525d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On 2 March 2012 09:47, Marco Leise <span dir=3D"= ltr">&lt;<a href=3D"mailto:Marco.Leise gmx.de">Marco.Leise gmx.de</a>&gt;</= span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e= x;border-left:1px #ccc solid;padding-left:1ex"> Am 01.03.2012, 21:26 Uhr, schrieb Jacob Carlborg &lt;<a href=3D"mailto:doob= me.com" target=3D"_blank">doob me.com</a>&gt;:<div><div class=3D"h5"><br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> On 2012-03-01 15:40, Marco Leise wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Since everyone loves polls, and the question comes up now and then: What<br=

<br> <a href=3D"http://www.easypolls.net/poll.html?p=3D4f4f7d25c2e1b0e40b0ac494"= target=3D"_blank">http://www.easypolls.net/poll.<u></u>html?p=3D<u></u>4f4= f7d25c2e1b0e40b0ac494</a><br> </blockquote> <br> Why bundle Linux and FreeBSD in one option?<br> </blockquote> <br></div></div> I considered the two &#39;similar enough&#39; from a point of view of archi= tecture and organization to merge them (aka Unix-like). I admit, that I nev= er used FreeBSD though.<br> Anyway the numbers nicely show, that neither Windows nor Linux(-compatible)= are underrepresented in the D community. My personal opinion is that the n= umber of Windows users is actually low, considering its market share and ot= her surveys like this: <a href=3D"http://redmonk.com/sogrady/2010/10/27/dev= eloper-os-preferences/" target=3D"_blank">http://redmonk.com/sogrady/<u></u=
2010/10/27/developer-os-<u></u>preferences/</a><br>

</blockquote></div><br><div>But we knew that already, because most of the D= devs are linux guys, and D does not present a good experience to Windows u= sers. 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 w= eak.</div> <div>Windows support should be prioritised BECAUSE Windows numbers are low,= not because there&#39;s perceived to be no demand on that platform.</div> --00248c6a86e26c833f04ba3e525d--
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 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 "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
prev sibling next sibling parent reply Manu <turkeyman gmail.com> writes:
--20cf306f72f8a02d8504ba413a14
Content-Type: text/plain; charset=UTF-8

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

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

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

 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. --20cf306f72f8a02d8504ba413a14 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On 2 March 2012 11:09, Brad Roberts <span dir=3D= "ltr">&lt;<a href=3D"mailto:braddr puremagic.com">braddr puremagic.com</a>&= gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 = 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class=3D"im">On 3/2/2012 12:25 AM, Manu wrote:<br> &gt; But we knew that already, because most of the D devs are linux guys, a= nd D does not present a good experience to Windows<br> &gt; users. I can personally point to numerous friends/colleagues who tried= out D and turned away within a few hours because<br> &gt; the Windows experience was so weak.<br> </div>&gt; Windows support should be prioritized BECAUSE Windows numbers ar= e low, not because there&#39;s perceived to be no demand on<br> &gt; that platform.<br> <br> I&#39;m fairly your assertion is incorrect, if by &quot;d devs&quot; you me= an the guys that are building dmd/druntime/phobos. =C2=A0I think<br> we actually have more contributors that are windows based than linux based.= =C2=A0At a minimum the numbers are well balanced,<br> not wildly lopsided towards linux.<br> <br> No one has ever claimed that there&#39;s no demand for windows support. =C2= =A0What&#39;s been asserted is that it&#39;s easier to support<br> linux/bsd/osx. =C2=A0And indeed that was backed up by how much time was spe= nt on the platform specific parts vs the generic<br> parts while implementing 64 bit support. =C2=A0Windows will get 64 bit supp= ort at some point. =C2=A0That&#39;s not even a question.<br> What is a question is when, and there isn&#39;t a good answer for that righ= t now.<br> <br> There&#39;s a clear need to focus/prioritize limited resources. =C2=A0It&#3= 9;s not a hard choice to decide to defer spending many<br> months working on win64 and other platform specific support issues when the= re&#39;s still language level issues that cross<br> every platform. =C2=A0That said, as always, if someone wants to scratch tha= t itch and contribute to improving the windows<br> specific parts, help will be welcomed with open arms and lots of encouragem= ent.<br></blockquote><div><br></div><div>I wonder what the loss in potentia= l contributors adds up to from those that turn away on account of incomplet= e windows support?</div> <div>Is it possible that loss of potential manpower is significant enough t= o justify the time spent?</div><div><br></div><div>Also, does it represent = a loss to D in terms of marketing? Some genuinely interested parties who tu= rn away because they couldn&#39;t begin working with the language effective= ly may then relay that negative experience to other potential developers (I= &#39;ve witnessed this, and had to argue myself that D is not actually shit= , it&#39;s just an unfinished implementation).</div> <div><br></div><div>Personally, I just want to be able to link like a norma= l 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 expec= t, 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 fo= r evaluation, or just academic interest.</div> <div>64bit is far less important to me personally, VisualC linker compatibi= lity is the big one. I just want to link against my C code without jumping = through lots of hoops.</div></div> --20cf306f72f8a02d8504ba413a14--
Mar 02 2012
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
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 next sibling 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 next sibling parent "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
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--20cf3074b5a24c9cf704ba5398c3
Content-Type: text/plain; charset=UTF-8

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... --20cf3074b5a24c9cf704ba5398c3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 2 March 2012 23:16, Bernard Helyer <span dir=3D"ltr">&lt;<a href=3D"mail= to:b.helyer gmail.com">b.helyer gmail.com</a>&gt;</span> wrote:<br><div cla= ss=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 = .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class=3D"im">On Friday, 2 March 2012 at 11:53:56 UTC, Manu wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Personally, I just want to be able to link like a normal windows developer.= <br> My code is C/C++, built with VC, and I want to link my D app against those<= br> libs using the VC linker, and debug with Visual Studio. This is the<br> workflow I think the vast majority of Windows devs will expect, and it<br> sounds simple enough. This is the only thing standing between me using D<br=

evaluation, or just academic interest.<br> 64bit is far less important to me personally, VisualC linker compatibility<= br> is the big one. I just want to link against my C code without jumping<br> through lots of hoops.<br> </blockquote> <br></div> No one thinks that&#39;s a bad idea. The trouble is the amount of developer= s that actually understand the backend enough to implement another object f= ormat (which is what&#39;s needed to support the VisualC linker) is very sm= all.<br> <br> What&#39;s needed is someone to take the time to learn it then do it. Someo= ne motivated, and smart. Not unlike yourself! :P<br> </blockquote></div><br><div>Haha, ohhh, I see what you did there.</div><div=
Well played...</div>

--20cf3074b5a24c9cf704ba5398c3--
Mar 03 2012
prev sibling next sibling parent "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
prev sibling 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 next sibling parent "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
prev sibling next sibling parent reply Manu <turkeyman gmail.com> writes:
--20cf3063e32f41b89704bab7ab8b
Content-Type: text/plain; charset=UTF-8

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

--20cf3063e32f41b89704bab7ab8b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On 8 March 2012 00:21, Jonathan M Davis <span di= r=3D"ltr">&lt;<a href=3D"mailto:jmdavisProg gmx.com">jmdavisProg gmx.com</a=
&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 =

<div class=3D"HOEnZb"><div class=3D"h5">On Wednesday, March 07, 2012 23:07:= 11 Mars wrote:<br> &gt; On Friday, 2 March 2012 at 11:53:56 UTC, Manu wrote:<br> &gt; &gt; Personally, I just want to be able to link like a normal<br> &gt; &gt; windows developer.<br> &gt; &gt; My code is C/C++, built with VC, and I want to link my D app<br> &gt; &gt; against those<br> &gt; &gt; libs using the VC linker, and debug with Visual Studio. This is<b= r> &gt; &gt; the<br> &gt; &gt; workflow I think the vast majority of Windows devs will expect,<b= r> &gt; &gt; and it<br> &gt; &gt; sounds simple enough. This is the only thing standing between<br> &gt; &gt; me using D<br> &gt; &gt; for any major projects, and just experimenting with the<br> &gt; &gt; language for<br> &gt; &gt; evaluation, or just academic interest.<br> &gt; &gt; 64bit is far less important to me personally, VisualC linker<br> &gt; &gt; compatibility<br> &gt; &gt; is the big one. I just want to link against my C code without<br> &gt; &gt; jumping<br> &gt; &gt; through lots of hoops.<br> &gt;<br> &gt; That&#39;s exactly my problem... and although I love D, these hurdles<= br> &gt; made me take a step back, to C++, while I wait for this to<br> &gt; change, so I can finally use D efficiently.<br> &gt;<br> &gt; I&#39;m sure this isn&#39;t a trivial task, but the problematic isn&#3= 9;t new<br> &gt; after all. Why hasn&#39;t it been addressed yet? In my eyes this<br> &gt; should be a top priority, to make it easier for new users to get<br> &gt; into D. Till this poll I actually believed the problem was that D<br> &gt; isn&#39;t used much by Windows users.<br> <br> </div></div>I don&#39; think that Walter really views it as much of a probl= em - or if he does,<br> he didn&#39;t used to. Remember that he&#39;s used to an environment where = he doesn&#39;t<br> use Visual Studio or Microsoft&#39;s C++ compiler. And his customers use dm= c just<br> like he does (since they&#39;re his customers), so many of the people that = he<br> interacts with in the C/C++ world are not necessarily particularly Microsof= t-<br> centric on Windows.<br> <br> Add to that the enormous task that it is to actually make dmd work with COF= F<br> or 64-bit or anything of the sort on Windows, and it&#39;s no wonder that i= t<br> hasn&#39;t happened yet.<br> <br> To be fair, there are plenty of other things that have needed to be done, a= nd<br> what we have for Windows does work, even if it&#39;s suboptimal. So, it&#39= ;s not all<br> that unreasonable that the issue would be put off as long as it has been. A= nd<br> Walter _has_ been slowing working on porting optlink to C (the fact that it= &#39;s<br> written in assembly makes it really fast but hard to maintain and change),<= br> which would make it possible to then start porting stuff to 64-bit and<br> considering COFF and stuff like that.<br></blockquote><div><br></div><div>I= s it possible to just fix the compiler to output COFF objects *without* tou= ching optlink at all?</div><div>I&#39;m not interested in using optlink wit= h this feature, I intend to link with Visual Studio, that&#39;s the whole p= oint. So ignoring optlink, that&#39;s a major slice of work taken out of th= e equation...</div> <div>Maybe it would be nice to support optlink in future, but it seems the = priority is backwards.</div><div><br></div><div>=C2=A0</div><blockquote cla= ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa= dding-left:1ex"> I expect that we&#39;ll get there eventually, but there&#39;s so much to do= , and this<br> particular issue is not only hard, but there&#39;s pretty much only one per= son<br> currently qualified to do it, so it hasn&#39;t happened yet.<br> <span class=3D"HOEnZb"><font color=3D"#888888"><br> - Jonathan M Davis<br> </font></span></blockquote></div><br> --20cf3063e32f41b89704bab7ab8b--
Mar 08 2012
parent "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
prev sibling next 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
prev sibling next sibling parent 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
prev sibling next sibling parent "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
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--20cf300faca1330f5504babc3a89
Content-Type: text/plain; charset=UTF-8

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. --20cf300faca1330f5504babc3a89 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On 8 March 2012 15:55, Daniel Murphy <span dir= =3D"ltr">&lt;<a href=3D"mailto:yebblies nospamgmail.com">yebblies nospamgma= il.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"= margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> &quot;Manu&quot; &lt;<a href=3D"mailto:turkeyman gmail.com">turkeyman gmail= .com</a>&gt; wrote in message<br> news:mailman.223.1331197934.4860.digitalmars-d puremagic.com...<br> <div class=3D"im">On 8 March 2012 00:21, Jonathan M Davis &lt;<a href=3D"ma= ilto:jmdavisProg gmx.com">jmdavisProg gmx.com</a>&gt; wrote:<br> &gt; Is it possible to just fix the compiler to output COFF objects *withou= t*<br> &gt; touching optlink at all?<br> </div><div class=3D"im">&gt; I&#39;m not interested in using optlink with t= his feature, I intend to link<br> &gt; with Visual Studio, that&#39;s the whole point. So ignoring optlink, t= hat&#39;s a<br> &gt; major slice of work taken out of the equation...<br> &gt; Maybe it would be nice to support optlink in future, but it seems the<= br> &gt; priority is backwards.<br> <br> </div>Yes, it is, but then you still won&#39;t be able to link omf and coff= object<br> files/libraries together, meaning you need a coff version of<br> druntime/phobos/any other d libraries, and you can&#39;t use the c runtime = made<br> by dmc etc.<br></blockquote><div><br></div><div>That&#39;s fine, I would us= e 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 ceas= e to exist in windows library distributions instantly.</div> <div>When was the last time you saw a closed-source windows library ship wi= th .a files? Windows library distributions would be VC compatible COFF obje= cts within days.</div><div><br></div><blockquote class=3D"gmail_quote" styl= e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Ideally everything would work together, and with a tool that can be bundled= <br> with D.<br></blockquote><div><br></div><div>Optlink is bundled with D, I pr= esume OMF would remain an option as a standalone &#39;complete package&#39;= , but realistically, I don&#39;t think virtually any windows users would us= e it once they can link with VS.</div> <div>The kind of Windows user that might use OMF+optlink is the same kind o= f user that would be perfectly happy, maybe even prefer to use GDC/LDC.</di= v></div> --20cf300faca1330f5504babc3a89--
Mar 08 2012
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--20cf300faca1cb25ac04babcb58b
Content-Type: text/plain; charset=UTF-8

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? --20cf300faca1cb25ac04babcb58b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On 8 March 2012 16:41, Jacob Carlborg <span dir= =3D"ltr">&lt;<a href=3D"mailto:doob me.com">doob me.com</a>&gt;</span> wrot= e:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l= eft:1px #ccc solid;padding-left:1ex"> <div class=3D"im">On 2012-03-08 10:12, Manu wrote:<br> </div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l= eft:1px #ccc solid;padding-left:1ex"><div class=3D"im"> On 8 March 2012 00:21, Jonathan M Davis &lt;<a href=3D"mailto:jmdavisProg g= mx.com" target=3D"_blank">jmdavisProg gmx.com</a><br></div><div><div class= =3D"h5"> &lt;mailto:<a href=3D"mailto:jmdavisProg gmx.com" target=3D"_blank">jmdavis= Prog gmx.com</a>&gt;&gt; wrote:<br> <br> =C2=A0 =C2=A0On Wednesday, March 07, 2012 23:07:11 Mars wrote:<br> =C2=A0 =C2=A0 &gt; On Friday, 2 March 2012 at 11:53:56 UTC, Manu wrote:<br=

normal<br> =C2=A0 =C2=A0 &gt; &gt; windows developer.<br> =C2=A0 =C2=A0 &gt; &gt; My code is C/C++, built with VC, and I want to lin= k my D app<br> =C2=A0 =C2=A0 &gt; &gt; against those<br> =C2=A0 =C2=A0 &gt; &gt; libs using the VC linker, and debug with Visual St= udio. This is<br> =C2=A0 =C2=A0 &gt; &gt; the<br> =C2=A0 =C2=A0 &gt; &gt; workflow I think the vast majority of Windows devs= will expect,<br> =C2=A0 =C2=A0 &gt; &gt; and it<br> =C2=A0 =C2=A0 &gt; &gt; sounds simple enough. This is the only thing stand= ing between<br> =C2=A0 =C2=A0 &gt; &gt; me using D<br> =C2=A0 =C2=A0 &gt; &gt; for any major projects, and just experimenting wit= h the<br> =C2=A0 =C2=A0 &gt; &gt; language for<br> =C2=A0 =C2=A0 &gt; &gt; evaluation, or just academic interest.<br> =C2=A0 =C2=A0 &gt; &gt; 64bit is far less important to me personally, Visu= alC linker<br> =C2=A0 =C2=A0 &gt; &gt; compatibility<br> =C2=A0 =C2=A0 &gt; &gt; is the big one. I just want to link against my C c= ode without<br> =C2=A0 =C2=A0 &gt; &gt; jumping<br> =C2=A0 =C2=A0 &gt; &gt; through lots of hoops.<br> =C2=A0 =C2=A0 &gt;<br> =C2=A0 =C2=A0 &gt; That&#39;s exactly my problem... and although I love D,= these hurdles<br> =C2=A0 =C2=A0 &gt; made me take a step back, to C++, while I wait for this= to<br> =C2=A0 =C2=A0 &gt; change, so I can finally use D efficiently.<br> =C2=A0 =C2=A0 &gt;<br> =C2=A0 =C2=A0 &gt; I&#39;m sure this isn&#39;t a trivial task, but the pro= blematic isn&#39;t new<br> =C2=A0 =C2=A0 &gt; after all. Why hasn&#39;t it been addressed yet? In my = eyes this<br> =C2=A0 =C2=A0 &gt; should be a top priority, to make it easier for new use= rs to get<br> =C2=A0 =C2=A0 &gt; into D. Till this poll I actually believed the problem = was that D<br> =C2=A0 =C2=A0 &gt; isn&#39;t used much by Windows users.<br> <br> =C2=A0 =C2=A0I don&#39; think that Walter really views it as much of a pro= blem - or<br> =C2=A0 =C2=A0if he does,<br> =C2=A0 =C2=A0he didn&#39;t used to. Remember that he&#39;s used to an envi= ronment where<br> =C2=A0 =C2=A0he doesn&#39;t<br> =C2=A0 =C2=A0use Visual Studio or Microsoft&#39;s C++ compiler. And his cu= stomers use<br> =C2=A0 =C2=A0dmc just<br> =C2=A0 =C2=A0like he does (since they&#39;re his customers), so many of th= e people<br> =C2=A0 =C2=A0that he<br> =C2=A0 =C2=A0interacts with in the C/C++ world are not necessarily particu= larly<br> =C2=A0 =C2=A0Microsoft-<br> =C2=A0 =C2=A0centric on Windows.<br> <br> =C2=A0 =C2=A0Add to that the enormous task that it is to actually make dmd= work<br> =C2=A0 =C2=A0with COFF<br> =C2=A0 =C2=A0or 64-bit or anything of the sort on Windows, and it&#39;s no= wonder that it<br> =C2=A0 =C2=A0hasn&#39;t happened yet.<br> <br> =C2=A0 =C2=A0To be fair, there are plenty of other things that have needed= to be<br> =C2=A0 =C2=A0done, and<br> =C2=A0 =C2=A0what we have for Windows does work, even if it&#39;s suboptim= al. So,<br> =C2=A0 =C2=A0it&#39;s not all<br> =C2=A0 =C2=A0that unreasonable that the issue would be put off as long as = it has<br> =C2=A0 =C2=A0been. And<br> =C2=A0 =C2=A0Walter _has_ been slowing working on porting optlink to C (th= e fact<br> =C2=A0 =C2=A0that it&#39;s<br> =C2=A0 =C2=A0written in assembly makes it really fast but hard to maintain= and<br> =C2=A0 =C2=A0change),<br> =C2=A0 =C2=A0which would make it possible to then start porting stuff to 6= 4-bit and<br> =C2=A0 =C2=A0considering COFF and stuff like that.<br> <br> <br></div></div><div class=3D"im"> Is it possible to just fix the compiler to output COFF objects *without*<br=

I&#39;m not interested in using optlink with this feature, I intend to link= <br> with Visual Studio, that&#39;s the whole point. So ignoring optlink, that&#= 39;s<br> a major slice of work taken out of the equation...<br> Maybe it would be nice to support optlink in future, but it seems the<br> priority is backwards.<br> </div></blockquote> <br> DMD would need to be compatible with the Microsoft linker and runtime as we= ll, that is, except from outputting object file in the correct format.</blo= ckquote><div><br></div><div>By &#39;runtime&#39; you mean the crt? I don&#3= 9;t think that&#39;ll be a major headache. Probably just a few subtle diffe= rences to deal with.</div> <div>A nice side effect would be that all those horrid OMF conversions of M= S libs bundled with D wouldn&#39;t be necessary.</div><div><br></div><div>A= nd what else affects linker compatibility other than object format and mang= ling convention?</div> <div><br></div><div><div>How is DMD actually affected by any of this other = than object format? Name mangling?</div></div></div> --20cf300faca1cb25ac04babcb58b--
Mar 08 2012
prev sibling next sibling parent "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
prev sibling next 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 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