www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - DMD - Windows

reply Manu <turkeyman gmail.com> writes:
Okay, so I was trying to link to a C lib, and I realised... DMD doesn't
support/produce VS compatible libs.
I should have realised this sooner, noting the cv debuginfo.

So like... WTF?

How am I supposed to use DMD in Windows in anything other than trivial,
self-contained programs?
VisualC is the de facto standard in Windows. All libs are COFF, and (unless
I'm working with GCC) everything I want to link to is produced from VC.

Let's also mention the debug info... Virtually every 3rd party tool assumes
and/or works best with PDB debug info. Being required to run cv2pdb is
pretty lame.

So... why no support for COFF libs, and PDB debug info?
Surely at least a compiler option would do the business if there is some
kinky attachment to CV and OMF :/

I was hoping to start a project using D as a front end language interacting
with my C/C++ engine lib... but I can't.
... and now that I think if it... how do ANY programs built with DMD
actually work? .. How does it link to system32.lib, user32.lib, etc?
Jan 06 2012
next sibling parent reply Trass3r <un known.com> writes:
Am 06.01.2012, 19:27 Uhr, schrieb Manu <turkeyman gmail.com>:


 Okay, so I was trying to link to a C lib, and I realised... DMD doesn't
 support/produce VS compatible libs.
 I should have realised this sooner, noting the cv debuginfo.

 So like... WTF?


Welcome to the jungle ^^

Your options are:
1) use dlls + implib, then you can work with MinGW or VisualC
2) use GDC, then you also get 64Bit:  
https://bitbucket.org/goshawk/gdc/downloads

*) torture yourself by trying to link statically with objconv
*) try UniLink



 Let's also mention the debug info... Virtually every 3rd party tool  
 assumes and/or works best with PDB debug info. Being required to run  
 cv2pdb is
 pretty lame.


pdb is undocumented. Even cv2pdb is based more or less on reverse  
engineering.



 ... and now that I think if it... how do ANY programs built with DMD
 actually work? .. How does it link to system32.lib, user32.lib, etc?


Those system libs are just import libraries for the respective DLLs, even  
in VS.
Jan 06 2012
parent reply "F i L" <witte2008 gmail.com> writes:
Trass3r wrote:

 2) use GDC, then you also get 64Bit:


wait... I was under the impression GDC and LDC can't build 64bit 
apps for Windows. Or are you talking about the compiler 
executing/linking in 64bit?


Manu wrote:

 - Use LDC or GDC instead of DMD. I think those work with COFF.


 
 VisualD doesn't support those compilers (yet).


I'm not sure if Mono-D supports GDC/LDC but, as a Visual Studios 
user myself, I recommend using Mono-D for D development on any 
platform (at this time at least) because of it's Code-completion 
and Renaming features. I've even converted the Obsidian syntax 
theme over if you're interested. Although Mono's syntax 
highlighting is inferior to VS in many ways (no operator or user 
types distinction) at least in v2.8.5.
http://mono-d.sourceforge.net/
Jan 06 2012
next sibling parent "Trass3r" <un known.com> writes:
On Friday, 6 January 2012 at 20:45:11 UTC, F i L wrote:

 wait... I was under the impression GDC and LDC can't build 
 64bit apps for Windows.


I thought so. Haven't tried it though cause I'm on Linux now.


 I recommend using Mono-D for D development


DDT is also shaping up nicely.
Jan 06 2012
prev sibling parent reply Manu <turkeyman gmail.com> writes:
On 6 January 2012 22:45, F i L <witte2008 gmail.com> wrote:


 Manu wrote:


 - Use LDC or GDC instead of DMD. I think those work with COFF.


 VisualD doesn't support those compilers (yet).


 I'm not sure if Mono-D supports GDC/LDC but, as a Visual Studios user
 myself, I recommend using Mono-D for D development on any platform (at this
 time at least) because of it's Code-completion and Renaming features. I've
 even converted the Obsidian syntax theme over if you're interested.
 Although Mono's syntax highlighting is inferior to VS in many ways (no
 operator or user types distinction) at least in v2.8.5.
 http://mono-d.sourceforge.net/



Nice, is the author of this someone in this community? I wonder if they
could contribute some of that effort towards VisualD... for some reason
VisualD lacks heaps of these features.

Monodevelop is surprisingly usable... although sadly, for me, my build
system uses premake to generate VisualStudio projects (and makefiles/etc on
other platforms).
I hope VisualD is given a lot more love and made awesome. But this might be
a nice option in the mean time... with manual project configuration.

