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?

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

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

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

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