I think VisualD is extremely important. It's fundamental to mainstream
adoption of D. Most windows programmers will simply not consider the
language until it is well supported in Visual Studio (and that's a LOT of
programmers, including basically the entire game dev community... [all
console SDK's are Windows+VisualStudio based])

I certainly wouldn't be using D now if VisualD didn't exist...
Jan 06 2012
next sibling parent reply "F i L" <witte2008 gmail.com> writes:
Trass3r wrote:

 DDT is also shaping up nicely.


Haven't tried it yet. Does it have context sensitive 
code-completion? Honestly I would love to use Geany because it's 
so clean and light-weight, but it just doesn't support enough 
productivity features yet.




Manu wrote:

 Monodevelop is surprisingly usable... although sadly, for me, 
 my build
 system uses premake to generate VisualStudio projects (and 
 makefiles/etc on
 other platforms).


MonoDevelop is compatible with VS2010 solution/project files. One 
of the best parts about MD is how seamlessly it works across all 
platforms. Really the best IDE on Linux and Mac IMO, but then 
again I haven't tried them all. Unfortunately Visual-D and Mono-D 
projects are incompatible. It would be great to see these two 
projects collaborate.



 ...including basically the entire game dev community... [all
 console SDK's are Windows+VisualStudio based])

 I certainly wouldn't be using D now if VisualD didn't exist...


Unity3D ships with MonoDevelop as it's primary code editor, and 
it's rather successful ;) I agree with what your saying here 
though. Power tools get the job done faster. After using proper 
code-completion and refactoring tools, it's hard to go back.
Jan 06 2012
next sibling parent Manu <turkeyman gmail.com> writes:
On 7 January 2012 02:37, F i L <witte2008 gmail.com> wrote:


 Manu wrote:


 Monodevelop is surprisingly usable... although sadly, for me, my build
 system uses premake to generate VisualStudio projects (and makefiles/etc
 on
 other platforms).


 MonoDevelop is compatible with VS2010 solution/project files. One of the
 best parts about MD is how seamlessly it works across all platforms. Really
 the best IDE on Linux and Mac IMO, but then again I haven't tried them all.
 Unfortunately Visual-D and Mono-D projects are incompatible. It would be
 great to see these two projects collaborate.


Works with VS2010 projects? Bullllshiiii....! I had no idea.
Finally! An IDE that's usable in Linux and OSX!! :)

I'll have to seriously try this out.. I haven't used monodevelop for about
a year. How does it do with C/C++ now?

If monodevelop supports vs2010 projects, then it would be REALLY awesome of
monodevelop and VisualD would agree to make their D project files
compatible...
Jan 06 2012
prev sibling parent "Trass3r" <un known.com> writes:
On Saturday, 7 January 2012 at 00:37:18 UTC, F i L wrote:

 Trass3r wrote:

 DDT is also shaping up nicely.


 Haven't tried it yet. Does it have context sensitive 
 code-completion?


Yep. But of course no semantic analysis.
http://code.google.com/a/eclipselabs.org/p/ddt/wiki/Features
Jan 06 2012
prev sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Manu" <turkeyman gmail.com> wrote in message 
news:mailman.144.1325892989.16222.digitalmars-d puremagic.com...

 Most windows programmers will simply not consider the
 language until it is well supported in Visual Studio


Yea, and that's very unfortunate. I used to be a huge fan of visual studio 
for years (from around MSVC 5 through the first or second VS.NET), but now 
that I've tasted the alternatives, I find the build/project management to be 
a little too "magical" and proprietary (or at least too incompatible and 
inbred), and the UI to be too bloated. I think a lot of the people who are 
unwilling to try anything but a heavyweight IDE are being unfair to 
themselves and their projects by keeping themselves blinded. (Obviously, if 
they've done both ways and still prefer big IDE's, that's different.)

And the thing is too, with popular overrated langauges like C++ or Java, you 
*need* a fancy IDE to get anywhere and still maintain sanity. But what many 
of those people don't get, is that with better languages, you *don't* 
actually *need* all that other stuff. Sure, it can still be a nice bonus, 
but it's *not* a necessity like with the popular "puzzle" languages they're 
used to. It's like canned vegetables: You've gotta drench that shit in salt, 
sauces, spices, and all sorts of stuff just to make it go down. But with 
food that's quality in the first place, it doesn't matter: You can either 
dress it up or leave it as-is; either way it still works 
fine...no...*better* than starting with an inferior base.
Jan 06 2012
next sibling parent Mail Mantis <mail.mantis.88 gmail.com> writes:
2012/1/7 Nick Sabalausky <a a.a>:

 news:mailman.144.1325892989.16222.digitalmars-d puremagic.com...
 Yea, and that's very unfortunate. I used to be a huge fan of visual studio
 for years (from around MSVC 5 through the first or second VS.NET), but now
 that I've tasted the alternatives, I find the build/project management to be
 a little too "magical" and proprietary (or at least too incompatible and
 inbred), and the UI to be too bloated. I think a lot of the people who are
 unwilling to try anything but a heavyweight IDE are being unfair to
 themselves and their projects by keeping themselves blinded. (Obviously, if
 they've done both ways and still prefer big IDE's, that's different.)

 And the thing is too, with popular overrated langauges like C++ or Java, you
 *need* a fancy IDE to get anywhere and still maintain sanity. But what many
 of those people don't get, is that with better languages, you *don't*
 actually *need* all that other stuff. Sure, it can still be a nice bonus,
 but it's *not* a necessity like with the popular "puzzle" languages they're
 used to. It's like canned vegetables: You've gotta drench that shit in salt,
 sauces, spices, and all sorts of stuff just to make it go down. But with
 food that's quality in the first place, it doesn't matter: You can either
 dress it up or leave it as-is; either way it still works
 fine...no...*better* than starting with an inferior base.


I agree to some extent. Visual studio has a very convenient integrated
debugging environment, and good extensibility.
Yet, I've choosen to sacrifice it for better efficiency/portability of GCC...


minutes in kinda good, but inability to efficiently use assembler, for
example, negates this benefit, IMHO.
Jan 06 2012
prev sibling next sibling parent Paulo Pinto <pjmlp progtools.org> writes:
Personally I would say that I am only able to not
use an IDE on hobby and very small scale projects.

On my line of work, where most projects are scattered around
the globe, with millions of lines and modules, the code navigation
tools that IDEs provide are priceless.

Now I am back to .NET after a few years doing mostly JVM stuff, and
I do conceed that many tools I take for granted on Java IDEs, even
for C/C++ development, are just missing in Visual Studio. It baffles
me that people find normal to buy Respher or VisualAssist for 
funcionality that other IDEs have since years.

Still, if you are doing Windows desktop applications, Visual Studio is
the only game in town. I don't want to write by hand framework 
boilerplate code that can be easily generated by Visual Studio.

And the debugger is quite nice as well.

--
Paulo

Am 07.01.2012 07:40, schrieb Nick Sabalausky:

 "Manu"<turkeyman gmail.com>  wrote in message
 news:mailman.144.1325892989.16222.digitalmars-d puremagic.com...

 Most windows programmers will simply not consider the
 language until it is well supported in Visual Studio


 Yea, and that's very unfortunate. I used to be a huge fan of visual studio
 for years (from around MSVC 5 through the first or second VS.NET), but now
 that I've tasted the alternatives, I find the build/project management to be
 a little too "magical" and proprietary (or at least too incompatible and
 inbred), and the UI to be too bloated. I think a lot of the people who are
 unwilling to try anything but a heavyweight IDE are being unfair to
 themselves and their projects by keeping themselves blinded. (Obviously, if
 they've done both ways and still prefer big IDE's, that's different.)

 And the thing is too, with popular overrated langauges like C++ or Java, you
 *need* a fancy IDE to get anywhere and still maintain sanity. But what many
 of those people don't get, is that with better languages, you *don't*
 actually *need* all that other stuff. Sure, it can still be a nice bonus,
 but it's *not* a necessity like with the popular "puzzle" languages they're
 used to. It's like canned vegetables: You've gotta drench that shit in salt,
 sauces, spices, and all sorts of stuff just to make it go down. But with
 food that's quality in the first place, it doesn't matter: You can either
 dress it up or leave it as-is; either way it still works
 fine...no...*better* than starting with an inferior base.
Jan 07 2012
prev sibling parent reply Manu <turkeyman gmail.com> writes:
On 7 January 2012 08:40, Nick Sabalausky <a a.a> wrote:


 "Manu" <turkeyman gmail.com> wrote in message
 news:mailman.144.1325892989.16222.digitalmars-d puremagic.com...

 Most windows programmers will simply not consider the
 language until it is well supported in Visual Studio


 Yea, and that's very unfortunate. I used to be a huge fan of visual studio
 for years (from around MSVC 5 through the first or second VS.NET), but now
 that I've tasted the alternatives, I find the build/project management to
 be
 a little too "magical" and proprietary (or at least too incompatible and
 inbred), and the UI to be too bloated. I think a lot of the people who are
 unwilling to try anything but a heavyweight IDE are being unfair to
 themselves and their projects by keeping themselves blinded. (Obviously, if
 they've done both ways and still prefer big IDE's, that's different.)


Your personal opinion of people who use and/or prefer visual studio is
irrelevant. Most windows devs use it, and love it. It's very important.

I for one am primarily a cross platform dev, NOT a windows/x86 dev, and I
still use and prefer VisualStudio.
I have worked extensively on these platforms: Dreamcast, PS2, XBox,
Gamecube, PS3, XBox360, Wii, PSP, NDS, iPhone, Android, Windows, and
Linux... plus some others on occasion in the last 10 years. I rarely work
on x86 platforms...
Unsurprisingly, almost every platform from that list above has reasonabe VS
integration. Console SDK's are almost all exclusively VS based (this might
be why most game devs use VS... perhaps a chicken/egg problem here, but
nobody's complaining about it. Only when the VS integration is
mediocre/half arsed to people complain...) .. Some older consoles tended to
tie themselves to CodeWarrior, but thankfully, that dwindled, and the same
platforms eventually adopted a VS integration due to demand. I've never
heard of anyone who PREFERS CodeWarrior.

What would you propose I try to convince me that VS is shit and
unproductive?

I do use build tools, like premake, which are able to produce VS projects
(and makefiles, etc, for non-windows platforms/toolchains and useful for
automated scripts)...
If you're going to talk about bloated heavy-weight IDE's, have you every
tried using Eclipse? What a joke! How is it that so many years of OSS dev
and Google backing it can produce such a bloated, crap, slow, inconsistent,
unfocused/unintegrated tool?!
How about XCode? I don't understand how anyone gets any work done with
XCode, it is just soooo crap.

So what are the alternatives? An endless mountain of annoying shell based
build systems? I use them when I need to, I like premake at the moment, and
have used others previously. It's an important part of the toolchain, but
it generally results in a VS project for actually doing productive work...
So there you go, another opinion for you, yet I believe mine is shared by
no small number of professional windows based devs ;)

And the thing is too, with popular overrated langauges like C++ or Java, you

 *need* a fancy IDE to get anywhere and still maintain sanity. But what many
 of those people don't get, is that with better languages, you *don't*
 actually *need* all that other stuff. Sure, it can still be a nice bonus,
 but it's *not* a necessity like with the popular "puzzle" languages they're
 used to. It's like canned vegetables: You've gotta drench that shit in
 salt,
 sauces, spices, and all sorts of stuff just to make it go down. But with
 food that's quality in the first place, it doesn't matter: You can either
 dress it up or leave it as-is; either way it still works
 fine...no...*better* than starting with an inferior base.


Overrated? I don't think calling industry standards overrated is a
reasonable claim. they're industry standards because everyone uses them...
and everyone uses them because they are industry standards.

tools recently. I hate C++! (that's why I'm here!).. I don't hype it up
like it's awesome, but I use it because it's industry standard, there is no
viable alternative, and even if there were, it would NEED integration with
all my tools before I could use it professionally in a full production
environment.

I don't NEED an IDE to work with those languages specifically, I *prefer*
an IDE to DO WORK FASTER... I prefer an IDE even when I'm writing python
for instance, and it annoys me that there's no IDE/debugger for embedded
LUA.

If by 'better' languages, you mean D, then I completely disagree. D *NEEDS*
an IDE, just like all the rest... and in my opinion, even more so... here
are some reasons I find it so annoying there isn't a quality VS integration
for D (yet):
  ** auto is used liberally in D... I should be able to hover over any
variable and have a tool tip inform me what it actually is (this makes it
more important that D has an IDE than even C/C++)
  ** I don't have years of experience with the libraries, I SHOULD be able
to press '.' and have a list of everything the library can do appear
instantly without wasting my time trawling through the docs.
  * I shouldn't have to guess or try and remember the name of some member
or method... I should be able to type the first 1-2 letters, and have the
rest of the word will appear instantly.
  * If I don't know what a type is, or want to know about it in more
detail, I should be able to press F1 and see documentation about the
class/function/whatever instantly.
  * I'm new to the syntax, and it's terribly nice when a little red
underline appears beneath a syntax error I've just created.
  * As projects grow, things like auto-refactor save sooo much time.
Extremely difficult to implement reliably for C/C++, but should work
perfectly in D...


just sooooo fucking productive, and that's not thanks to the language its

actually it's VS integration.

opened VS, and started typing... thanks to the integration, the language
was self-documenting and self-evident. I felt immediately productive in a
language I hadn't even read a word about, and after a little more
experience, I love its efficiency for writing the kind of code it's great
at, and I always feel amazingly productive. The experience is not limited,
or even thanks to the language, it's the whole package.


shouldn't need to KNOW a language, or basically anything about it to start
using it immediately. The IDE (auto-popup-documentation, code completion,
info tooltips, etc) is what gives me that experience. Assuming the rest of
the language and libraries are designed intuitively, it works.

The reason it matters so much to me...
I suspect I could actually propose using D in the office for small tasks,
tools, etc... everyone hates C++, it wouldn't be hard to convince them to
give it a try.
That said, If D doesn't have an IDE, or more specifically, VS integration,
it's off the table. Period. In a multi-user project, where all users expect
VS integration, I can't do without it.

be really impressed, and they'll keep coming back.
Jan 07 2012
next sibling parent Paulo Pinto <pjmlp progtools.org> writes:
Hi Manu,



I am a bit of half-insider in the game industry, being
a IGDA member for some years and also attended two
GDCE so far.

Several reasons have kept me from getting a job in the
industry, but I still follow what's happening quite closely.

 From what I know here in Europe, many studios have been slowly

are also experimenting with it in their engines.

How does it look like from your side?

I think this is important to know, because in what concerns

with good quality AOT compilers. Not sure how good Mono's AOT

language for the PlayStation VITA and the PlayStation Suite.

And game development is probably one of the few areas where D could get
an entry to.

--
Paulo


Am 07.01.2012 13:40, schrieb Manu:

 On 7 January 2012 08:40, Nick Sabalausky <a a.a> wrote:

     "Manu" <turkeyman gmail.com <mailto:turkeyman gmail.com>> wrote in
     message
     news:mailman.144.1325892989.16222.digitalmars-d puremagic.com...
      >
      > Most windows programmers will simply not consider the
      > language until it is well supported in Visual Studio
      >

     Yea, and that's very unfortunate. I used to be a huge fan of visual
     studio
     for years (from around MSVC 5 through the first or second VS.NET
     <http://VS.NET>), but now
     that I've tasted the alternatives, I find the build/project
     management to be
     a little too "magical" and proprietary (or at least too incompatible and
     inbred), and the UI to be too bloated. I think a lot of the people
     who are
     unwilling to try anything but a heavyweight IDE are being unfair to
     themselves and their projects by keeping themselves blinded.
     (Obviously, if
     they've done both ways and still prefer big IDE's, that's different.)


 Your personal opinion of people who use and/or prefer visual studio is
 irrelevant. Most windows devs use it, and love it. It's very important.

 I for one am primarily a cross platform dev, NOT a windows/x86 dev, and
 I still use and prefer VisualStudio.
 I have worked extensively on these platforms: Dreamcast, PS2, XBox,
 Gamecube, PS3, XBox360, Wii, PSP, NDS, iPhone, Android, Windows, and
 Linux... plus some others on occasion in the last 10 years. I rarely
 work on x86 platforms...
 Unsurprisingly, almost every platform from that list above has reasonabe
 VS integration. Console SDK's are almost all exclusively VS based (this
 might be why most game devs use VS... perhaps a chicken/egg problem
 here, but nobody's complaining about it. Only when the VS integration is
 mediocre/half arsed to people complain...) .. Some older consoles tended
 to tie themselves to CodeWarrior, but thankfully, that dwindled, and the
 same platforms eventually adopted a VS integration due to demand. I've
 never heard of anyone who PREFERS CodeWarrior.

 What would you propose I try to convince me that VS is shit and
 unproductive?

 I do use build tools, like premake, which are able to produce VS
 projects (and makefiles, etc, for non-windows platforms/toolchains and
 useful for automated scripts)...
 If you're going to talk about bloated heavy-weight IDE's, have you every
 tried using Eclipse? What a joke! How is it that so many years of OSS
 dev and Google backing it can produce such a bloated, crap, slow,
 inconsistent, unfocused/unintegrated tool?!
 How about XCode? I don't understand how anyone gets any work done with
 XCode, it is just soooo crap.

 So what are the alternatives? An endless mountain of annoying shell
 based build systems? I use them when I need to, I like premake at the
 moment, and have used others previously. It's an important part of the
 toolchain, but it generally results in a VS project for actually doing
 productive work...
 So there you go, another opinion for you, yet I believe mine is shared
 by no small number of professional windows based devs ;)

     And the thing is too, with popular overrated langauges like C++ or
     Java, you
     *need* a fancy IDE to get anywhere and still maintain sanity. But
     what many
     of those people don't get, is that with better languages, you *don't*
     actually *need* all that other stuff. Sure, it can still be a nice
     bonus,
     but it's *not* a necessity like with the popular "puzzle" languages
     they're
     used to. It's like canned vegetables: You've gotta drench that shit
     in salt,
     sauces, spices, and all sorts of stuff just to make it go down. But with
     food that's quality in the first place, it doesn't matter: You can
     either
     dress it up or leave it as-is; either way it still works
     fine...no...*better* than starting with an inferior base.


 Overrated? I don't think calling industry standards overrated is a
 reasonable claim. they're industry standards because everyone uses
 them... and everyone uses them because they are industry standards.

 for tools recently. I hate C++! (that's why I'm here!).. I don't hype it
 up like it's awesome, but I use it because it's industry standard, there
 is no viable alternative, and even if there were, it would NEED
 integration with all my tools before I could use it professionally in a
 full production environment.

 I don't NEED an IDE to work with those languages specifically, I
 *prefer* an IDE to DO WORK FASTER... I prefer an IDE even when I'm
 writing python for instance, and it annoys me that there's no
 IDE/debugger for embedded LUA.

 If by 'better' languages, you mean D, then I completely disagree. D
 *NEEDS* an IDE, just like all the rest... and in my opinion, even more
 so... here are some reasons I find it so annoying there isn't a quality
 VS integration for D (yet):
    ** auto is used liberally in D... I should be able to hover over any
 variable and have a tool tip inform me what it actually is (this makes
 it more important that D has an IDE than even C/C++)
    ** I don't have years of experience with the libraries, I SHOULD be
 able to press '.' and have a list of everything the library can do
 appear instantly without wasting my time trawling through the docs.
    * I shouldn't have to guess or try and remember the name of some
 member or method... I should be able to type the first 1-2 letters, and
 have the rest of the word will appear instantly.
    * If I don't know what a type is, or want to know about it in more
 detail, I should be able to press F1 and see documentation about the
 class/function/whatever instantly.
    * I'm new to the syntax, and it's terribly nice when a little red
 underline appears beneath a syntax error I've just created.
    * As projects grow, things like auto-refactor save sooo much time.
 Extremely difficult to implement reliably for C/C++, but should work
 perfectly in D...


 it's just sooooo fucking productive, and that's not thanks to the

 special power is actually it's VS integration.

 language), I opened VS, and started typing... thanks to the integration,
 the language was self-documenting and self-evident. I felt immediately
 productive in a language I hadn't even read a word about, and after a
 little more experience, I love its efficiency for writing the kind of
 code it's great at, and I always feel amazingly productive. The
 experience is not limited, or even thanks to the language, it's the
 whole package.


 shouldn't need to KNOW a language, or basically anything about it to
 start using it immediately. The IDE (auto-popup-documentation, code
 completion, info tooltips, etc) is what gives me that experience.
 Assuming the rest of the language and libraries are designed
 intuitively, it works.

 The reason it matters so much to me...
 I suspect I could actually propose using D in the office for small
 tasks, tools, etc... everyone hates C++, it wouldn't be hard to convince
 them to give it a try.
 That said, If D doesn't have an IDE, or more specifically, VS
 integration, it's off the table. Period. In a multi-user project, where
 all users expect VS integration, I can't do without it.

 will be really impressed, and they'll keep coming back.
Jan 07 2012
prev sibling next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Manu" <turkeyman gmail.com> wrote in message 
news:mailman.164.1325940038.16222.digitalmars-d puremagic.com...

 What would you propose I try to convince me that VS is shit and
 unproductive?


You're twisting my words around. That's not what I said.


 If you're going to talk about bloated heavy-weight IDE's, have you every
 tried using Eclipse? What a joke! How is it that so many years of OSS dev
 and Google backing it can produce such a bloated, crap, slow, 
 inconsistent,
 unfocused/unintegrated tool?!


Honestly, I always found all of the VS.NETs after 2003 to be just as bloated 
as Eclipse. Although given a choice, I admit I'd still use it over Eclipse 
since I find Eclipse painfully Java-centric when using it for non-JVM 
languages.


 How about XCode? I don't understand how anyone gets any work done with
 XCode, it is just soooo crap.


I had some brief experience with...shoot, I forget what it was called, but 
it was the immediate predecessor to XCode, the one in 10.2. I think it was 
something generic-sounding like "Project Builder" or something. It got the 
job done, but yea, I was never a fan of it.


 Overrated? I don't think calling industry standards overrated is a
 reasonable claim. they're industry standards because everyone uses them...
 and everyone uses them because they are industry standards.

 for
 tools recently. I hate C++! (that's why I'm here!).. I don't hype it up
 like it's awesome, but I use it because it's industry standard, there is 
 no
 viable alternative, and even if there were, it would NEED integration with
 all my tools before I could use it professionally in a full production
 environment.


So...you agree that it's widespread...and you hate it...Ok, I give up: 
Exactly how is that *not* "overrated"?


 If by 'better' languages, you mean D, then I completely disagree. D 
 *NEEDS*
 an IDE, just like all the rest... and in my opinion, even more so... here
 are some reasons I find it so annoying there isn't a quality VS 
 integration
 for D (yet):
  ** auto is used liberally in D... I should be able to hover over any
 variable and have a tool tip inform me what it actually is (this makes it
 more important that D has an IDE than even C/C++)
  ** I don't have years of experience with the libraries, I SHOULD be able
 to press '.' and have a list of everything the library can do appear
 instantly without wasting my time trawling through the docs.
  * I shouldn't have to guess or try and remember the name of some member
 or method... I should be able to type the first 1-2 letters, and have the
 rest of the word will appear instantly.
  * If I don't know what a type is, or want to know about it in more
 detail, I should be able to press F1 and see documentation about the
 class/function/whatever instantly.
  * I'm new to the syntax, and it's terribly nice when a little red
 underline appears beneath a syntax error I've just created.
  * As projects grow, things like auto-refactor save sooo much time.
 Extremely difficult to implement reliably for C/C++, but should work
 perfectly in D...


I like all those features too. But I've learned that I like responsive 
editors and great langauges even *more*. Like I said, if you're familiar 
with both sides and still prefer big IDE's, fine. That's just personal 
taste, I've got no problems with that. But I tend to get the impression that 
there are a lot of "professionals" out there who would completely and 
immediately shun a language based *purely* on a lack of full integration 
with VS. Actually, I think you're one of the people who have pretty much 
told me exactly that, that there are many such professionals who would do 
that.



 it's
 just sooooo fucking productive, and that's not thanks to the language its

 actually it's VS integration.

 I
 opened VS, and started typing... thanks to the integration, the language
 was self-documenting and self-evident. I felt immediately productive in a
 language I hadn't even read a word about, and after a little more
 experience, I love its efficiency for writing the kind of code it's great
 at, and I always feel amazingly productive. The experience is not limited,
 or even thanks to the language, it's the whole package.





(Try making a basic, let alone realistically useful, set of generic 
functional tools! Without at least an IArithmetic, it's not realistically 
possible. Or do a simple reinterpret cast without diving into dark corners 

in fighting the damn compiler. But at the same time, D just kept feeling 
more and more natural - even without a fancy IDE.

So, based on personal experience, I tend to call "bullshit" on the idea that 

the very basic UI controls and don't do a lot under the hood. And ok, maybe 
it's highly productive compared to C++, but that sure as hell isn't saying 
much.

Honest to god, I'm *more* productive with D and Programmer's Notepad 2 than 

coding, anyway ;)) But I never would have discovered that if I had been an 
IDE-snob. Obviously you're not one, as you pointed out you've at least tried 
things the other way, too. But from what you describe, it appears that a lot 
of people in the industry *are* staunch IDE-snobs.


 That said, If D doesn't have an IDE, or more specifically, VS integration,
 it's off the table. Period. In a multi-user project, where all users 
 expect
 VS integration, I can't do without it.

 be really impressed, and they'll keep coming back.


FWIW, I have always agreed that it's good for D to have good IDE integration 
because, like you've been saying, there are people who prefer it. And heck, 
once in a while I find it useful too, so I fire it up...wait a while...do 
what I need to do...slowly..., and then go back to my usual setup.
Jan 07 2012
next sibling parent reply Manu <turkeyman gmail.com> writes:
Just for the record, my post was intentionally excessively inflammatory. I
do like a good IDE vs non-IDE debate! :P

On 7 January 2012 22:22, Nick Sabalausky <a a.a> wrote:


 So...you agree that it's widespread...and you hate it...Ok, I give up:
 Exactly how is that *not* "overrated"?


In that, I don't think most people would rate it 10/10 :)
I'll give it maybe... 7/10. I mean, it's pretty good. It's universally
accepted, definitely stood the test of time, and produced much of the
worlds best software.
But it's old and outdated, refuses to respond to modern updates/requests in
reasonable time, and a lot of modern features they EVENTUALLY put in there
just don't address concerns that, at least my circle of developers, care
about.
Also they tend to just bloat the already bloated as hell standard library!

...and I think most people agree. So no, I don't think it's overrated, I
think it's quite fairly rated :P

But I tend to get the impression that

 there are a lot of "professionals" out there who would completely and
 immediately shun a language based *purely* on a lack of full integration
 with VS. Actually, I think you're one of the people who have pretty much
 told me exactly that, that there are many such professionals who would do
 that.


Yup, and I believe that's completely true :)
I expect a huge surge of developers will appear the moment a quality VS
integration exists.





 (Try making a basic, let alone realistically useful, set of generic
 functional tools! Without at least an IArithmetic, it's not realistically
 possible. Or do a simple reinterpret cast without diving into dark corners

 in fighting the damn compiler. But at the same time, D just kept feeling
 more and more natural - even without a fancy IDE.


Well I'm certainly not sharing that feeling, at least not yet. I'd like to
think it might get there though with some more time...

So, based on personal experience, I tend to call "bullshit" on the idea that


 the very basic UI controls and don't do a lot under the hood. And ok, maybe
 it's highly productive compared to C++, but that sure as hell isn't saying
 much.


I'm sure you've got more experience than me in this area.. All I've ever

The experience was always elegant and enjoyable. My only complaint is that
I created them so much faster than I expected... then I was finished, and
had to get back on to C/C++ work again :(

Honest to god, I'm *more* productive with D and Programmer's Notepad 2 than


 actually
 coding, anyway ;)) But I never would have discovered that if I had been an
 IDE-snob. Obviously you're not one, as you pointed out you've at least
 tried
 things the other way, too. But from what you describe, it appears that a
 lot
 of people in the industry *are* staunch IDE-snobs.


Well you're obviously weird ;)

Oh I'm definitely an IDE snob. I use all the other tools for cross platform
dev, automation, homebrew hobby work, etc, but I can't stand editing code
without a nice editor, the ability to hit ctrl-F7, and even debug,
instantly and seamlessly.
I go miles out of my way to integrate whatever toolchain I'm working with
into VS as best I can. The difference between me and most others like me
is, I go out of my way, whereas most other people, if said integration
doesn't already exist, will just give up and move with something else.

I will definitely admit though, VS2010 was a major step backwards..
Everything suddenly got all slow and buggy.
Infact, I do feel it's been going backwards since VS6... Although I think
2005 was a good year :)
2010 is the best VS yet though when it comes to custom workflow
integration, they are getting better at that, they're just ruining the rest
of the actual IDE in the mean time! >_<
Jan 07 2012
parent "Nick Sabalausky" <a a.a> writes:
"Manu" <turkeyman gmail.com> wrote in message 
news:mailman.174.1325975010.16222.digitalmars-d puremagic.com...

 Just for the record, my post was intentionally excessively inflammatory. I
 do like a good IDE vs non-IDE debate! :P


Heh, fair enough. Hell, it's not as if I'm not known for being overly 
inflammatory...


 On 7 January 2012 22:22, Nick Sabalausky <a a.a> wrote:


 So...you agree that it's widespread...and you hate it...Ok, I give up:
 Exactly how is that *not* "overrated"?


 ...and I think most people agree. So no, I don't think it's overrated, I
 think it's quite fairly rated :P


I see :) Guess I just chose the wrong word then ;)



 Yup, and I believe that's completely true :)
 I expect a huge surge of developers will appear the moment a quality VS
 integration exists.


Oh yea.


 I'm sure you've got more experience than me in this area.. All I've ever

 The experience was always elegant and enjoyable. My only complaint is that
 I created them so much faster than I expected... then I was finished, and
 had to get back on to C/C++ work again :(


Yea, it *is* nicer than C/C++ as long as you don't need to go too low-level 
or too high-level. That's why I had gotten into it in the first place. Sort 
of a middle-ground between C/C++ and Java.


 Honest to god, I'm *more* productive with D and Programmer's Notepad 2 
 than


 actually
 coding, anyway ;)) But I never would have discovered that if I had been 
 an
 IDE-snob. Obviously you're not one, as you pointed out you've at least
 tried
 things the other way, too. But from what you describe, it appears that a
 lot
 of people in the industry *are* staunch IDE-snobs.


 Well you're obviously weird ;)


Heh, I'm a weirdo in sooo many ways it's rediculous...


 Oh I'm definitely an IDE snob. I use all the other tools for cross 
 platform
 dev, automation, homebrew hobby work, etc, but I can't stand editing code
 without a nice editor, the ability to hit ctrl-F7, and even debug,
 instantly and seamlessly.
 I go miles out of my way to integrate whatever toolchain I'm working with
 into VS as best I can. The difference between me and most others like me
 is, I go out of my way, whereas most other people, if said integration
 doesn't already exist, will just give up and move with something else.


See, I used to do that [1]. But I guess instead of giving up and moving back 
to more established mainstream languages, I gave up and moved on to other 
editors and build methods.

[1] Actually, when I was doing GBA homebrew I even made a GBA AppWizard for 
MSVC 6: http://www.semitwist.com/gbadev/  I tried to make a VS.NET version 
(back with the original VS.NET), but I found the whole process to be 
confusing as hell, and the docs didn't seem to be much help.


 I will definitely admit though, VS2010 was a major step backwards..
 Everything suddenly got all slow and buggy.
 Infact, I do feel it's been going backwards since VS6... Although I think
 2005 was a good year :)


Heh. Different experiences. I first noticed VS starting to get slow with 
2003, but it wasn't enough to really turn me off yet, just annoy me 
(although the price tag every few years was getting to be a problem, 
especially since I wasn't much of a student anymore...Of course, this was 
before the Express editions). Then with 2005 I pretty much just gave up on 
VS for various reasons - speed, cost, lack of even basic D support, 
difficulty in extending it to do what I wanted, and just being a little bit 
too..."proprietary" and "inbred" are the only words I can think of for it, 
but "inbred" is more inflammatory than what I really mean and "proprietary" 
isn't exactly correct either...


 2010 is the best VS yet though when it comes to custom workflow
 integration, they are getting better at that, they're just ruining the 
 rest
 of the actual IDE in the mean time! >_<
Jan 07 2012
prev sibling parent "Martin Nowak" <dawg dawgfoto.de> writes:
On Sat, 07 Jan 2012 23:23:16 +0100, Manu <turkeyman gmail.com> wrote:


 Just for the record, my post was intentionally excessively inflammatory.  
 I
 do like a good IDE vs non-IDE debate! :P

 On 7 January 2012 22:22, Nick Sabalausky <a a.a> wrote:


Investing time to get familiar with emacs has been a huge win for me.
D with posix+emacs+gdb is on par with C++ and very productive IMHO.

martin
Jan 08 2012
prev sibling parent reply Jim Hewes <jimhewes gmail.com> writes:
On 1/7/2012 4:40 AM, Manu wrote:

 On 7 January 2012 08:40, Nick Sabalausky <a a.a> wrote:

 If by 'better' languages, you mean D, then I completely disagree. D
 *NEEDS* an IDE, just like all the rest... and in my opinion, even more
 so... here are some reasons I find it so annoying there isn't a quality
 VS integration for D (yet):



My job is primarily C++ Windows programming and I use Visual Studio. I 
think I agree with everything you said. In my case, I think of 
development tools as consisting of three components: (1) the language 
(2) the library/libraries including GUI, and (3) development 
environment, which includes debugger, IDE, etc. So even if the language 
is wonderful by itself, it's still not everything, and the total package 
may be less attractive than some other. I casually follow D progress 
because, besides just looking like a fun language to use, it seems to 
have all the elements that make a good language. But as you say, some 
things outside the language aren't quite there.


for that because of the IDE integration and also the .NET framework. The 

in the language is the lack of deterministic destruction, and that's one 
reason I'd favor D. (Also, having to get the .NET framework installed on 
users' systems is not so great, but not an issue just for internal 
tools. ) But the pros of IDE integration and .NET framework are greater 
to me than D language advantage. Visual D is helpful....but then there's 
the GUI library....

Not to get too far off topic, I'm the only one where I work who will use 


liking it. And that's seems to be the case where I work as far as I can 

integrated better with VS, I don't know. But there is always the issue 
with less widely used languages: if I write our company's main product 
in D, and if we then need to hire more people, I need to tell my boss we 
need to hire people that know D (or are at least willing and able pick 
it up) which are not as common. If anything at all goes wrong with D 
that wouldn't have gone wrong had we used C++, it's on me. No one ever 
got fired for buying IBM, lol. Sorry, I know we need to battle past that 
but I can't help mentioning it.
Jan 08 2012
parent Danni Coy <danni.coy gmail.com> writes:
 Not to get too far off topic, I'm the only one where I work who will use


 And that's seems to be the case where I work as far as I can tell. Maybe D

 with VS, I don't know. But there is always the issue with less widely used
 languages: if I write our company's main product in D, and if we then need
 to hire more people, I need to tell my boss we need to hire people that
 know D (or are at least willing and able pick it up) which are not as
 common. If anything at all goes wrong with D that wouldn't have gone wrong
 had we used C++, it's on me. No one ever got fired for buying IBM, lol.
 Sorry, I know we need to battle past that but I can't help mentioning it.


Not so much hate Microsoft as cautious of using platforms that contain a
lot of Microsoft IP. The thing about Microsoft is that it isn't really one

.net are probably totally cool there are other parts of of the company who
wouldn't hesitate to leverage that IP against anything they perceive to be

is a lot of Oracle IP to deal with (Microsoft currently pay Oracle a metric
f*cktonne of money per year to use that IP and I am not sure where
alternate .Net implementations stand in this regards). See Microsoft v
Google and Oracle v Google. This probably won't be an issue if you are
heavily microsoft centric in what you are doing anyways just not sure how
much I trust it as a cross platform solution in the long term.

Ideally D would allow you to write code that is in the same ballpark
performance wise as C/C++ but with much greater programmer productivity. I
don't think it's quite there yet. I think that IDE intergration including V
S is part of that, in fact I think it is something of a low hanging fruit.
Jan 08 2012
prev sibling next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Manu" <turkeyman gmail.com> wrote in message 
news:mailman.118.1325874486.16222.digitalmars-d puremagic.com...

 Okay, so I was trying to link to a C lib, and I realised... DMD doesn't
 support/produce VS compatible libs.
 I should have realised this sooner, noting the cv debuginfo.

 So like... WTF?

 How am I supposed to use DMD in Windows in anything other than trivial,
 self-contained programs?
 VisualC is the de facto standard in Windows. All libs are COFF, and 
 (unless
 I'm working with GCC) everything I want to link to is produced from VC.

 Let's also mention the debug info... Virtually every 3rd party tool 
 assumes
 and/or works best with PDB debug info. Being required to run cv2pdb is
 pretty lame.

 So... why no support for COFF libs, and PDB debug info?
 Surely at least a compiler option would do the business if there is some
 kinky attachment to CV and OMF :/

 I was hoping to start a project using D as a front end language 
 interacting
 with my C/C++ engine lib... but I can't.
 ... and now that I think if it... how do ANY programs built with DMD
 actually work? .. How does it link to system32.lib, user32.lib, etc?




The problem: On windows, DMD uses the Optlink linker. Optlink only supports 
OMF right now (OMF used to be commonly used by Borland, IIRC). Optlink was 
written entirely in asm so changing it is difficult. But Walter has been, 
piece-by-piece, porting it to C (and then he'll port it to D). (This is 
issue also happens to be the main thing blocking 64-bit on Windows.)

There are a few solutions right now (in no particular order):

- Recompile the libs using DMC (the Digital Mars C/C++ compiler). That will 
result in an OMF lib file that can be used with DMD.

- Link with Unilink instead of DMD/Optlink. Unilink can link both OMF and 
COFF together just fine. I don't have a link offhand, and it's a little 
funky to learn how to use since the docs aren't very good, but I'm sure 
someone here will chime in (or you can search the archives, I know comeone 
posted a good introduction to it not too long ago).

- Use the Digital Mars COFF2OMF tool to convert to lib to OMF. 
Unfortunately, the tool isn't free, but IIRC it's inexpensive.

- Use LDC or GDC instead of DMD. I think those work with COFF.

- If the library comes in a DLL version, you can download the free IMPLIB 
tool and use it to generate an OMF import library directly from the DLL 
(it'll still actually link to the DLL at runtime).

- Search/Ask around: Someone may have already created an OMF version of the 
lib.

The IMPLIB and COFF2OMF tools are here: 
http://www.digitalmars.com/download/freecompiler.html  IMPLIB is in the free 
"Basic Utilities" package, and COFF2OMF is in the "Extended Utilities 
Package"

If you feel this is all still a big pain in the ass: Don't worry, everyone 
here agrees with you, and the situation will not remain like this forever.
Jan 06 2012
next sibling parent reply Trass3r <un known.com> writes:
 The problem: On windows, DMD uses the Optlink linker. Optlink only  
 supports OMF right now (OMF used to be commonly used by Borland, IIRC).  
 Optlink was written entirely in asm so changing it is difficult. But  
 Walter has been,
 piece-by-piece, porting it to C (and then he'll port it to D).


I say get rid of that freakin' dinosaur. Pull requests are already piling  
up, we can't afford losing more time.


 (This is issue also happens to be the main thing blocking 64-bit on  
 Windows.)


Not quite true. You need 64Bit: object format, linker, librarian, debug  
info, compiler.


 - Recompile the libs using DMC (the Digital Mars C/C++ compiler). That  
 will result in an OMF lib file that can be used with DMD.


Did you ever try that?? You can't even mention that, let alone recommend  
it.


 - Use the Digital Mars COFF2OMF tool to convert to lib to OMF.
 Unfortunately, the tool isn't free, but IIRC it's inexpensive.


Doesn't matter. You already have to pay enough by having to deal with that  
OMF crap.


 If you feel this is all still a big pain in the ass: Don't worry,  
 everyone here agrees with you, and the situation will not remain like  
 this forever.


I'm sceptical.
Jan 06 2012
parent "Nick Sabalausky" <a a.a> writes:
"Trass3r" <un known.com> wrote in message news:op.v7ofwpwh3ncmek enigma...

 The problem: On windows, DMD uses the Optlink linker. Optlink only 
 supports OMF right now (OMF used to be commonly used by Borland, IIRC). 
 Optlink was written entirely in asm so changing it is difficult. But 
 Walter has been,
 piece-by-piece, porting it to C (and then he'll port it to D).


 I say get rid of that freakin' dinosaur. Pull requests are already piling 
 up, we can't afford losing more time.


I can't say I disagree :/  (So who's up for adding COFF support to DMD?)


 (This is issue also happens to be the main thing blocking 64-bit on 
 Windows.)


 Not quite true. You need 64Bit: object format, linker, librarian, debug 
 info, compiler.


Well, ok, *one of* the main things ;)


 - Recompile the libs using DMC (the Digital Mars C/C++ compiler). That 
 will result in an OMF lib file that can be used with DMD.


 Did you ever try that?? You can't even mention that, let alone recommend 
 it.


Depends on the lib really. DMC is a perfectly capable compiler as far as I 
can tell. It's just that some projects have fairly complex buildscripts that 
are fairly hardwired for MSVC and/or GCC. Anything with a sane buildsystem 
should be fine (though how common that is in C/C++-world, I can't say...).



 - Use the Digital Mars COFF2OMF tool to convert to lib to OMF.
 Unfortunately, the tool isn't free, but IIRC it's inexpensive.


 Doesn't matter. You already have to pay enough by having to deal with that 
 OMF crap.


Regardless, it *is* an option, so I listed it. I leave it up to others to 
decide if it's right for them.


 If you feel this is all still a big pain in the ass: Don't worry, 
 everyone here agrees with you, and the situation will not remain like 
 this forever.


 I'm sceptical.
Jan 06 2012
prev sibling next sibling parent reply Manu <turkeyman gmail.com> writes:
On 6 January 2012 21:06, Nick Sabalausky <a a.a> wrote:




 The problem: On windows, DMD uses the Optlink linker. Optlink only supports
 OMF right now (OMF used to be commonly used by Borland, IIRC). Optlink was
 written entirely in asm so changing it is difficult. But Walter has been,
 piece-by-piece, porting it to C (and then he'll port it to D). (This is
 issue also happens to be the main thing blocking 64-bit on Windows.)


Lame. Surely Optlink is not the only linker in the world...?
I'm also surprised that someone capable of writing a compiler and optimiser
for a complex language isn't capable of writing a linker. The link must
surely be the simplest+easiest of those 3 jobs...?



 There are a few solutions right now (in no particular order):

 - Recompile the libs using DMC (the Digital Mars C/C++ compiler). That will
 result in an OMF lib file that can be used with DMD.


DMx has inferior code generation, not a chance :) .. And does DMC even
support all the features of the language? SSE? No support in D, why would
it work in DMC?



 - Link with Unilink instead of DMD/Optlink. Unilink can link both OMF and
 COFF together just fine. I don't have a link offhand, and it's a little
 funky to learn how to use since the docs aren't very good, but I'm sure
 someone here will chime in (or you can search the archives, I know comeone
 posted a good introduction to it not too long ago).


Why not use this instead of Optlink if it works?
I'll check it out... though VisualD doesn't support this.



 - Use the Digital Mars COFF2OMF tool to convert to lib to OMF.
 Unfortunately, the tool isn't free, but IIRC it's inexpensive.


Seriously... I just simply won't bother, and write my app in C instead ;)



 - Use LDC or GDC instead of DMD. I think those work with COFF.


VisualD doesn't support those compilers (yet).

- If the library comes in a DLL version, you can download the free IMPLIB

 tool and use it to generate an OMF import library directly from the DLL
 (it'll still actually link to the DLL at runtime).


I could probably build my engine as a DLL... I've been planning to do this
for a long time anyway.
Maybe this is the extra bit of motivation I need to do it ;)



 The IMPLIB and COFF2OMF tools are here:
 http://www.digitalmars.com/download/freecompiler.html  IMPLIB is in the
 free
 "Basic Utilities" package, and COFF2OMF is in the "Extended Utilities
 Package"

 If you feel this is all still a big pain in the ass: Don't worry, everyone
 here agrees with you, and the situation will not remain like this forever.


Indeed. The main reason for my post is just to complain, and add my voice ;)
I'd like to insist that this is basically unacceptable... it should be
prioritised.
Jan 06 2012
next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Friday, 6 January 2012 at 19:20:35 UTC, Manu wrote:

 The link must
 surely be the simplest+easiest of those 3 jobs...?


The painful part is more getting dmd to output coff than
writing a linker (can always use a third party linker anyway).

Adding coff support is a bit of a mess and super tedious.


I've been thinking porting the coff outputter from something
like nasm might be a good strategy, but I haven't figured out
how to start that yet.
Jan 06 2012
prev sibling next sibling parent Trass3r <un known.com> writes:
 - Link with Unilink instead of DMD/Optlink.


 Why not use this instead of Optlink if it works?
 I'll check it out... though VisualD doesn't support this.


Cause its status is.. nebulous.
Closed-source, no homepage, just an ftp.
You have no guarantee it doesn't get abandoned one day.
Also what if there are blocking bugs and the author is away for some time?


 - Use the Digital Mars COFF2OMF tool to convert to lib to OMF.
 Unfortunately, the tool isn't free, but IIRC it's inexpensive.


 Seriously... I just simply won't bother, and write my app in C instead ;)


Exactly. That's what people will do/do/have already done.


 I could probably build my engine as a DLL... I've been planning to do  
 this for a long time anyway.
 Maybe this is the extra bit of motivation I need to do it ;)


Good practice anyway. Code should always be modular.
Jan 06 2012
prev sibling parent "Nick Sabalausky" <a a.a> writes:
"Manu" <turkeyman gmail.com> wrote in message 
news:mailman.126.1325877634.16222.digitalmars-d puremagic.com...

 Lame. Surely Optlink is not the only linker in the world...?
 I'm also surprised that someone capable of writing a compiler and 
 optimiser
 for a complex language isn't capable of writing a linker. The link must
 surely be the simplest+easiest of those 3 jobs...?


He (ie, Walter) *did* write Optlink, that's why DMD/Win uses it :/

(And OMF wasn't such a problem back when Optlink was written. AIUI, not 
being an expert in the matter myself, the decline of Borland seems to be one 
of the main reasons for OMF's demise.)


Why not use this instead of Optlink if it works?
I'll check it out... though VisualD doesn't support this.


...

 VisualD doesn't support those compilers (yet).


Yea, GDC and LDC were lagging pretty far behind until only fairly recently, 
and we didn't discover unilink until not real long ago either, so D many 
projects have been slow in supporting them. But yea, as a community we 
probably do need to make sure to start supporting them better.


 If you feel this is all still a big pain in the ass: Don't worry, 
 everyone
 here agrees with you, and the situation will not remain like this 
 forever.


 Indeed. The main reason for my post is just to complain, and add my voice 
 ;)
 I'd like to insist that this is basically unacceptable... it should be
 prioritised.


vote++
Jan 06 2012
prev sibling parent reply =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <xtzgzorex gmail.com> writes:
On 06-01-2012 20:06, Nick Sabalausky wrote:

 "Manu"<turkeyman gmail.com>  wrote in message
 news:mailman.118.1325874486.16222.digitalmars-d puremagic.com...

 Okay, so I was trying to link to a C lib, and I realised... DMD doesn't
 support/produce VS compatible libs.
 I should have realised this sooner, noting the cv debuginfo.

 So like... WTF?

 How am I supposed to use DMD in Windows in anything other than trivial,
 self-contained programs?
 VisualC is the de facto standard in Windows. All libs are COFF, and
 (unless
 I'm working with GCC) everything I want to link to is produced from VC.

 Let's also mention the debug info... Virtually every 3rd party tool
 assumes
 and/or works best with PDB debug info. Being required to run cv2pdb is
 pretty lame.

 So... why no support for COFF libs, and PDB debug info?
 Surely at least a compiler option would do the business if there is some
 kinky attachment to CV and OMF :/

 I was hoping to start a project using D as a front end language
 interacting
 with my C/C++ engine lib... but I can't.
 ... and now that I think if it... how do ANY programs built with DMD
 actually work? .. How does it link to system32.lib, user32.lib, etc?




 The problem: On windows, DMD uses the Optlink linker. Optlink only supports
 OMF right now (OMF used to be commonly used by Borland, IIRC). Optlink was
 written entirely in asm so changing it is difficult. But Walter has been,
 piece-by-piece, porting it to C (and then he'll port it to D). (This is
 issue also happens to be the main thing blocking 64-bit on Windows.)

 There are a few solutions right now (in no particular order):

 - Recompile the libs using DMC (the Digital Mars C/C++ compiler). That will
 result in an OMF lib file that can be used with DMD.

 - Link with Unilink instead of DMD/Optlink. Unilink can link both OMF and
 COFF together just fine. I don't have a link offhand, and it's a little
 funky to learn how to use since the docs aren't very good, but I'm sure
 someone here will chime in (or you can search the archives, I know comeone
 posted a good introduction to it not too long ago).

 - Use the Digital Mars COFF2OMF tool to convert to lib to OMF.
 Unfortunately, the tool isn't free, but IIRC it's inexpensive.


There is the free objconv tool: http://www.agner.org/optimize/


 - Use LDC or GDC instead of DMD. I think those work with COFF.

 - If the library comes in a DLL version, you can download the free IMPLIB
 tool and use it to generate an OMF import library directly from the DLL
 (it'll still actually link to the DLL at runtime).

 - Search/Ask around: Someone may have already created an OMF version of the
 lib.

 The IMPLIB and COFF2OMF tools are here:
 http://www.digitalmars.com/download/freecompiler.html  IMPLIB is in the free
 "Basic Utilities" package, and COFF2OMF is in the "Extended Utilities
 Package"

 If you feel this is all still a big pain in the ass: Don't worry, everyone
 here agrees with you, and the situation will not remain like this forever.



-- 
- Alex
Jan 06 2012
parent "Nick Sabalausky" <a a.a> writes:
"Alex Rønne Petersen" <xtzgzorex gmail.com> wrote in message 
news:je7v2g$22qv$1 digitalmars.com...

 There is the free objconv tool: http://www.agner.org/optimize/


Awesome! I'll definitely have to try that next time I need to use a C lib.
Jan 06 2012
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/6/2012 10:27 AM, Manu wrote:

 I was hoping to start a project using D as a front end language interacting
with
 my C/C++ engine lib... but I can't.
 ... and now that I think if it... how do ANY programs built with DMD actually
 work? .. How does it link to system32.lib, user32.lib, etc?


With DMD comes the various *.lib files converted to OMF format. Converting them 
is pretty simple.

Long term, I hope to get a better solution, but this is where we're at at the 
moment.
Jan 06 2012
parent reply Trass3r <un known.com> writes:
Am 06.01.2012, 20:26 Uhr, schrieb Walter Bright  
<newshound2 digitalmars.com>:

 Long term, I hope to get a better solution, but this is where we're at  
 at the moment.


What's the current state of the plan?
Can we hope for a switch to COFF?
Jan 06 2012
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/6/2012 11:37 AM, Trass3r wrote:

 Am 06.01.2012, 20:26 Uhr, schrieb Walter Bright <newshound2 digitalmars.com>:

 Long term, I hope to get a better solution, but this is where we're at at the
 moment.


 What's the current state of the plan?
 Can we hope for a switch to COFF?


My plan is to make the linker understand coff and so be able to pull in objects 
in any format. But that's a ways off.
Jan 06 2012
parent reply Jacob Carlborg <doob me.com> writes:
On 2012-01-07 06:11, Walter Bright wrote:

 On 1/6/2012 11:37 AM, Trass3r wrote:

 Am 06.01.2012, 20:26 Uhr, schrieb Walter Bright
 <newshound2 digitalmars.com>:

 Long term, I hope to get a better solution, but this is where we're
 at at the
 moment.


 What's the current state of the plan?
 Can we hope for a switch to COFF?


 My plan is to make the linker understand coff and so be able to pull in
 objects in any format. But that's a ways off.


Will dmd still produce OMF or will it be changed to produce COFF?

-- 
/Jacob Carlborg
Jan 07 2012
next sibling parent reply "Froglegs" <lugtug gmail.com> writes:
  A great IDE is essential for D to really succeed.

  Visual D is a solid start but it isn't really usable for a large 
project yet.

-  The debugging experience is funky, it can't seem to see many 
variables
-  hovering over variables generally doesn't show anything useful
-  hitting . doesn't pop up possible members
-  very limited syntax highlighting

  D might have simplified C++ syntax, but it is still quite 
complex, not having an IDE that supports the type of things that 
Visual Studio supports is just painful-- I doubt D has any chance 
in the game industry without much better VS support.

Aside from C++ I also use Lua quite often and even in a light 
weight scripting language like Lua I much prefer an 
IDE(Decoda--Manu it works with embedded scripts btw).
Jan 07 2012
next sibling parent =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
On 07-01-2012 19:43, Froglegs wrote:

 A great IDE is essential for D to really succeed.

 Visual D is a solid start but it isn't really usable for a large project
 yet.

 - The debugging experience is funky, it can't seem to see many variables
 - hovering over variables generally doesn't show anything useful
 - hitting . doesn't pop up possible members
 - very limited syntax highlighting


I strongly disagree. Visual D's syntax highlighting is currently the 
best available across all D editors, including Vim, Mono-D, Geany, 
KDevelop, etc.


 D might have simplified C++ syntax, but it is still quite complex, not
 having an IDE that supports the type of things that Visual Studio
 supports is just painful-- I doubt D has any chance in the game industry
 without much better VS support.

 Aside from C++ I also use Lua quite often and even in a light weight
 scripting language like Lua I much prefer an IDE(Decoda--Manu it works
 with embedded scripts btw).



-- 
- Alex
Jan 07 2012
prev sibling parent Manu <turkeyman gmail.com> writes:
On 7 January 2012 20:43, Froglegs <lugtug gmail.com> wrote:


 Aside from C++ I also use Lua quite often and even in a light weight
 scripting language like Lua I much prefer an IDE(Decoda--Manu it works with
 embedded scripts btw).


Cheers for the pro-tip! :)
Jan 07 2012
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/7/2012 6:00 AM, Jacob Carlborg wrote:

 Will dmd still produce OMF or will it be changed to produce COFF?


It will be irrelevant, as the linker will read whatever it puts out, and the 
linker will read COFF.

There is no reason why a linker cannot transparently read many object and 
library file formats. I even want the linker to be able to read a DLL and
figure 
out how to interface it without needing to build a corresponding import library.

There's quite a bit that can be done that was impractical for linkers of yore 
because of severe memory constraints.
Jan 07 2012
next sibling parent reply =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
On 08-01-2012 01:27, Walter Bright wrote:

 On 1/7/2012 6:00 AM, Jacob Carlborg wrote:

 Will dmd still produce OMF or will it be changed to produce COFF?


 It will be irrelevant, as the linker will read whatever it puts out, and
 the linker will read COFF.

 There is no reason why a linker cannot transparently read many object
 and library file formats. I even want the linker to be able to read a
 DLL and figure out how to interface it without needing to build a
 corresponding import library.

 There's quite a bit that can be done that was impractical for linkers of
 yore because of severe memory constraints.


Does the OMF format actually support 64-bit? If not, we're bound to need 
COFF eventually.

-- 
- Alex
Jan 08 2012
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/8/2012 3:02 AM, Alex Rønne Petersen wrote:

 Does the OMF format actually support 64-bit?


Nope.


 If not, we're bound to need COFF eventually.


Probably. Or elf.
Jan 08 2012
parent Manu <turkeyman gmail.com> writes:
On 8 January 2012 21:49, Walter Bright <newshound2 digitalmars.com> wrote:


 On 1/8/2012 3:02 AM, Alex R=C3=B8nne Petersen wrote:


 If not, we're bound to need COFF eventually.



 Probably. Or elf.


Elf? Don't be silly. Windows needs COFF. I should be able to use the visual
studio linker.
Jan 08 2012
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
On 8 January 2012 02:27, Walter Bright <newshound2 digitalmars.com> wrote:


 On 1/7/2012 6:00 AM, Jacob Carlborg wrote:


 Will dmd still produce OMF or will it be changed to produce COFF?


 It will be irrelevant, as the linker will read whatever it puts out, and
 the linker will read COFF.

 There is no reason why a linker cannot transparently read many object and
 library file formats. I even want the linker to be able to read a DLL and
 figure out how to interface it without needing to build a corresponding
 import library.

 There's quite a bit that can be done that was impractical for linkers of
 yore because of severe memory constraints.


I'd quite like to use the VisualC linker... so I hope this isn't a
substitute for implementing COFF output to the compiler at some point.
Jan 08 2012
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-01-08 01:27, Walter Bright wrote:

 On 1/7/2012 6:00 AM, Jacob Carlborg wrote:

 Will dmd still produce OMF or will it be changed to produce COFF?


 It will be irrelevant, as the linker will read whatever it puts out, and
 the linker will read COFF.

 There is no reason why a linker cannot transparently read many object
 and library file formats. I even want the linker to be able to read a
 DLL and figure out how to interface it without needing to build a
 corresponding import library.

 There's quite a bit that can be done that was impractical for linkers of
 yore because of severe memory constraints.


I see, thanks for the explanation.

-- 
/Jacob Carlborg
Jan 08 2012
prev sibling next sibling parent reply "Trass3r" <un known.com> writes:
On Sunday, 8 January 2012 at 00:27:46 UTC, Walter Bright wrote:

 On 1/7/2012 6:00 AM, Jacob Carlborg wrote:

 Will dmd still produce OMF or will it be changed to produce 
 COFF?


 It will be irrelevant, as the linker will read whatever it puts 
 out, and the linker will read COFF.

 There is no reason why a linker cannot transparently read many 
 object and library file formats. I even want the linker to be 
 able to read a DLL and figure out how to interface it without 
 needing to build a corresponding import library.

 There's quite a bit that can be done that was impractical for 
 linkers of yore because of severe memory constraints.


Yet you are the only one who can maintain optlink, just as you 
are the only one who can process pull requests. The latter is 
much more important, especially since there already are stable 
alternative linkers with more features.

e.g. https://github.com/D-Programming-Language/dmd/pull/375 fixes 
severe bugs with postblits/destructors and has been open for 4 
months already without any comment from your side. We have to 
live with the fact that bugs are fixed somewhat randomly (i.e. 
the bugzilla voting system is completely ignored), but it isn't 
acceptable that we have to deal with bugs that have been fixed 
months ago but just not merged yet. Bug 314 is a prime example 
for all of that (most voted bug for years, fixed in ldc long ago, 
pull request was open for ages).
Also the dmd code needs improvement. It should leverage C++11 
features, become more modular and code quality needs to be 
improved. For example the typed Array was long overdue, yet 
people still use that crappy tdata() syntax instead of just []. 
The C++11 range based for loop would be a logical next step for 
that. Other things that come to my mind are replacing hard-coded 
values with proper constants, introducing smart pointers so at 
least some memory is released and better (documentation) comments.
Jan 08 2012
next sibling parent reply Peter Alexander <peter.alexander.au gmail.com> writes:
On 8/01/12 2:14 PM, Trass3r wrote:

 Also the dmd code needs improvement. It should leverage C++11 features,
 become more modular and code quality needs to be improved. For example
 the typed Array was long overdue, yet people still use that crappy
 tdata() syntax instead of just []. The C++11 range based for loop would
 be a logical next step for that. Other things that come to my mind are
 replacing hard-coded values with proper constants, introducing smart
 pointers so at least some memory is released and better (documentation)
 comments.


It's still far too early to start using C++11 stuff because not all 
compilers support it. OSX still ships with g++ 4.2. Expecting people to 
install a new compiler just to compile the DMD code is a pointless 
barrier. Especially if the only reason for using C++11 is relatively 
minor syntactic changes.

Smart pointers (especially shared_ptr) are not free. They will make DMD 
slower, compile more slowly, and bloat the syntax (T* vs. 
std::shared_ptr<T>). It is also a very large change to change most 
pointers to smart pointers. Any mistakes made in the transition will 
cause bugs.

All this stuff you have proposed requires time. Time is precious. What 
do you propose should be delayed so that this work could be carried out?
Jan 08 2012
parent reply "Trass3r" <un known.com> writes:
On Sunday, 8 January 2012 at 14:39:59 UTC, Peter Alexander wrote:

 It's still far too early to start using C++11 stuff because not 
 all compilers support it. OSX still ships with g++ 4.2. 
 Expecting people to install a new compiler just to compile the 
 DMD code is a pointless barrier. Especially if the only reason 
 for using C++11 is relatively minor syntactic changes.


Usage can be restricted to those features that are well supported.
Apple switched to Clang.


 Smart pointers (especially shared_ptr) are not free. They will 
 make DMD slower, compile more slowly, and bloat the syntax (T* 
 vs. std::shared_ptr<T>).


IIRC Clang uses them all over the place and they did carefully 
design everything for speed and memory efficiency.


 All this stuff you have proposed requires time. Time is 
 precious. What do you propose should be delayed so that this 
 work could be carried out?


I didn't say it has to happen today. But it should be a goal.
Investing precious time in an old linker instead of just putting 
out COFF and using existing alternative ones isn't the right path.
Jan 08 2012
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/8/2012 7:06 AM, Trass3r wrote:

 IIRC Clang uses them all over the place and they did carefully design
everything
 for speed and memory efficiency.


Clang is a lot slower at compiling than dmc.
Jan 08 2012
parent reply Trass3r <un known.com> writes:
 Clang is a lot slower at compiling than dmc.


With or without optimizations?
Would be interesting to see detailed comparisons lexing/parsing/... like  
http://clang.llvm.org/performance.html
Jan 08 2012
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/8/2012 12:35 PM, Trass3r wrote:

 Clang is a lot slower at compiling than dmc.


 With or without optimizations?


http://biolpc22.york.ac.uk/wx/wxhatch/wxMSW_Compiler_choice.html



 Would be interesting to see detailed comparisons lexing/parsing/... like
 http://clang.llvm.org/performance.html


Being faster than gcc isn't a great trick.
Jan 08 2012
parent reply "Trass3r" <un known.com> writes:
On Sunday, 8 January 2012 at 22:50:07 UTC, Walter Bright wrote:

 Would be interesting to see detailed comparisons 
 lexing/parsing/... like
 http://clang.llvm.org/performance.html


 Being faster than gcc isn't a great trick.


I didn't claim the opposite.
I was curious why dmc is faster.
Jan 08 2012
parent Walter Bright <newshound2 digitalmars.com> writes:
On 1/8/2012 2:58 PM, Trass3r wrote:

 I was curious why dmc is faster.


Many hours with the profiler!
Jan 08 2012
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/8/2012 6:14 AM, Trass3r wrote:

 e.g. https://github.com/D-Programming-Language/dmd/pull/375 fixes severe bugs
 with postblits/destructors and has been open for 4 months already without any
 comment from your side.


Don knows what he's doing, and it's waiting for fixes to his observations. 
Meanwhile, there are a ton of other pull requests that are ready to go that
I've 
been pulling in steadily.


 We have to live with the fact that bugs are fixed
 somewhat randomly (i.e. the bugzilla voting system is completely ignored), but
 it isn't acceptable that we have to deal with bugs that have been fixed months
 ago but just not merged yet.


See my comment above.


 Bug 314 is a prime example for all of that (most
 voted bug for years, fixed in ldc long ago, pull request was open for ages).


That one has been pulled and merged.


 Also the dmd code needs improvement. It should leverage C++11 features, become
 more modular and code quality needs to be improved. For example the typed Array
 was long overdue, yet people still use that crappy tdata() syntax instead of
 just []. The C++11 range based for loop would be a logical next step for that.
 Other things that come to my mind are replacing hard-coded values with proper
 constants, introducing smart pointers so at least some memory is released and
 better (documentation) comments.


I'd like to use C++11 features in the dmd source, too. The downside is that all 
the C++ compilers on all the current and potential targets for D need to 
reliably support those C++11 features. Currently, this is not close to true,
and 
likely won't be for some time.

The minor benefit of those features is not worth arbitrarily shutting the door 
on some targets.
Jan 08 2012
next sibling parent reply "q66" <quaker66 gmail.com> writes:
By the way, Walter, I'm fixing druntime and Phobos makefiles 
after the Shared ELF merge so they can be built as shared libs (I 
have them working both now, on my FreeBSD box). I just wanna ask 
you, I think it would be a good idea to remove default phobos2 
linkage from dmd and move that to dmd.conf instead, as the 
phobos2 linkage comes after dmd.conf linkages and druntime has to 
be linked after phobos (I'd like them as separate libs). Do you 
think I can do that, or any other idea?
Jan 08 2012
next sibling parent reply "Martin Nowak" <dawg dawgfoto.de> writes:
Am 08.01.2012, 21:04 Uhr, schrieb q66 <quaker66 gmail.com>:


 By the way, Walter, I'm fixing druntime and Phobos makefiles after the  
 Shared ELF merge so they can be built as shared libs (I have them  
 working both now, on my FreeBSD box). I just wanna ask you, I think it  
 would be a good idea to remove default phobos2 linkage from dmd and move  
 that to dmd.conf instead, as the phobos2 linkage comes after dmd.conf  
 linkages and druntime has to be linked after phobos (I'd like them as  
 separate libs). Do you think I can do that, or any other idea?


I hope you know that shared libraries still don't work.
It needs runtime which is currently being merged.

There are ShareRuntime branches for dmd/druntime/phobos
https://github.com/dawgfoto
and I'd be glad have a cleaner Makefile solution than mine.
Jan 08 2012
parent reply "q66" <quaker66 gmail.com> writes:
On Sunday, 8 January 2012 at 21:10:21 UTC, Martin Nowak wrote:

 Am 08.01.2012, 21:04 Uhr, schrieb q66 <quaker66 gmail.com>:


 By the way, Walter, I'm fixing druntime and Phobos makefiles 
 after the Shared ELF merge so they can be built as shared libs 
 (I have them working both now, on my FreeBSD box). I just 
 wanna ask you, I think it would be a good idea to remove 
 default phobos2 linkage from dmd and move that to dmd.conf 
 instead, as the phobos2 linkage comes after dmd.conf linkages 
 and druntime has to be linked after phobos (I'd like them as 
 separate libs). Do you think I can do that, or any other idea?


 I hope you know that shared libraries still don't work.
 It needs runtime which is currently being merged.

 There are ShareRuntime branches for dmd/druntime/phobos
 https://github.com/dawgfoto
 and I'd be glad have a cleaner Makefile solution than mine.


don't work? I use git and they're working perfectly fine for me :)
Jan 08 2012
parent reply "Martin Nowak" <dawg dawgfoto.de> writes:
Am 08.01.2012, 22:14 Uhr, schrieb q66 <quaker66 gmail.com>:


 On Sunday, 8 January 2012 at 21:10:21 UTC, Martin Nowak wrote:

 Am 08.01.2012, 21:04 Uhr, schrieb q66 <quaker66 gmail.com>:


 By the way, Walter, I'm fixing druntime and Phobos makefiles after the  
 Shared ELF merge so they can be built as shared libs (I have them  
 working both now, on my FreeBSD box). I just wanna ask you, I think it  
 would be a good idea to remove default phobos2 linkage from dmd and  
 move that to dmd.conf instead, as the phobos2 linkage comes after  
 dmd.conf linkages and druntime has to be linked after phobos (I'd like  
 them as separate libs). Do you think I can do that, or any other idea?


 I hope you know that shared libraries still don't work.
 It needs runtime which is currently being merged.

 There are ShareRuntime branches for dmd/druntime/phobos
 https://github.com/dawgfoto
 and I'd be glad have a cleaner Makefile solution than mine.


 don't work? I use git and they're working perfectly fine for me :)


No EH, no static/TLS GC roots from shared libraries.
Jan 08 2012
parent Walter Bright <newshound2 digitalmars.com> writes:
On 1/8/2012 1:51 PM, Martin Nowak wrote:

 No EH, no static/TLS GC roots from shared libraries.


Also, calling the runtime helper functions, like ulong division, is broken for 
shared because it doesn't set EBX. (Or maybe that doesn't matter since those 
functions don't access static data? Not sure.)
Jan 08 2012
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/8/2012 12:04 PM, q66 wrote:

 By the way, Walter, I'm fixing druntime and Phobos makefiles after the Shared
 ELF merge so they can be built as shared libs (I have them working both now, on
 my FreeBSD box). I just wanna ask you, I think it would be a good idea to
remove
 default phobos2 linkage from dmd and move that to dmd.conf instead, as the
 phobos2 linkage comes after dmd.conf linkages and druntime has to be linked
 after phobos (I'd like them as separate libs). Do you think I can do that, or
 any other idea?


Once Phobos works as a shared lib, I think we should switch to that as the
default.
Jan 08 2012
parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Sunday, 8 January 2012 at 22:52:17 UTC, Walter Bright wrote:

 Once Phobos works as a shared lib, I think we should switch to 
 that as the default.


Please, no. That would mean standalone executables won't work
by default.
Jan 08 2012
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/8/2012 3:12 PM, Adam D. Ruppe wrote:

 On Sunday, 8 January 2012 at 22:52:17 UTC, Walter Bright wrote:

 Once Phobos works as a shared lib, I think we should switch to that as the
 default.


 Please, no. That would mean standalone executables won't work
 by default.


People who distribute apps will be more sophisticated users, and will be able
to 
set a flag to static link.

I guarantee you that shared should be the default, as otherwise newbies will 
compile with D and:

    "Zo-mah-gawd, look at the size of those D executables! D sux!"

Which happens now. Note that the default with gcc is to link with the shared C 
runtime, and it will be expected for dmd.
Jan 08 2012
parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Monday, 9 January 2012 at 00:32:51 UTC, Walter Bright wrote:

   "Zo-mah-gawd, look at the size of those D executables! D sux!"

 Which happens now.


My problem with this is a shared lib actually *increases*
the size. At best, it fools you by separating it out into
two or three files instead of one.

A better solution to the executable size problem is to
actually make them smaller, like Andrei was doing a couple
weeks ago. He made a huge difference just by changing a
handful of lines to reduce unnecessary coupling in Phobos.


 Note that the default with gcc is to link with the shared C 
 runtime, and it will be expected for dmd.


The big difference there is people usually already have the
C runtime and use it for many programs. They don't actually
have to think about installing it.

Imagine how many people, especially on Linux, will now
start asking "I built a D program, but when I run it, it
complains that it can't find libphobos2.so", or the already
somewhat common version mismatches that happen when you update
one but not the other.


Would you rather have someone complaining about a 200 kb
executable, on an executable that doesn't work right without
end user action?
Jan 08 2012
next sibling parent reply "Martin Nowak" <dawg dawgfoto.de> writes:
Am 09.01.2012, 04:59 Uhr, schrieb Adam D. Ruppe  
<destructionator gmail.com>:


 On Monday, 9 January 2012 at 00:32:51 UTC, Walter Bright wrote:

   "Zo-mah-gawd, look at the size of those D executables! D sux!"

 Which happens now.


 My problem with this is a shared lib actually *increases*
 the size. At best, it fools you by separating it out into
 two or three files instead of one.

 A better solution to the executable size problem is to
 actually make them smaller, like Andrei was doing a couple
 weeks ago. He made a huge difference just by changing a
 handful of lines to reduce unnecessary coupling in Phobos.


 Note that the default with gcc is to link with the shared C runtime,  
 and it will be expected for dmd.


 The big difference there is people usually already have the
 C runtime and use it for many programs. They don't actually
 have to think about installing it.

 Imagine how many people, especially on Linux, will now
 start asking "I built a D program, but when I run it, it
 complains that it can't find libphobos2.so", or the already
 somewhat common version mismatches that happen when you update
 one but not the other.


 Would you rather have someone complaining about a 200 kb
 executable, on an executable that doesn't work right without
 end user action?


We will have to install the libraries into a sensible place by default.
Also multiple processes using the same shared library will benefit from
memory savings.
Jan 08 2012
parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Monday, 9 January 2012 at 04:54:45 UTC, Martin Nowak wrote:

 We will have to install the libraries into a sensible place by 
 default.


Right now, you can just unzip it and go. Are we going
to break that too?



 Also multiple processes using the same shared library will 
 benefit from memory savings.


We're talking maybe, MAYBE, one megabyte here.
Jan 08 2012
prev sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Adam D. Ruppe" <destructionator gmail.com> wrote in message 
news:oftpypayqrnhjqkmwthk dfeed.kimsufi.thecybershadow.net...

 On Monday, 9 January 2012 at 00:32:51 UTC, Walter Bright wrote:

   "Zo-mah-gawd, look at the size of those D executables! D sux!"

 Which happens now.


 My problem with this is a shared lib actually *increases*
 the size. At best, it fools you by separating it out into
 two or three files instead of one.

 A better solution to the executable size problem is to
 actually make them smaller, like Andrei was doing a couple
 weeks ago. He made a huge difference just by changing a
 handful of lines to reduce unnecessary coupling in Phobos.


 Note that the default with gcc is to link with the shared C runtime, and 
 it will be expected for dmd.


 The big difference there is people usually already have the
 C runtime and use it for many programs. They don't actually
 have to think about installing it.

 Imagine how many people, especially on Linux, will now
 start asking "I built a D program, but when I run it, it
 complains that it can't find libphobos2.so", or the already
 somewhat common version mismatches that happen when you update
 one but not the other.


 Would you rather have someone complaining about a 200 kb
 executable, on an executable that doesn't work right without
 end user action?


Absolutely agree 100%.

Besides, "1MB Hello Word?!?" is just moronic whining. Christ, I'm on a 
32-bit single-core with 2GB ram, I bitch about software bloat constantly, 
and yet even **I** don't give half a shit about it, and even I'm not 
*remotely* inconvenienced by trivial apps being a few hundred k, or even a 
few M, too large. WTF does it matter? Those people are just trying to find 
bullshit to moan about. Fix that and they'll find some reason to whine about 
underscores in numeric literals.

Additionally, Phobos is different with every release. Are we seriously going 
to expect D users, and worse - the end-users of D-made software, to have 
their system cluttered with libphobos2-065.so, libphobos2-066.so, 
libphobos2-067.so, etc. Or are we going to pretend that issue doesn't exist 
and create our own little DDLL hell? (And on top of that: "Why do I have 
hundreds of megs worth of this damn libphobos?") Even if dynamic phobos does 
become default at some point, *at the very least*, it shouldn't be until 
Phobos stabalizes. Realistically, it shouldn't be until libphobos is stable 
*and* about as common as libc.
Jan 08 2012
parent reply Trass3r <un known.com> writes:
 Realistically, it shouldn't be until libphobos is stable *and* about as  
 common as libc.


Exactly. It doesn't make any sense as long as there's a new version every  
month.
We should do something about dead code elimination though.
-ffunction-sections -fdata-sections -L--gc-sections greatly reduces the  
size with gdc, but you can't expect users to always pass that.
Jan 09 2012
parent reply Manu <turkeyman gmail.com> writes:
On 9 January 2012 15:14, Trass3r <un known.com> wrote:


 Realistically, it shouldn't be until libphobos is stable *and* about as

 common as libc.


 Exactly. It doesn't make any sense as long as there's a new version every
 month.
 We should do something about dead code elimination though.
 -ffunction-sections -fdata-sections -L--gc-sections greatly reduces the
 size with gdc, but you can't expect users to always pass that.


static this() seems to be a problem. Unless there's powerful
whole-program-optimisation, how can it strip out any data that might be
initialised/touched in static this()?

Why wouldn't dead code be eliminated effectively already?
Jan 09 2012
parent reply Trass3r <un known.com> writes:
 static this() seems to be a problem. Unless there's powerful
 whole-program-optimisation, how can it strip out any data that might be
 initialised/touched in static this()?


It probably can't.


 Why wouldn't dead code be eliminated effectively already?


Cause 1 section is created for each module. So if you use just 1 function  
the whole module is pulled in.
Jan 09 2012
parent reply Manu <turkeyman gmail.com> writes:
On 9 January 2012 15:27, Trass3r <un known.com> wrote:


 static this() seems to be a problem. Unless there's powerful

 whole-program-optimisation, how can it strip out any data that might be
 initialised/touched in static this()?


 It probably can't.



I'm sure it's possible, but it would need some pretty powerful global
expression analysis.
Ie, if data initialised in static this() is only touched in one function
lets say, and that function is never referenced, then it should surely be
able to safely eliminate that function and associated data?

Why wouldn't dead code be eliminated effectively already?


 Cause 1 section is created for each module. So if you use just 1 function
 the whole module is pulled in.


Why would it pull the whole module if only one function is used? And why
can't a post-link strip process clean it up?



 Jan 09 2012



  parent  "Trass3r" <un known.com>  writes:


 I'm sure it's possible, but it would need some pretty powerful 
 global expression analysis.
 Ie, if data initialised in static this() is only touched in one 
 function
 lets say, and that function is never referenced, then it should 
 surely be
 able to safely eliminate that function and associated data?


You need LTO for that.


 Why would it pull the whole module if only one function is used?


http://elinux.org/Function_sections


 And why can't a post-link strip process clean it up?


Everything's already merged by then.



 Jan 09 2012



prev sibling  parent reply Trass3r <un known.com>  writes:


Am 08.01.2012, 20:59 Uhr, schrieb Walter Bright  
<newshound2 digitalmars.com>:


 On 1/8/2012 6:14 AM, Trass3r wrote:

 e.g. https://github.com/D-Programming-Language/dmd/pull/375 fixes  
 severe bugs
 with postblits/destructors and has been open for 4 months already  
 without any
 comment from your side.


 Don knows what he's doing, and it's waiting for fixes to his  
 observations.


You should have posted there that you are waiting for this.
As I understand it Kenji has fixed some stuff that Don mentioned, but  
won't do anything about the points that are optimizations rather than  
fixes soon.
So wouldn't it be better to pull now?


 I'd like to use C++11 features in the dmd source, too. The downside is  
 that all the C++ compilers on all the current and potential targets for  
 D need to reliably support those C++11 features. Currently, this is not  
 close to true, and likely won't be for some time.


I thought even dmc supports a few features.
Which one doesn't implement C++11 at all?



 Jan 08 2012



  parent  Walter Bright <newshound2 digitalmars.com>  writes:


On 1/8/2012 12:31 PM, Trass3r wrote:

 I thought even dmc supports a few features.
 Which one doesn't implement C++11 at all?


Each compiler does a different set of C++11 features, and it changes regularly.

It's just not a good idea now. The agony of #ifdef'ing around compiler problems 
is not going to make the code cleaner.



 Jan 08 2012



prev sibling  parent reply "q66" <quaker66 gmail.com>  writes:


On Sunday, 8 January 2012 at 00:27:46 UTC, Walter Bright wrote:

 On 1/7/2012 6:00 AM, Jacob Carlborg wrote:

 Will dmd still produce OMF or will it be changed to produce 
 COFF?


 It will be irrelevant, as the linker will read whatever it puts 
 out, and the linker will read COFF.

 There is no reason why a linker cannot transparently read many 
 object and library file formats. I even want the linker to be 
 able to read a DLL and figure out how to interface it without 
 needing to build a corresponding import library.

 There's quite a bit that can be done that was impractical for 
 linkers of yore because of severe memory constraints.


It certainly won't be irrelevant, as people will want to produce 
libraries with dmd too, and other toolchains have to be able to 
read them.



 Jan 08 2012



  parent  Trass3r <un known.com>  writes:


Am 08.01.2012, 20:58 Uhr, schrieb q66 <quaker66 gmail.com>:


 On Sunday, 8 January 2012 at 00:27:46 UTC, Walter Bright wrote:

 On 1/7/2012 6:00 AM, Jacob Carlborg wrote:

 Will dmd still produce OMF or will it be changed to produce COFF?


 It will be irrelevant, as the linker will read whatever it puts out,  
 and the linker will read COFF.


 It certainly won't be irrelevant, as people will want to produce  
 libraries with dmd too, and other toolchains have to be able to read  
 them.


Good point.



 Jan 08 2012



prev sibling  parent reply "Adam Wilson" <flyboynw gmail.com>  writes:


On Fri, 06 Jan 2012 10:27:58 -0800, Manu <turkeyman gmail.com> wrote:


 Okay, so I was trying to link to a C lib, and I realised... DMD doesn't
 support/produce VS compatible libs.
 I should have realised this sooner, noting the cv debuginfo.

 So like... WTF?

 How am I supposed to use DMD in Windows in anything other than trivial,
 self-contained programs?
 VisualC is the de facto standard in Windows. All libs are COFF, and  
 (unless
 I'm working with GCC) everything I want to link to is produced from VC.

 Let's also mention the debug info... Virtually every 3rd party tool  
 assumes
 and/or works best with PDB debug info. Being required to run cv2pdb is
 pretty lame.

 So... why no support for COFF libs, and PDB debug info?
 Surely at least a compiler option would do the business if there is some
 kinky attachment to CV and OMF :/

 I was hoping to start a project using D as a front end language  
 interacting
 with my C/C++ engine lib... but I can't.
 ... and now that I think if it... how do ANY programs built with DMD
 actually work? .. How does it link to system32.lib, user32.lib, etc?


DMD on Linux gets ELF with x64 support.
DMD on OSX gets Mach-O with x64 support.
DMD on Windows gets ... OMF with no x64 support.

COFF is an absolute requirements when working on Windows, yet DMD doesn't  
support it. Everything, every programming interface, every application  
running on x64 Windows is built with COFF, the default output of every  
other compiler on Windows is COFF, everyone else programming on Windows is  
expecting COFF.
Windows represents the largest OS install base in the world; and yet,  
Windows based D programmers are told that they have to dig up extremely  
esoteric tools from the darkest, smelliest, most cobwebbed corners of the  
Internet, just to be able to interact with the the rest of the Windows  
world.

This situation is simply unacceptable.

Everything else on Windows is COFF, if DMD ever wants to be accepted as a  
mainstream Windows development tool, it simply *MUST* support COFF. And no  
amount of wishing will ever change this. Without COFF, D will ALWAYS be  
hamstrung on Windows, even if OMF ever got x64 support. Every other  
platform that DMD supports got their native object formats. It is now time  
to get the native Windows format in D.

All DMD needs to do is output the COFF files, any number of linkers  
available on Windows can handle it from there. It doesn't have to replace  
OMF and it doesn't even have to be the default option, but it absolutely  
MUST be AN option.

-- 
Adam Wilson
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/



 Jan 06 2012



 next sibling parent  "q66" <quaker66 gmail.com>  writes:


On Friday, 6 January 2012 at 20:03:01 UTC, Adam Wilson wrote:

 On Fri, 06 Jan 2012 10:27:58 -0800, Manu <turkeyman gmail.com> 
 wrote:


 Okay, so I was trying to link to a C lib, and I realised... 
 DMD doesn't
 support/produce VS compatible libs.
 I should have realised this sooner, noting the cv debuginfo.

 So like... WTF?

 How am I supposed to use DMD in Windows in anything other than 
 trivial,
 self-contained programs?
 VisualC is the de facto standard in Windows. All libs are 
 COFF, and (unless
 I'm working with GCC) everything I want to link to is produced 
 from VC.

 Let's also mention the debug info... Virtually every 3rd party 
 tool assumes
 and/or works best with PDB debug info. Being required to run 
 cv2pdb is
 pretty lame.

 So... why no support for COFF libs, and PDB debug info?
 Surely at least a compiler option would do the business if 
 there is some
 kinky attachment to CV and OMF :/

 I was hoping to start a project using D as a front end 
 language interacting
 with my C/C++ engine lib... but I can't.
 ... and now that I think if it... how do ANY programs built 
 with DMD
 actually work? .. How does it link to system32.lib, 
 user32.lib, etc?


 DMD on Linux gets ELF with x64 support.
 DMD on OSX gets Mach-O with x64 support.
 DMD on Windows gets ... OMF with no x64 support.

 COFF is an absolute requirements when working on Windows, yet 
 DMD doesn't support it. Everything, every programming 
 interface, every application running on x64 Windows is built 
 with COFF, the default output of every other compiler on 
 Windows is COFF, everyone else programming on Windows is 
 expecting COFF.
 Windows represents the largest OS install base in the world; 
 and yet, Windows based D programmers are told that they have to 
 dig up extremely esoteric tools from the darkest, smelliest, 
 most cobwebbed corners of the Internet, just to be able to 
 interact with the the rest of the Windows world.

 This situation is simply unacceptable.

 Everything else on Windows is COFF, if DMD ever wants to be 
 accepted as a mainstream Windows development tool, it simply 
 *MUST* support COFF. And no amount of wishing will ever change 
 this. Without COFF, D will ALWAYS be hamstrung on Windows, even 
 if OMF ever got x64 support. Every other platform that DMD 
 supports got their native object formats. It is now time to get 
 the native Windows format in D.

 All DMD needs to do is output the COFF files, any number of 
 linkers available on Windows can handle it from there. It 
 doesn't have to replace OMF and it doesn't even have to be the 
 default option, but it absolutely MUST be AN option.


I'm not a Windows user myself, but I completely agree. I'm 
writing a game engine and I'd like to do it in D at some point. 
However, I also have to support Windows and the other platforms 
(I develop on FreeBSD and support Windows,Linux,Mac,FreeBSD) and 
OMF is a blocker. I'm really glad DMD now supports ELF shared 
libs though. It basically solves one half of my problems.



 Jan 06 2012



prev sibling next sibling parent  "Nick Sabalausky" <a a.a>  writes:


"Adam Wilson" <flyboynw gmail.com> wrote in message 
news:op.v7ohzbof707hn8 apollo.hra.local...

 All DMD needs to do is output the COFF files, any number of linkers 
 available on Windows can handle it from there. It doesn't have to replace 
 OMF and it doesn't even have to be the default option, but it absolutely 
 MUST be AN option.


Just thinking: Since DigitalMars already has an OMF2COFF tool, would it 
really be all that hard for someone with access to and knowledge of the 
source (ie, Walter ;) ) to adapt it, or the knowledge within it, into a COFF 
output module for DMD? (Or has that been the plan all along?)



 Jan 06 2012



prev sibling next sibling parent reply torhu <no spam.invalid>  writes:


On 06.01.2012 21:02, Adam Wilson wrote:

 COFF is an absolute requirements when working on Windows, yet DMD doesn't
 support it. Everything, every programming interface, every application
 running on x64 Windows is built with COFF, the default output of every
 other compiler on Windows is COFF, everyone else programming on Windows is
 expecting COFF.
 Windows represents the largest OS install base in the world; and yet,
 Windows based D programmers are told that they have to dig up extremely
 esoteric tools from the darkest, smelliest, most cobwebbed corners of the
 Internet, just to be able to interact with the the rest of the Windows
 world.

 This situation is simply unacceptable.


It's not that bad.  Most libraries can be compiled to DLL files, in fact 
that's often the default.  DMD/Optlink can use DLL files created by 
other tool chains just fine. If an import library in the correct format 
is not available, just use implib or coffimplib to create one.  No problem.

Some of the D bindings for C libraries include build scripts for 
building the library with DMC, to allow for static linking with D 
programs.  Most don't, but you can still get by just fine with the DLL 
build of the library.



 Jan 06 2012



  parent reply "Adam Wilson" <flyboynw gmail.com>  writes:


On Fri, 06 Jan 2012 23:31:52 -0800, torhu <no spam.invalid> wrote:


 On 06.01.2012 21:02, Adam Wilson wrote:

 COFF is an absolute requirements when working on Windows, yet DMD  
 doesn't
 support it. Everything, every programming interface, every application
 running on x64 Windows is built with COFF, the default output of every
 other compiler on Windows is COFF, everyone else programming on Windows  
 is
 expecting COFF.
 Windows represents the largest OS install base in the world; and yet,
 Windows based D programmers are told that they have to dig up extremely
 esoteric tools from the darkest, smelliest, most cobwebbed corners of  
 the
 Internet, just to be able to interact with the the rest of the Windows
 world.

 This situation is simply unacceptable.


 It's not that bad.  Most libraries can be compiled to DLL files, in fact  
 that's often the default.  DMD/Optlink can use DLL files created by  
 other tool chains just fine. If an import library in the correct format  
 is not available, just use implib or coffimplib to create one.  No  
 problem.


First of all, what if I want to use a DLL lib file that was created by DMD  
in VC++? Oh right, can't do that either. I know there are converter tools  
available, but all of them are closed source, and what if the creator  
decides one day that he is done? I'm stuck with no source and potential  
bugs.
Second, as a professional, the idea that somehow the advice to download  
Esoteric Tool X from Shady FTP Server Y is acceptable is completely beyond  
me. No professional compiler implementation would DARE give that advice to  
it's clients, they'd laugh and find another compiler that did what they  
want. The concept of kludging together a build toolchain is uniquely open  
source. DMD will never get buy-in from large groups of professionals  
without natively supporting the things those professionals expect.

Let me state that again for clarity. If DMD does not natively support the  
standard outputs that professionals have come to expect and demand, then  
DMD will forever remain a hobby toy.

Professionals don't have time to kludge together a [fragile] build  
toolchain and support it, they have work to do. Given the choice for a  
large project right now, i'd have to say VC++ wins on Windows every time,  
it's got COFF, excellent tooling and libraries, and x64 support; but  
mostly, it works with everything Windows. DMD does not. Until DMD does,  
professionals cannot seriously consider DMD.


 Some of the D bindings for C libraries include build scripts for  
 building the library with DMC, to allow for static linking with D  
 programs.  Most don't, but you can still get by just fine with the DLL  
 build of the library.



-- 
Adam Wilson
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/



 Jan 07 2012



  parent  Manu <turkeyman gmail.com>  writes:


On 7 January 2012 10:40, Adam Wilson <flyboynw gmail.com> wrote:


 On Fri, 06 Jan 2012 23:31:52 -0800, torhu <no spam.invalid> wrote:

  On 06.01.2012 21:02, Adam Wilson wrote:

 COFF is an absolute requirements when working on Windows, yet DMD doesn't
 support it. Everything, every programming interface, every application
 running on x64 Windows is built with COFF, the default output of every
 other compiler on Windows is COFF, everyone else programming on Windows
 is
 expecting COFF.
 Windows represents the largest OS install base in the world; and yet,
 Windows based D programmers are told that they have to dig up extremely
 esoteric tools from the darkest, smelliest, most cobwebbed corners of the
 Internet, just to be able to interact with the the rest of the Windows
 world.

 This situation is simply unacceptable.


 It's not that bad.  Most libraries can be compiled to DLL files, in fact
 that's often the default.  DMD/Optlink can use DLL files created by other
 tool chains just fine. If an import library in the correct format is not
 available, just use implib or coffimplib to create one.  No problem.


 First of all, what if I want to use a DLL lib file that was created by DMD
 in VC++? Oh right, can't do that either. I know there are converter tools
 available, but all of them are closed source, and what if the creator
 decides one day that he is done? I'm stuck with no source and potential
 bugs.
 Second, as a professional, the idea that somehow the advice to download
 Esoteric Tool X from Shady FTP Server Y is acceptable is completely beyond
 me. No professional compiler implementation would DARE give that advice to
 it's clients, they'd laugh and find another compiler that did what they
 want. The concept of kludging together a build toolchain is uniquely open
 source. DMD will never get buy-in from large groups of professionals
 without natively supporting the things those professionals expect.

 Let me state that again for clarity. If DMD does not natively support the
 standard outputs that professionals have come to expect and demand, then
 DMD will forever remain a hobby toy.

 Professionals don't have time to kludge together a [fragile] build
 toolchain and support it, they have work to do. Given the choice for a
 large project right now, i'd have to say VC++ wins on Windows every time,
 it's got COFF, excellent tooling and libraries, and x64 support; but
 mostly, it works with everything Windows. DMD does not. Until DMD does,
 professionals cannot seriously consider DMD.



Hear, hear!



 Jan 07 2012



prev sibling  parent reply Don <nospam nospam.com>  writes:


On 06.01.2012 21:02, Adam Wilson wrote:

 On Fri, 06 Jan 2012 10:27:58 -0800, Manu <turkeyman gmail.com> wrote:


 Okay, so I was trying to link to a C lib, and I realised... DMD doesn't
 support/produce VS compatible libs.
 I should have realised this sooner, noting the cv debuginfo.

 So like... WTF?

 How am I supposed to use DMD in Windows in anything other than trivial,
 self-contained programs?
 VisualC is the de facto standard in Windows. All libs are COFF, and
 (unless
 I'm working with GCC) everything I want to link to is produced from VC.

 Let's also mention the debug info... Virtually every 3rd party tool
 assumes
 and/or works best with PDB debug info. Being required to run cv2pdb is
 pretty lame.

 So... why no support for COFF libs, and PDB debug info?
 Surely at least a compiler option would do the business if there is some
 kinky attachment to CV and OMF :/

 I was hoping to start a project using D as a front end language
 interacting
 with my C/C++ engine lib... but I can't.
 ... and now that I think if it... how do ANY programs built with DMD
 actually work? .. How does it link to system32.lib, user32.lib, etc?


 DMD on Linux gets ELF with x64 support.
 DMD on OSX gets Mach-O with x64 support.
 DMD on Windows gets ... OMF with no x64 support.

 COFF is an absolute requirements when working on Windows, yet DMD
 doesn't support it. Everything, every programming interface, every
 application running on x64 Windows is built with COFF, the default
 output of every other compiler on Windows is COFF, everyone else
 programming on Windows is expecting COFF.
 Windows represents the largest OS install base in the world; and yet,
 Windows based D programmers are told that they have to dig up extremely
 esoteric tools from the darkest, smelliest, most cobwebbed corners of
 the Internet, just to be able to interact with the the rest of the
 Windows world.

 This situation is simply unacceptable.

 Everything else on Windows is COFF, if DMD ever wants to be accepted as
 a mainstream Windows development tool, it simply *MUST* support COFF.
 And no amount of wishing will ever change this. Without COFF, D will
 ALWAYS be hamstrung on Windows, even if OMF ever got x64 support. Every
 other platform that DMD supports got their native object formats. It is
 now time to get the native Windows format in D.

 All DMD needs to do is output the COFF files, any number of linkers
 available on Windows can handle it from there. It doesn't have to
 replace OMF and it doesn't even have to be the default option, but it
 absolutely MUST be AN option.


 From everything I've seen, COFF seems to be very closely related to 
ELF. A large part of it is identical.
In the old DDL project on dsource, a lot of work was done in deciphering 
the formats. COFF is a lot better documented than Mach-O.

IMHO we should be looking at adding COFF output to the compiler, not to 
the linker.



 Jan 07 2012



  parent  Manu <turkeyman gmail.com>  writes:


On 7 January 2012 11:37, Don <nospam nospam.com> wrote:


 On 06.01.2012 21:02, Adam Wilson wrote:


 On Fri, 06 Jan 2012 10:27:58 -0800, Manu <turkeyman gmail.com> wrote:

  Okay, so I was trying to link to a C lib, and I realised... DMD doesn't

 support/produce VS compatible libs.
 I should have realised this sooner, noting the cv debuginfo.

 So like... WTF?

 How am I supposed to use DMD in Windows in anything other than trivial,
 self-contained programs?
 VisualC is the de facto standard in Windows. All libs are COFF, and
 (unless
 I'm working with GCC) everything I want to link to is produced from VC.

 Let's also mention the debug info... Virtually every 3rd party tool
 assumes
 and/or works best with PDB debug info. Being required to run cv2pdb is
 pretty lame.

 So... why no support for COFF libs, and PDB debug info?
 Surely at least a compiler option would do the business if there is some
 kinky attachment to CV and OMF :/

 I was hoping to start a project using D as a front end language
 interacting
 with my C/C++ engine lib... but I can't.
 ... and now that I think if it... how do ANY programs built with DMD
 actually work? .. How does it link to system32.lib, user32.lib, etc?


 DMD on Linux gets ELF with x64 support.
 DMD on OSX gets Mach-O with x64 support.
 DMD on Windows gets ... OMF with no x64 support.

 COFF is an absolute requirements when working on Windows, yet DMD
 doesn't support it. Everything, every programming interface, every
 application running on x64 Windows is built with COFF, the default
 output of every other compiler on Windows is COFF, everyone else
 programming on Windows is expecting COFF.
 Windows represents the largest OS install base in the world; and yet,
 Windows based D programmers are told that they have to dig up extremely
 esoteric tools from the darkest, smelliest, most cobwebbed corners of
 the Internet, just to be able to interact with the the rest of the
 Windows world.

 This situation is simply unacceptable.

 Everything else on Windows is COFF, if DMD ever wants to be accepted as
 a mainstream Windows development tool, it simply *MUST* support COFF.
 And no amount of wishing will ever change this. Without COFF, D will
 ALWAYS be hamstrung on Windows, even if OMF ever got x64 support. Every
 other platform that DMD supports got their native object formats. It is
 now time to get the native Windows format in D.

 All DMD needs to do is output the COFF files, any number of linkers
 available on Windows can handle it from there. It doesn't have to
 replace OMF and it doesn't even have to be the default option, but it
 absolutely MUST be AN option.


 From everything I've seen, COFF seems to be very closely related to ELF. A
 large part of it is identical.
 In the old DDL project on dsource, a lot of work was done in deciphering
 the formats. COFF is a lot better documented than Mach-O.

 IMHO we should be looking at adding COFF output to the compiler, not to
 the linker.


Definitely. I'd be happy/prefer to use VisualC's linker if the D
objects/libs were compatible.



 Jan 07 2012