Hello all,
what started as a simple request for help growed up to some kind of essay.
Here it is:

Why D is not for me?
The scene of this little opera:
I'm working for a small firm which products use kernel modules for Windows.
Part of our tests are built-in in the modules themselves but others
are user-mode programmes. But it is quite common to go one level lower
and use the so called "Native API" to do some tricks.
My boss told me that I need to made a small test programme that exercises
a obscure pattern of behaviour of our product. I thought: this is relatively
a small programme that is not top priority but nevertheless is useful and
with clear goal. A right test for what can D do for me.
And my quest started.

I've read the information on the site, I was eager to start and I downloaded
dmd.zip. I wrote my first programme which uses Native API.
And now is the right time for my first obstacle. As in any
self-respecting RPG quest, it is an easy task:

1. The official distribution of D is the only language distribution seen by me
that is not self sufficient.
  1.1. no linker - no linker? How am I supposed to build my programmes?
  1.2. no libraries - consider the default command line that dmd builds
       for optlink - kernel32+gdi32.
       Where is kernel32.lib? Where is gdi32.lib?

Please, compare dmd distribution to Python or Ruby ones.
  Ok, I'm not afraid of some digging and I actually read the documentation,
so I downloaded dmc package and installed it. The miracle happened and now
I have kernel32.lib. Which leads me to:

2. D is the only language which aims at system programming and in the same
time cannot inter-operate with the operating system.
  2.1. No easy support for importing Windows types & functions not
       included by default within Phobos.

Want to easily convert a .h file to .d? Yes of course! Not with D.
Because it does not define all basic types so you can go straight to
missing ones. So what, use Core32 from dsource.org! But one must first
find that this project exists! And then, hurray, it conflicts with Phobos!
Good, now I must find out what to comment out. Five minutes later i'm done
with this task.

  2.2. The libraries included are old. Outdated. Unusable to me. And I even
       didn't try to use Transactional NTFS functions from Vista beta WDK/SDK.
       Plain old, boring Windows 2000/XP functions (5 years old, mind this)
       are nowhere to be seen. Functions like FindFirstVolumeMountPoint
       or GetVolumePathNamesForVolumeName.
  2.3. No out-of-box support for lib files coming with SDK/DDK/IFS/WDK.
  2.4. No implib functionality so I cannot create up-to date lib files
       from the dll files.

I dig some more and found that there is coff2omf utility, which:
 * produces incompatible lib files, if I want to use the available Borland one
 * is not available free if I want to use the digital mars one
 * actually do not work because it requires special version of
 <b>Microsoft</b> link.exe that cannot be found anywhere.
 So to use Digital Mars product, I must pay to Microsoft and pray
 that I can found their very old linker somewhere in MSDN archives?
I dig some more and found the special version of OpenWatcom wlink exe
that can do the trick. And indeed, it did the trick.
After about 5 hours fight with it, I was able to spell the right incantation
that linked my 20 lines of D code.
That includes special order of library paths so that Watcom's kernel32 is
first and special order of libraries so that snn comes first.
Really, a good job for starter in a completely new language and environment!
D made me feel proud of myself. And I lost 5 hours but now I know why
most people think programming is some kind of wizardry.
If I opted for MS C++ I will be ready in less than a minute.
If I opted for C# I will be ready in less than 20 minutes (I have other tests
written in C# and I know the pattern).
  And actually that cannot be called "productive". I now must support three
separate entities: D compiler, DigitalMars C compiler and OpenWatcom linker.
And of course, for every project I start from now, I must build a bat file
and linker response file tailored for that project. No build.exe for me.
No simple dmd *.d my.lib my2.lib. Nothing like this.

Ok, my programme is linked and I have an exe file. But as my ex-boss
likes to say: "No-one should commit code in the source control system
unless she had stepped through every one of the new code in the debugger."
I know that all the tools of D language & infrastructure are there to
help me spend as little time in the debugger as possible.
Tools like contracts, unit tests, code coverage etc.
But only the debugger can tell you the flow of code.

3. Where is the debugger?
No near me, for sure.
I hear "WinDbg" screamed, am I not?
First, it does not come with D/dmd.
Second, you must find it in the Microsoft site - not an easy task.
Third, half an year earlier when WinDbg out of the blue got
the docking windows and user interface that made it actually useful
some of my colleague go out, bought some beer and celebrated it.
Fourth, that WinDbg which is quite user-unfriendly does not work with D.
There are anecdotal evidence that version of WinDbg developed circa 1996
can be used but I'm not sure I want to touch this beast.
  What other languages offer? Lua, Python & Ruby have built-in
debugging facilities. VisualStudio have a debugger which can be extend
to show your data the way you want it. The dotNet SDK comes with a
debugger (and an excellent one). D simply does not have working debugger.

To proceed with other problems, I will leave our beautiful scene
and go back in time to February 2005. In that time I had to do another
little project. This time I was choosing between 3 languages:
D, Lua and Io. I chose Lua because:

4. Documentation
Lua comes with the best book for a programming language I read so far
in my life. It is called "Programming in Lua" and is available from
http://www.lua.org/pil/. A book about a language gives a newbie a base
to stand. It gave me confidence. D (and Io) do not have this. Languages like
Python and Ruby come with "Programming Python" and "Programming Ruby" books
in the zip files you download from their sites. A newbie is lost in the scarce
documentation of D. "Programming Python/Ruby/Lua" gives you the boost to start.
I cannot stress how important is a good book for the newbie.
Just go to the link I give and read the book. And then compare to D documents.

5. Often changes of the compiler.
This is a controversial issue. But please consider, how many versions of dmd
came from February till now? Even the projects in dsource.org cannot catch
with them. Core32 collides with current phobos. DFL notes that it is tested
with version 140 and the author cannot help if you use other version.
Lua on the other side stays unchanged from 2001. Most of its bugs are
documented and their solutions are known. Also, the new version that will be
out this week is known from half an year. Its new features are known. You can
prepare for them (I am currently modifying my code to be ready for it and
send patches to authors for bugs I encounter). D just announces new features
and deprecation of old ones and leaves you to adapt.
I can't build my projects on a base that slips and changes every month.
I know Walter thinks of setting version 1.0 but that is in the future
and can't help me now.


Consider the "Major goals of D" and compare to what I said earlier:
 * Reduce software development costs by at least 10% - losing 5 hours just
 to link a simple 20 lines programme won't reduce the cost of its development.
 The requirements for 3rd party tools (namely Microsoft linker, OpenWatcom
 suite) and 4th party tools (the patched wlink for DMC) make the situation
 as bad as possible.
 * Provide low level bare metal access as required - it is not even near,
 as I really need access to ntdll.dll (the lowest level to bare metal
 in user mode available) and D actively hinders me.
 * Be compatible with the local C application binary interface - Microsoft
 tools are de facto standard for Windows platform and D does not talk to them.


To conclude, language D is a daydream coming true to every C/C++ programmer.
But what D as language gives, D as infrastructure takes tenfolds.
I admit all the problems I presented are not unresolvable,
the big problem is that I must resolve or work around them before doing any
actual work. Also I know about projects like Poseidon or D Forms Library
which prove that D is useful. All I state is that D is not useful for me
in its current form. And I think that the problems I have are applicable
to other people too. Also it is possible that I mis-read the documentation
and there is an easy way to do what I do and I simply didn't found it.
But I read as much as I can, searched in the newsgroup archives and
I think I made the best possible effort to do the things right.
Last, I know some of the problems are hard to solve.
Microsoft keeps interface of mspdb??.dll files for themselves so noone can
easily produce pdb files in the new format. And it is not redistributable.
I know that writing a book is a demanding task that often requires more than year
to complete. I thought of creating a module that in its contructor dynamically binds
to functions in ntdll & write simple wrappers in D. Et cetera.
I read the newsgroups since version 0.96 or .98 (can't remember exactly).
I'm a competent Windows developer and if Poseidon turns a good IDE I can
try to write a decent wrapper around dbghelp.dll to help build a proper
debugger. But now I feel that infrastructure of D have a room for improvements.

Regards,
Todor Totev

All valid concerns , but it sounds like you want to jump into a brand new language without having to learn or put any effort into it.

D is not an out-of-the-box solution , and as you said isn't even 1.0 yet.

Im afraid you took the long way around trying to get some library working ( you didnt mention which ? ) -- but Ill present a counter example .. have you ever used dbghelp.dll in an MFC application ?  How many ongodly hoops must you jump through to get that working ....

I like  how you sepereated out

D the language
D the infranstructure

as your right the two are very seperate , and D the infrastructure does need alot of work to become a viable commercial solution.

Charlie


"Todor Totev" <umbra.tenebris@list.ru> wrote in message news:op.s2f8okolihwmk4@todor-1-xp.sanbolic.local...


Hello all,
what started as a simple request for help growed up to some kind of essay.
Here it is:

Why D is not for me?
The scene of this little opera:
I'm working for a small firm which products use kernel modules for Windows.
Part of our tests are built-in in the modules themselves but others
are user-mode programmes. But it is quite common to go one level lower
and use the so called "Native API" to do some tricks.
My boss told me that I need to made a small test programme that exercises
a obscure pattern of behaviour of our product. I thought: this is
relatively
a small programme that is not top priority but nevertheless is useful and
with clear goal. A right test for what can D do for me.
And my quest started.

I've read the information on the site, I was eager to start and I
downloaded
dmd.zip. I wrote my first programme which uses Native API.
And now is the right time for my first obstacle. As in any
self-respecting RPG quest, it is an easy task:

1. The official distribution of D is the only language distribution seen
by me
that is not self sufficient.
   1.1. no linker - no linker? How am I supposed to build my programmes?
   1.2. no libraries - consider the default command line that dmd builds
        for optlink - kernel32+gdi32.
        Where is kernel32.lib? Where is gdi32.lib?

Please, compare dmd distribution to Python or Ruby ones.
   Ok, I'm not afraid of some digging and I actually read the documentation,
so I downloaded dmc package and installed it. The miracle happened and now
I have kernel32.lib. Which leads me to:

2. D is the only language which aims at system programming and in the same
time cannot inter-operate with the operating system.
   2.1. No easy support for importing Windows types & functions not
        included by default within Phobos.

Want to easily convert a .h file to .d? Yes of course! Not with D. Because it does not define all basic types so you can go straight to missing ones. So what, use Core32 from dsource.org! But one must first find that this project exists! And then, hurray, it conflicts with Phobos! Good, now I must find out what to comment out. Five minutes later i'm done with this task.

   2.2. The libraries included are old. Outdated. Unusable to me. And I even
        didn't try to use Transactional NTFS functions from Vista beta
WDK/SDK.
        Plain old, boring Windows 2000/XP functions (5 years old, mind this)
        are nowhere to be seen. Functions like FindFirstVolumeMountPoint
        or GetVolumePathNamesForVolumeName.
   2.3. No out-of-box support for lib files coming with SDK/DDK/IFS/WDK.
   2.4. No implib functionality so I cannot create up-to date lib files
        from the dll files.

I dig some more and found that there is coff2omf utility, which:
  * produces incompatible lib files, if I want to use the available Borland
one
  * is not available free if I want to use the digital mars one
  * actually do not work because it requires special version of
  <b>Microsoft</b> link.exe that cannot be found anywhere.
  So to use Digital Mars product, I must pay to Microsoft and pray
  that I can found their very old linker somewhere in MSDN archives?
I dig some more and found the special version of OpenWatcom wlink exe
that can do the trick. And indeed, it did the trick.
After about 5 hours fight with it, I was able to spell the right
incantation
that linked my 20 lines of D code.
That includes special order of library paths so that Watcom's kernel32 is
first and special order of libraries so that snn comes first.
Really, a good job for starter in a completely new language and
environment!
D made me feel proud of myself. And I lost 5 hours but now I know why
most people think programming is some kind of wizardry.
If I opted for MS C++ I will be ready in less than a minute.
If I opted for C# I will be ready in less than 20 minutes (I have other
tests
written in C# and I know the pattern).
   And actually that cannot be called "productive". I now must support three
separate entities: D compiler, DigitalMars C compiler and OpenWatcom
linker.
And of course, for every project I start from now, I must build a bat file
and linker response file tailored for that project. No build.exe for me.
No simple dmd *.d my.lib my2.lib. Nothing like this.

Ok, my programme is linked and I have an exe file. But as my ex-boss
likes to say: "No-one should commit code in the source control system
unless she had stepped through every one of the new code in the debugger."
I know that all the tools of D language & infrastructure are there to
help me spend as little time in the debugger as possible.
Tools like contracts, unit tests, code coverage etc.
But only the debugger can tell you the flow of code.

3. Where is the debugger?
No near me, for sure.
I hear "WinDbg" screamed, am I not?
First, it does not come with D/dmd.
Second, you must find it in the Microsoft site - not an easy task.
Third, half an year earlier when WinDbg out of the blue got
the docking windows and user interface that made it actually useful
some of my colleague go out, bought some beer and celebrated it.
Fourth, that WinDbg which is quite user-unfriendly does not work with D.
There are anecdotal evidence that version of WinDbg developed circa 1996
can be used but I'm not sure I want to touch this beast.
   What other languages offer? Lua, Python & Ruby have built-in
debugging facilities. VisualStudio have a debugger which can be extend
to show your data the way you want it. The dotNet SDK comes with a
debugger (and an excellent one). D simply does not have working debugger.

To proceed with other problems, I will leave our beautiful scene
and go back in time to February 2005. In that time I had to do another
little project. This time I was choosing between 3 languages:
D, Lua and Io. I chose Lua because:

4. Documentation
Lua comes with the best book for a programming language I read so far
in my life. It is called "Programming in Lua" and is available from
http://www.lua.org/pil/. A book about a language gives a newbie a base
to stand. It gave me confidence. D (and Io) do not have this. Languages
like
Python and Ruby come with "Programming Python" and "Programming Ruby" books
in the zip files you download from their sites. A newbie is lost in the
scarce
documentation of D. "Programming Python/Ruby/Lua" gives you the boost to
start.
I cannot stress how important is a good book for the newbie.
Just go to the link I give and read the book. And then compare to D
documents.

5. Often changes of the compiler.
This is a controversial issue. But please consider, how many versions of
dmd
came from February till now? Even the projects in dsource.org cannot catch
with them. Core32 collides with current phobos. DFL notes that it is tested
with version 140 and the author cannot help if you use other version.
Lua on the other side stays unchanged from 2001. Most of its bugs are
documented and their solutions are known. Also, the new version that will
be
out this week is known from half an year. Its new features are known. You
can
prepare for them (I am currently modifying my code to be ready for it and
send patches to authors for bugs I encounter). D just announces new
features
and deprecation of old ones and leaves you to adapt.
I can't build my projects on a base that slips and changes every month.
I know Walter thinks of setting version 1.0 but that is in the future
and can't help me now.


Consider the "Major goals of D" and compare to what I said earlier:
  * Reduce software development costs by at least 10% - losing 5 hours just
  to link a simple 20 lines programme won't reduce the cost of its
development.
  The requirements for 3rd party tools (namely Microsoft linker, OpenWatcom
  suite) and 4th party tools (the patched wlink for DMC) make the situation
  as bad as possible.
  * Provide low level bare metal access as required - it is not even near,
  as I really need access to ntdll.dll (the lowest level to bare metal
  in user mode available) and D actively hinders me.
  * Be compatible with the local C application binary interface - Microsoft
  tools are de facto standard for Windows platform and D does not talk to
them.


To conclude, language D is a daydream coming true to every
C/C++ programmer.
But what D as language gives, D as infrastructure takes tenfolds.
I admit all the problems I presented are not unresolvable,
the big problem is that I must resolve or work around them before doing any
actual work. Also I know about projects like Poseidon or D Forms Library
which prove that D is useful. All I state is that D is not useful for me
in its current form. And I think that the problems I have are applicable
to other people too. Also it is possible that I mis-read the documentation
and there is an easy way to do what I do and I simply didn't found it.
But I read as much as I can, searched in the newsgroup archives and
I think I made the best possible effort to do the things right.
Last, I know some of the problems are hard to solve.
Microsoft keeps interface of mspdb??.dll files for themselves so noone can
easily produce pdb files in the new format. And it is not redistributable.
I know that writing a book is a demanding task that often requires more
than year
to complete. I thought of creating a module that in its contructor
dynamically binds
to functions in ntdll & write simple wrappers in D. Et cetera.
I read the newsgroups since version 0.96 or .98 (can't remember exactly).
I'm a competent Windows developer and if Poseidon turns a good IDE I can
try to write a decent wrapper around dbghelp.dll to help build a proper
debugger. But now I feel that infrastructure of D have a room for
improvements.

Regards,
Todor Totev

LOL. No offence but this is why products which are driving the programming/computers/world down (in my opinion) have such big success. People want everything to be a big template. Aranged just for them. Without the need to think. Without the need to do anything. Just choose from a template. Of course I am looking from a non-comercial perpespective. I value D because it is fast, easy, GREAT! Maybe for people who want to make money from it these problems matters but still. Everything you can do with C#, Java or some other fashion choose-one-from-the-template-wizard crap you can do with D. Sometimes it requires more coding and when it doesn't come out of the box with library X people don't even think that they can do it on their own. And after all if we all code in D  and forget about the slow DND (so called programming) crap who will make the people buy faster computers? Because you cant make a D program run slow. Unlike the virtual machines where you cant make a program run fast.

Todor Totev wrote:
> 
> 
> Hello all,
> what started as a simple request for help growed up to some kind of essay.
> Here it is:
> 
> Why D is not for me?
> The scene of this little opera:
> I'm working for a small firm which products use kernel modules for Windows.
> Part of our tests are built-in in the modules themselves but others
> are user-mode programmes. But it is quite common to go one level lower
> and use the so called "Native API" to do some tricks.
> My boss told me that I need to made a small test programme that exercises
> a obscure pattern of behaviour of our product. I thought: this is  relatively
> a small programme that is not top priority but nevertheless is useful and
> with clear goal. A right test for what can D do for me.
> And my quest started.
> 
> I've read the information on the site, I was eager to start and I  downloaded
> dmd.zip. I wrote my first programme which uses Native API.
> And now is the right time for my first obstacle. As in any
> self-respecting RPG quest, it is an easy task:
> 
> 1. The official distribution of D is the only language distribution seen  by me
> that is not self sufficient.
>   1.1. no linker - no linker? How am I supposed to build my programmes?
>   1.2. no libraries - consider the default command line that dmd builds
>        for optlink - kernel32+gdi32.
>        Where is kernel32.lib? Where is gdi32.lib?
> 
> Please, compare dmd distribution to Python or Ruby ones.
>   Ok, I'm not afraid of some digging and I actually read the documentation,
> so I downloaded dmc package and installed it. The miracle happened and now
> I have kernel32.lib. Which leads me to:
> 
> 2. D is the only language which aims at system programming and in the same
> time cannot inter-operate with the operating system.
>   2.1. No easy support for importing Windows types & functions not
>        included by default within Phobos.
> 
> Want to easily convert a .h file to .d? Yes of course! Not with D.
> Because it does not define all basic types so you can go straight to
> missing ones. So what, use Core32 from dsource.org! But one must first
> find that this project exists! And then, hurray, it conflicts with Phobos!
> Good, now I must find out what to comment out. Five minutes later i'm done
> with this task.
> 
>   2.2. The libraries included are old. Outdated. Unusable to me. And I even
>        didn't try to use Transactional NTFS functions from Vista beta  WDK/SDK.
>        Plain old, boring Windows 2000/XP functions (5 years old, mind this)
>        are nowhere to be seen. Functions like FindFirstVolumeMountPoint
>        or GetVolumePathNamesForVolumeName.
>   2.3. No out-of-box support for lib files coming with SDK/DDK/IFS/WDK.
>   2.4. No implib functionality so I cannot create up-to date lib files
>        from the dll files.
> 
> I dig some more and found that there is coff2omf utility, which:
>  * produces incompatible lib files, if I want to use the available Borland  one
>  * is not available free if I want to use the digital mars one
>  * actually do not work because it requires special version of
>  <b>Microsoft</b> link.exe that cannot be found anywhere.
>  So to use Digital Mars product, I must pay to Microsoft and pray
>  that I can found their very old linker somewhere in MSDN archives?
> I dig some more and found the special version of OpenWatcom wlink exe
> that can do the trick. And indeed, it did the trick.
> After about 5 hours fight with it, I was able to spell the right  incantation
> that linked my 20 lines of D code.
> That includes special order of library paths so that Watcom's kernel32 is
> first and special order of libraries so that snn comes first.
> Really, a good job for starter in a completely new language and  environment!
> D made me feel proud of myself. And I lost 5 hours but now I know why
> most people think programming is some kind of wizardry.
> If I opted for MS C++ I will be ready in less than a minute.
> If I opted for C# I will be ready in less than 20 minutes (I have other  tests
> written in C# and I know the pattern).
>   And actually that cannot be called "productive". I now must support three
> separate entities: D compiler, DigitalMars C compiler and OpenWatcom  linker.
> And of course, for every project I start from now, I must build a bat file
> and linker response file tailored for that project. No build.exe for me.
> No simple dmd *.d my.lib my2.lib. Nothing like this.
> 
> Ok, my programme is linked and I have an exe file. But as my ex-boss
> likes to say: "No-one should commit code in the source control system
> unless she had stepped through every one of the new code in the debugger."
> I know that all the tools of D language & infrastructure are there to
> help me spend as little time in the debugger as possible.
> Tools like contracts, unit tests, code coverage etc.
> But only the debugger can tell you the flow of code.
> 
> 3. Where is the debugger?
> No near me, for sure.
> I hear "WinDbg" screamed, am I not?
> First, it does not come with D/dmd.
> Second, you must find it in the Microsoft site - not an easy task.
> Third, half an year earlier when WinDbg out of the blue got
> the docking windows and user interface that made it actually useful
> some of my colleague go out, bought some beer and celebrated it.
> Fourth, that WinDbg which is quite user-unfriendly does not work with D.
> There are anecdotal evidence that version of WinDbg developed circa 1996
> can be used but I'm not sure I want to touch this beast.
>   What other languages offer? Lua, Python & Ruby have built-in
> debugging facilities. VisualStudio have a debugger which can be extend
> to show your data the way you want it. The dotNet SDK comes with a
> debugger (and an excellent one). D simply does not have working debugger.
> 
> To proceed with other problems, I will leave our beautiful scene
> and go back in time to February 2005. In that time I had to do another
> little project. This time I was choosing between 3 languages:
> D, Lua and Io. I chose Lua because:
> 
> 4. Documentation
> Lua comes with the best book for a programming language I read so far
> in my life. It is called "Programming in Lua" and is available from
> http://www.lua.org/pil/. A book about a language gives a newbie a base
> to stand. It gave me confidence. D (and Io) do not have this. Languages  like
> Python and Ruby come with "Programming Python" and "Programming Ruby" books
> in the zip files you download from their sites. A newbie is lost in the  scarce
> documentation of D. "Programming Python/Ruby/Lua" gives you the boost to  start.
> I cannot stress how important is a good book for the newbie.
> Just go to the link I give and read the book. And then compare to D  documents.
> 
> 5. Often changes of the compiler.
> This is a controversial issue. But please consider, how many versions of  dmd
> came from February till now? Even the projects in dsource.org cannot catch
> with them. Core32 collides with current phobos. DFL notes that it is tested
> with version 140 and the author cannot help if you use other version.
> Lua on the other side stays unchanged from 2001. Most of its bugs are
> documented and their solutions are known. Also, the new version that will  be
> out this week is known from half an year. Its new features are known. You  can
> prepare for them (I am currently modifying my code to be ready for it and
> send patches to authors for bugs I encounter). D just announces new  features
> and deprecation of old ones and leaves you to adapt.
> I can't build my projects on a base that slips and changes every month.
> I know Walter thinks of setting version 1.0 but that is in the future
> and can't help me now.
> 
> 
> Consider the "Major goals of D" and compare to what I said earlier:
>  * Reduce software development costs by at least 10% - losing 5 hours just
>  to link a simple 20 lines programme won't reduce the cost of its  development.
>  The requirements for 3rd party tools (namely Microsoft linker, OpenWatcom
>  suite) and 4th party tools (the patched wlink for DMC) make the situation
>  as bad as possible.
>  * Provide low level bare metal access as required - it is not even near,
>  as I really need access to ntdll.dll (the lowest level to bare metal
>  in user mode available) and D actively hinders me.
>  * Be compatible with the local C application binary interface - Microsoft
>  tools are de facto standard for Windows platform and D does not talk to  them.
> 
> 
> To conclude, language D is a daydream coming true to every  C/C++ programmer.
> But what D as language gives, D as infrastructure takes tenfolds.
> I admit all the problems I presented are not unresolvable,
> the big problem is that I must resolve or work around them before doing any
> actual work. Also I know about projects like Poseidon or D Forms Library
> which prove that D is useful. All I state is that D is not useful for me
> in its current form. And I think that the problems I have are applicable
> to other people too. Also it is possible that I mis-read the documentation
> and there is an easy way to do what I do and I simply didn't found it.
> But I read as much as I can, searched in the newsgroup archives and
> I think I made the best possible effort to do the things right.
> Last, I know some of the problems are hard to solve.
> Microsoft keeps interface of mspdb??.dll files for themselves so noone can
> easily produce pdb files in the new format. And it is not redistributable.
> I know that writing a book is a demanding task that often requires more  than year
> to complete. I thought of creating a module that in its contructor  dynamically binds
> to functions in ntdll & write simple wrappers in D. Et cetera.
> I read the newsgroups since version 0.96 or .98 (can't remember exactly).
> I'm a competent Windows developer and if Poseidon turns a good IDE I can
> try to write a decent wrapper around dbghelp.dll to help build a proper
> debugger. But now I feel that infrastructure of D have a room for  improvements.
> 
> Regards,
> Todor Totev

On Wed, 28 Dec 2005 02:44:34 +1100, Todor Totev <umbra.tenebris@list.ru> wrote:

>
>
> Hello all,
> what started as a simple request for help growed up to some kind of essay.
> Here it is:
>
> Why D is not for me?

A well thought out and restrained essay. I agree with will all you say, to varying degrees. I imagine that the primary reason for the omissions you detail is the lack of people working on the problems. Walter is the bottleneck that all submissions must pass through at the moment. Even libraries such as Ares and Mango which go to replace and expand Phobos are short on active workers.

Although the language itself, as opposed to tools and implementation, is still in flux, it is almost stable.

-- 
Derek Parnell
Melbroune, Australia

Todor Totev wrote:
> 
> 
> Hello all,
> what started as a simple request for help growed up to some kind of essay.

If you're referring to your "Problem with COFF library" post, then I'd have to say that

  1) You didn't leave enough time for someone to come and provide a
     clear response to your unclear request for help.
  2) Your request was very far off in a tiny niche of the support corner
     that it makes it very hard to reproduce what it is you're
     discovering (let alone without any code examples given).

> Here it is:
> 
> Why D is not for me?
> The scene of this little opera:
> I'm working for a small firm which products use kernel modules for Windows.
> Part of our tests are built-in in the modules themselves but others
> are user-mode programmes. But it is quite common to go one level lower
> and use the so called "Native API" to do some tricks.
> My boss told me that I need to made a small test programme that exercises
> a obscure pattern of behaviour of our product. I thought: this is  relatively
> a small programme that is not top priority but nevertheless is useful and
> with clear goal. A right test for what can D do for me.
> And my quest started.
> 
> I've read the information on the site, I was eager to start and I  downloaded
> dmd.zip. I wrote my first programme which uses Native API.
> And now is the right time for my first obstacle. As in any
> self-respecting RPG quest, it is an easy task:
> 
> 1. The official distribution of D is the only language distribution seen  by me
> that is not self sufficient.
>   1.1. no linker - no linker? How am I supposed to build my programmes?
>   1.2. no libraries - consider the default command line that dmd builds
>        for optlink - kernel32+gdi32.
>        Where is kernel32.lib? Where is gdi32.lib?
> 
> Please, compare dmd distribution to Python or Ruby ones.

Ok.  Python and Ruby do not run on the bare metal of the processor. They have their own bytecode and interpreter.  Their interpreters for the Windows platform were undoubtedly created using Microsoft's C++ compiler and hence having full access to the Windows platform and all of its libraries.  Writing Microsoft-specific implementations for the Python or Ruby standard library functions is now an easy task.  You don't need to link your Python or Ruby executable to kernel32.lib or gdi32.lib, because the interpreter that runs your Python/Ruby program is already linked to those.

This is simply not the case with DMD.  (and you will hear this repeated later in this post)

>   Ok, I'm not afraid of some digging and I actually read the documentation,
> so I downloaded dmc package and installed it. The miracle happened and now
> I have kernel32.lib. Which leads me to:

DMD is based on the Digital Mars C/C++ toolset as you've discovered.  On the download page the two are together and the instructions clearly state that 'dmc.zip' is a requirement (from http://digitalmars.com/d/dcompiler.html#Win32):

"Requirements

    * 32 bit Windows (Win32) operating system, such as Windows XP
    * dmd.zip (D compiler) for Win32
    * dmc.zip (linker and utilities) for Win32"

Yes, slightly annoying to those of us who'd skip over this and just grab what we think we only need... But then again why package the same tools in two different archives?  This way you only have to update your dmc once (or whenever DMC actually changes which is rare), and just keep updating the dmd side of things.  Bandwidth saved.  Time saved (unless you didn't read =P).

> 2. D is the only language which aims at system programming and in the same
> time cannot inter-operate with the operating system.
>   2.1. No easy support for importing Windows types & functions not
>        included by default within Phobos.
> 

D is not a platform-dependent language.  You are referring to the D infrastructure here, specific to the Windows platform.  It is not the purpose of Phobos to become a transparent gateway to the raw Windows API.  Yes, admittedly, phobos' Windows support is lacking.

> Want to easily convert a .h file to .d? Yes of course! Not with D.

The h2d tool is on dsource.org, but written in C++ requiring the boost libraries.

> Because it does not define all basic types so you can go straight to
> missing ones. So what, use Core32 from dsource.org! But one must first
> find that this project exists! And then, hurray, it conflicts with Phobos!
> Good, now I must find out what to comment out. Five minutes later i'm done
> with this task.
> 

Well, that wasn't so bad.  I'd contact the author/maintainer of Core32 and let them know the problem.

>   2.2. The libraries included are old. Outdated. Unusable to me. And I even
>        didn't try to use Transactional NTFS functions from Vista beta  WDK/SDK.
>        Plain old, boring Windows 2000/XP functions (5 years old, mind this)
>        are nowhere to be seen. Functions like FindFirstVolumeMountPoint
>        or GetVolumePathNamesForVolumeName.
>   2.3. No out-of-box support for lib files coming with SDK/DDK/IFS/WDK.
>   2.4. No implib functionality so I cannot create up-to date lib files
>        from the dll files.
> 

If you didn't know, the SDK, DDK, IFS, WDK, whatever from Microsoft are all proprietary development kits which must be purchased and licensed at hefty costs.  I'm no legal expert, but knowing Microsoft there is probably a high barrier to entry for compilers wanting to fully support the Windows platforms.  I certainly wouldn't expect, let alone demand, from Walter that he shell out cash in the neighborhood of 5-6 figures to Microsoft to get such support for his compiler.

> I dig some more and found that there is coff2omf utility, which:
>  * produces incompatible lib files, if I want to use the available Borland  one

I don't fully understand your note here.  Use what available Borland what now?

>  * is not available free if I want to use the digital mars one

Digital Mars has to make their income somehow.  The utility CD is $15. Sacrifice a night out at the movies (which is most likely to be > $15) and grab your copy.  This is incomparable to what Microsoft would charge you for their compiler toolset.

>  * actually do not work because it requires special version of
>  <b>Microsoft</b> link.exe that cannot be found anywhere.
>  So to use Digital Mars product, I must pay to Microsoft and pray
>  that I can found their very old linker somewhere in MSDN archives?

Again, I'm not sure what you'd need this old LINK utility for?  If you use the Digital Mars toolset CD (available for $15 as noted above), then you wouldn't have to delve into these murky waters.  I could be wrong, since I'm not clear on your intentions here.

> I dig some more and found the special version of OpenWatcom wlink exe
> that can do the trick. And indeed, it did the trick.
> After about 5 hours fight with it, I was able to spell the right  incantation
> that linked my 20 lines of D code.
> That includes special order of library paths so that Watcom's kernel32 is
> first and special order of libraries so that snn comes first.

I'm happy to hear you persevered and got your solution, but still I believe things might've worked better by just using the readily available Digital Mars toolset.

Besides, this COFF and OMF format thing is hardly Digital Mars' fault. Microsoft went their own way, invented their own standard, and closed the books on it so hardly anyone else could come and share.  This doesn't sound like a standard to me.

> Really, a good job for starter in a completely new language and  environment!
> D made me feel proud of myself. And I lost 5 hours but now I know why
> most people think programming is some kind of wizardry.

This isn't programming anymore... =P

> If I opted for MS C++ I will be ready in less than a minute.

Well of course, since MS C++ is the same MS that gave you Windows.  It's not Digital Mars Windows XP, now is it? =)  Also, you'd be out $750.

> If I opted for C# I will be ready in less than 20 minutes (I have other  tests
> written in C# and I know the pattern).

That's funny that C# takes longer for you than C++?

>   And actually that cannot be called "productive". I now must support three
> separate entities: D compiler, DigitalMars C compiler and OpenWatcom  linker.
> And of course, for every project I start from now, I must build a bat file
> and linker response file tailored for that project. No build.exe for me.
> No simple dmd *.d my.lib my2.lib. Nothing like this.

Derek Parnell's 'build' utility (available also on dsource.org) will get you headed in the right direction here.

> Ok, my programme is linked and I have an exe file. But as my ex-boss
> likes to say: "No-one should commit code in the source control system
> unless she had stepped through every one of the new code in the debugger."
> I know that all the tools of D language & infrastructure are there to
> help me spend as little time in the debugger as possible.
> Tools like contracts, unit tests, code coverage etc.
> But only the debugger can tell you the flow of code.

While your ex-boss may be a wise man stating this, it shouldn't be a strict requirement that all code must be stepped-through in a debugger in order to be bug-free.  True, it may catch many uncaught bugs, but this is what (and you realize this) the tools the language provides to you should help to eliminate.

> 3. Where is the debugger?
> No near me, for sure.
> I hear "WinDbg" screamed, am I not?

First off, again you're assuming Windows platform here.  GDC and GDB are perfectly acceptable alternatives.

> First, it does not come with D/dmd.

Nor should it, because it is not a Digital Mars product.

> Second, you must find it in the Microsoft site - not an easy task.

This is Microsoft's fault alone.  Personally, I think it isn't all that hard to find.  Your milage may (and did) vary, of course.

> Third, half an year earlier when WinDbg out of the blue got
> the docking windows and user interface that made it actually useful
> some of my colleague go out, bought some beer and celebrated it.

Slapping a GUI onto a tool does not instantly make it "actually useful".  It *might* make it more user-friendly and manageable, but the old tool was just as useful.

> Fourth, that WinDbg which is quite user-unfriendly does not work with D.

If you mean that it doesn't work with D in that you can't peek at local variables' contents, then I should state that this is a problem with Microsoft's tools sporting their proprietary PDB file format.

> There are anecdotal evidence that version of WinDbg developed circa 1996
> can be used but I'm not sure I want to touch this beast.
>   What other languages offer? Lua, Python & Ruby have built-in
> debugging facilities. VisualStudio have a debugger which can be extend
> to show your data the way you want it. The dotNet SDK comes with a
> debugger (and an excellent one). D simply does not have working debugger.

None of these languages are 'systems programming' languages.  They work through bytecode and interpretation (or JIT compilation) which make it significantly easier to debug and step-through.  D compiles down to native code, which is not so easy to debug.  I believe a D debugger project is in the works on dsource.org (dbug?) but I haven't tried it myself.

> To proceed with other problems, I will leave our beautiful scene
> and go back in time to February 2005. In that time I had to do another
> little project. This time I was choosing between 3 languages:
> D, Lua and Io. I chose Lua because:
> 
> 4. Documentation
> Lua comes with the best book for a programming language I read so far
> in my life. It is called "Programming in Lua" and is available from
> http://www.lua.org/pil/. A book about a language gives a newbie a base
> to stand. It gave me confidence. D (and Io) do not have this. Languages  like
> Python and Ruby come with "Programming Python" and "Programming Ruby" books
> in the zip files you download from their sites. A newbie is lost in the  scarce
> documentation of D. "Programming Python/Ruby/Lua" gives you the boost to  start.
> I cannot stress how important is a good book for the newbie.
> Just go to the link I give and read the book. And then compare to D  documents.

D is assuming a solid understanding of C and [C++ or OOP in general] as a start for learning D.  While a book would be great for the business-oriented newbie who is being paid to be trained in the language, I believe there is no substitue for raw experience gained while tinkering with the language.  Once you have the basics down, go ahead and read the reference books/docs to find out what you may have missed in your tinkering sessions.

> 5. Often changes of the compiler.
> This is a controversial issue. But please consider, how many versions of  dmd
> came from February till now? Even the projects in dsource.org cannot catch
> with them. Core32 collides with current phobos. DFL notes that it is tested
> with version 140 and the author cannot help if you use other version.
> Lua on the other side stays unchanged from 2001. Most of its bugs are
> documented and their solutions are known. Also, the new version that will  be
> out this week is known from half an year. Its new features are known. You  can
> prepare for them (I am currently modifying my code to be ready for it and
> send patches to authors for bugs I encounter). D just announces new  features
> and deprecation of old ones and leaves you to adapt.
> I can't build my projects on a base that slips and changes every month.
> I know Walter thinks of setting version 1.0 but that is in the future
> and can't help me now.
> 
> 
> Consider the "Major goals of D" and compare to what I said earlier:
>  * Reduce software development costs by at least 10% - losing 5 hours just
>  to link a simple 20 lines programme won't reduce the cost of its  development.

This was your case, and for what it's worth it was probably the worst-case scenario.

>  The requirements for 3rd party tools (namely Microsoft linker, OpenWatcom
>  suite) and 4th party tools (the patched wlink for DMC) make the situation
>  as bad as possible.

These are not requirements for regular development.

>  * Provide low level bare metal access as required - it is not even near,
>  as I really need access to ntdll.dll (the lowest level to bare metal
>  in user mode available) and D actively hinders me.

Bare-metal access does not mean access to operating system libraries. It means that the code will run on the native processor without requiring an interpreter or JIT compiler.

>  * Be compatible with the local C application binary interface - Microsoft
>  tools are de facto standard for Windows platform and D does not talk to  them.

Microsoft tools were made to force a de facto standard on the Windows platform because they use and integrate so well their own proprietary technologies to keep others out.

If you had made a case developing for Linux using either the Linux version of DMD or the GDC front-end for GCC, I'm sure your experience would have been much more enjoyable.

> To conclude, language D is a daydream coming true to every  C/C++ programmer.
> But what D as language gives, D as infrastructure takes tenfolds.

Very good of you to separate the two.  I applaud this clarity of thinking.

> I admit all the problems I presented are not unresolvable,
> the big problem is that I must resolve or work around them before doing any
> actual work. Also I know about projects like Poseidon or D Forms Library
> which prove that D is useful. All I state is that D is not useful for me
> in its current form. And I think that the problems I have are applicable
> to other people too. Also it is possible that I mis-read the documentation
> and there is an easy way to do what I do and I simply didn't found it.
> But I read as much as I can, searched in the newsgroup archives and
> I think I made the best possible effort to do the things right.
> Last, I know some of the problems are hard to solve.

> Microsoft keeps interface of mspdb??.dll files for themselves so noone can
> easily produce pdb files in the new format. And it is not redistributable.
> I know that writing a book is a demanding task that often requires more  than year to complete. I thought of creating a module that in its contructor  dynamically binds to functions in ntdll & write simple wrappers in D. Et cetera.

Why not?  Help out a bit.  You've faced these problems yourself, why leave the road as bumpy for the next guy?

> I read the newsgroups since version 0.96 or .98 (can't remember exactly).
> I'm a competent Windows developer and if Poseidon turns a good IDE I can
> try to write a decent wrapper around dbghelp.dll to help build a proper
> debugger. But now I feel that infrastructure of D have a room for  improvements.
> 
> Regards,
> Todor Totev

To be fair, use the tools that are right for the job.  D might not be right for your current project, at the current time.  Don't overgeneralize to everyone else stating that D is a completely useless language in all areas of development.

Regards,
James Dunne

Excellent / well though-out post. I think your concerns are very legitimate.

I have absolutely no experience in your situation, but I encountered the same kind of problems when I tried to use Linux as a desktop environment. (i.e. endless compatibility issues.)
Linux seems to have developed a culture which does not care about these details and expects the users to waste their time and solve them (see some of the replies to your post).

One thing though, the problem of not finding a linker can be solved by downloading the dmc.zip file from the same page where you found the compiler.




Todor Totev wrote:
> 
> 
> Hello all,
> what started as a simple request for help growed up to some kind of essay.
> Here it is:
> 
> Why D is not for me?
> The scene of this little opera:
> I'm working for a small firm which products use kernel modules for Windows.
> Part of our tests are built-in in the modules themselves but others
> are user-mode programmes. But it is quite common to go one level lower
> and use the so called "Native API" to do some tricks.
> My boss told me that I need to made a small test programme that exercises
> a obscure pattern of behaviour of our product. I thought: this is  relatively
> a small programme that is not top priority but nevertheless is useful and
> with clear goal. A right test for what can D do for me.
> And my quest started.
> 
> I've read the information on the site, I was eager to start and I  downloaded
> dmd.zip. I wrote my first programme which uses Native API.
> And now is the right time for my first obstacle. As in any
> self-respecting RPG quest, it is an easy task:
> 
> 1. The official distribution of D is the only language distribution seen  by me
> that is not self sufficient.
>   1.1. no linker - no linker? How am I supposed to build my programmes?
>   1.2. no libraries - consider the default command line that dmd builds
>        for optlink - kernel32+gdi32.
>        Where is kernel32.lib? Where is gdi32.lib?
> 
> Please, compare dmd distribution to Python or Ruby ones.
>   Ok, I'm not afraid of some digging and I actually read the documentation,
> so I downloaded dmc package and installed it. The miracle happened and now
> I have kernel32.lib. Which leads me to:
> 
> 2. D is the only language which aims at system programming and in the same
> time cannot inter-operate with the operating system.
>   2.1. No easy support for importing Windows types & functions not
>        included by default within Phobos.
> 
> Want to easily convert a .h file to .d? Yes of course! Not with D.
> Because it does not define all basic types so you can go straight to
> missing ones. So what, use Core32 from dsource.org! But one must first
> find that this project exists! And then, hurray, it conflicts with Phobos!
> Good, now I must find out what to comment out. Five minutes later i'm done
> with this task.
> 
>   2.2. The libraries included are old. Outdated. Unusable to me. And I even
>        didn't try to use Transactional NTFS functions from Vista beta  WDK/SDK.
>        Plain old, boring Windows 2000/XP functions (5 years old, mind this)
>        are nowhere to be seen. Functions like FindFirstVolumeMountPoint
>        or GetVolumePathNamesForVolumeName.
>   2.3. No out-of-box support for lib files coming with SDK/DDK/IFS/WDK.
>   2.4. No implib functionality so I cannot create up-to date lib files
>        from the dll files.
> 
> I dig some more and found that there is coff2omf utility, which:
>  * produces incompatible lib files, if I want to use the available Borland  one
>  * is not available free if I want to use the digital mars one
>  * actually do not work because it requires special version of
>  <b>Microsoft</b> link.exe that cannot be found anywhere.
>  So to use Digital Mars product, I must pay to Microsoft and pray
>  that I can found their very old linker somewhere in MSDN archives?
> I dig some more and found the special version of OpenWatcom wlink exe
> that can do the trick. And indeed, it did the trick.
> After about 5 hours fight with it, I was able to spell the right  incantation
> that linked my 20 lines of D code.
> That includes special order of library paths so that Watcom's kernel32 is
> first and special order of libraries so that snn comes first.
> Really, a good job for starter in a completely new language and  environment!
> D made me feel proud of myself. And I lost 5 hours but now I know why
> most people think programming is some kind of wizardry.
> If I opted for MS C++ I will be ready in less than a minute.
> If I opted for C# I will be ready in less than 20 minutes (I have other  tests
> written in C# and I know the pattern).
>   And actually that cannot be called "productive". I now must support three
> separate entities: D compiler, DigitalMars C compiler and OpenWatcom  linker.
> And of course, for every project I start from now, I must build a bat file
> and linker response file tailored for that project. No build.exe for me.
> No simple dmd *.d my.lib my2.lib. Nothing like this.
> 
> Ok, my programme is linked and I have an exe file. But as my ex-boss
> likes to say: "No-one should commit code in the source control system
> unless she had stepped through every one of the new code in the debugger."
> I know that all the tools of D language & infrastructure are there to
> help me spend as little time in the debugger as possible.
> Tools like contracts, unit tests, code coverage etc.
> But only the debugger can tell you the flow of code.
> 
> 3. Where is the debugger?
> No near me, for sure.
> I hear "WinDbg" screamed, am I not?
> First, it does not come with D/dmd.
> Second, you must find it in the Microsoft site - not an easy task.
> Third, half an year earlier when WinDbg out of the blue got
> the docking windows and user interface that made it actually useful
> some of my colleague go out, bought some beer and celebrated it.
> Fourth, that WinDbg which is quite user-unfriendly does not work with D.
> There are anecdotal evidence that version of WinDbg developed circa 1996
> can be used but I'm not sure I want to touch this beast.
>   What other languages offer? Lua, Python & Ruby have built-in
> debugging facilities. VisualStudio have a debugger which can be extend
> to show your data the way you want it. The dotNet SDK comes with a
> debugger (and an excellent one). D simply does not have working debugger.
> 
> To proceed with other problems, I will leave our beautiful scene
> and go back in time to February 2005. In that time I had to do another
> little project. This time I was choosing between 3 languages:
> D, Lua and Io. I chose Lua because:
> 
> 4. Documentation
> Lua comes with the best book for a programming language I read so far
> in my life. It is called "Programming in Lua" and is available from
> http://www.lua.org/pil/. A book about a language gives a newbie a base
> to stand. It gave me confidence. D (and Io) do not have this. Languages  like
> Python and Ruby come with "Programming Python" and "Programming Ruby" books
> in the zip files you download from their sites. A newbie is lost in the  scarce
> documentation of D. "Programming Python/Ruby/Lua" gives you the boost to  start.
> I cannot stress how important is a good book for the newbie.
> Just go to the link I give and read the book. And then compare to D  documents.
> 
> 5. Often changes of the compiler.
> This is a controversial issue. But please consider, how many versions of  dmd
> came from February till now? Even the projects in dsource.org cannot catch
> with them. Core32 collides with current phobos. DFL notes that it is tested
> with version 140 and the author cannot help if you use other version.
> Lua on the other side stays unchanged from 2001. Most of its bugs are
> documented and their solutions are known. Also, the new version that will  be
> out this week is known from half an year. Its new features are known. You  can
> prepare for them (I am currently modifying my code to be ready for it and
> send patches to authors for bugs I encounter). D just announces new  features
> and deprecation of old ones and leaves you to adapt.
> I can't build my projects on a base that slips and changes every month.
> I know Walter thinks of setting version 1.0 but that is in the future
> and can't help me now.
> 
> 
> Consider the "Major goals of D" and compare to what I said earlier:
>  * Reduce software development costs by at least 10% - losing 5 hours just
>  to link a simple 20 lines programme won't reduce the cost of its  development.
>  The requirements for 3rd party tools (namely Microsoft linker, OpenWatcom
>  suite) and 4th party tools (the patched wlink for DMC) make the situation
>  as bad as possible.
>  * Provide low level bare metal access as required - it is not even near,
>  as I really need access to ntdll.dll (the lowest level to bare metal
>  in user mode available) and D actively hinders me.
>  * Be compatible with the local C application binary interface - Microsoft
>  tools are de facto standard for Windows platform and D does not talk to  them.
> 
> 
> To conclude, language D is a daydream coming true to every  C/C++ programmer.
> But what D as language gives, D as infrastructure takes tenfolds.
> I admit all the problems I presented are not unresolvable,
> the big problem is that I must resolve or work around them before doing any
> actual work. Also I know about projects like Poseidon or D Forms Library
> which prove that D is useful. All I state is that D is not useful for me
> in its current form. And I think that the problems I have are applicable
> to other people too. Also it is possible that I mis-read the documentation
> and there is an easy way to do what I do and I simply didn't found it.
> But I read as much as I can, searched in the newsgroup archives and
> I think I made the best possible effort to do the things right.
> Last, I know some of the problems are hard to solve.
> Microsoft keeps interface of mspdb??.dll files for themselves so noone can
> easily produce pdb files in the new format. And it is not redistributable.
> I know that writing a book is a demanding task that often requires more  than year
> to complete. I thought of creating a module that in its contructor  dynamically binds
> to functions in ntdll & write simple wrappers in D. Et cetera.
> I read the newsgroups since version 0.96 or .98 (can't remember exactly).
> I'm a competent Windows developer and if Poseidon turns a good IDE I can
> try to write a decent wrapper around dbghelp.dll to help build a proper
> debugger. But now I feel that infrastructure of D have a room for  improvements.
> 
> Regards,
> Todor Totev

Two thoughts of my own experience for you:

- D infrastructure is this way because it's pre-1.0 version (the language and the compiler are at kind of BETA stage). Not ready for serious project development (so here a lot of your complaints gets demolished).

- If you would just downloaded DMC linker (and the other tools coming with it) *as instructions states clearly*, all that 5 hours of wasted hard work would had been spended in a more useful way. I had no problems the first time i wanted to try D. It was about minutes before getting simple demos compiling/linking and running.

Though I would agree with people saying D is taking too long to get out of its current BETA stage. Walter should open the project or dedicate more of his time in it (i don't know about the disadvantages of doing the first).

Tom;

In article <op.s2f8okolihwmk4@todor-1-xp.sanbolic.local>, Todor Totev says...
>Hello all,
>what started as a simple request for help growed up to some kind of essa=
>y.
>Here it is:
>
>Why D is not for me?
>The scene of this little opera:
>I'm working for a small firm which products use kernel modules for Windo=
>ws.
>Part of our tests are built-in in the modules themselves but others
>are user-mode programmes. But it is quite common to go one level lower
>and use the so called "Native API" to do some tricks.
>My boss told me that I need to made a small test programme that exercise=
>s
>a obscure pattern of behaviour of our product. I thought: this is  =
>
>relatively
>a small programme that is not top priority but nevertheless is useful an=
>d
>with clear goal. A right test for what can D do for me.
>And my quest started.
>
>I've read the information on the site, I was eager to start and I  =
>
>downloaded
>dmd.zip. I wrote my first programme which uses Native API.
>And now is the right time for my first obstacle. As in any
>self-respecting RPG quest, it is an easy task:
>
>1. The official distribution of D is the only language distribution seen=
>  =
>
>by me
>that is not self sufficient.
>   1.1. no linker - no linker? How am I supposed to build my programmes?=
>
>   1.2. no libraries - consider the default command line that dmd builds=
>
>        for optlink - kernel32+gdi32.
>        Where is kernel32.lib? Where is gdi32.lib?
>
>Please, compare dmd distribution to Python or Ruby ones.
>   Ok, I'm not afraid of some digging and I actually read the documentat=
>ion,
>so I downloaded dmc package and installed it. The miracle happened and n=
>ow
>I have kernel32.lib. Which leads me to:
>
>2. D is the only language which aims at system programming and in the sa=
>me
>time cannot inter-operate with the operating system.
>   2.1. No easy support for importing Windows types & functions not
>        included by default within Phobos.
>
>Want to easily convert a .h file to .d? Yes of course! Not with D.
>Because it does not define all basic types so you can go straight to
>missing ones. So what, use Core32 from dsource.org! But one must first
>find that this project exists! And then, hurray, it conflicts with Phobo=
>s!
>Good, now I must find out what to comment out. Five minutes later i'm do=
>ne
>with this task.
>
>   2.2. The libraries included are old. Outdated. Unusable to me. And I =
>even
>        didn't try to use Transactional NTFS functions from Vista beta  =
>
>WDK/SDK.
>        Plain old, boring Windows 2000/XP functions (5 years old, mind t=
>his)
>        are nowhere to be seen. Functions like FindFirstVolumeMountPoint=
>
>        or GetVolumePathNamesForVolumeName.
>   2.3. No out-of-box support for lib files coming with SDK/DDK/IFS/WDK.=
>
>   2.4. No implib functionality so I cannot create up-to date lib files
>        from the dll files.
>
>I dig some more and found that there is coff2omf utility, which:
>  * produces incompatible lib files, if I want to use the available Borl=
>and  =
>
>one
>  * is not available free if I want to use the digital mars one
>  * actually do not work because it requires special version of
>  <b>Microsoft</b> link.exe that cannot be found anywhere.
>  So to use Digital Mars product, I must pay to Microsoft and pray
>  that I can found their very old linker somewhere in MSDN archives?
>I dig some more and found the special version of OpenWatcom wlink exe
>that can do the trick. And indeed, it did the trick.
>After about 5 hours fight with it, I was able to spell the right  =
>
>incantation
>that linked my 20 lines of D code.
>That includes special order of library paths so that Watcom's kernel32 i=
>s
>first and special order of libraries so that snn comes first.
>Really, a good job for starter in a completely new language and  =
>
>environment!
>D made me feel proud of myself. And I lost 5 hours but now I know why
>most people think programming is some kind of wizardry.
>If I opted for MS C++ I will be ready in less than a minute.
>If I opted for C# I will be ready in less than 20 minutes (I have other =
> =
>
>tests
>written in C# and I know the pattern).
>   And actually that cannot be called "productive". I now must support t=
>hree
>separate entities: D compiler, DigitalMars C compiler and OpenWatcom  =
>
>linker.
>And of course, for every project I start from now, I must build a bat fi=
>le
>and linker response file tailored for that project. No build.exe for me.=
>
>No simple dmd *.d my.lib my2.lib. Nothing like this.
>
>Ok, my programme is linked and I have an exe file. But as my ex-boss
>likes to say: "No-one should commit code in the source control system
>unless she had stepped through every one of the new code in the debugger=
>."
>I know that all the tools of D language & infrastructure are there to
>help me spend as little time in the debugger as possible.
>Tools like contracts, unit tests, code coverage etc.
>But only the debugger can tell you the flow of code.
>
>3. Where is the debugger?
>No near me, for sure.
>I hear "WinDbg" screamed, am I not?
>First, it does not come with D/dmd.
>Second, you must find it in the Microsoft site - not an easy task.
>Third, half an year earlier when WinDbg out of the blue got
>the docking windows and user interface that made it actually useful
>some of my colleague go out, bought some beer and celebrated it.
>Fourth, that WinDbg which is quite user-unfriendly does not work with D.=
>
>There are anecdotal evidence that version of WinDbg developed circa 1996=
>
>can be used but I'm not sure I want to touch this beast.
>   What other languages offer? Lua, Python & Ruby have built-in
>debugging facilities. VisualStudio have a debugger which can be extend to show your data the way you want it. The dotNet SDK comes with a debugger (and an excellent one). D simply does not have working debugger= .
>
>To proceed with other problems, I will leave our beautiful scene
>and go back in time to February 2005. In that time I had to do another
>little project. This time I was choosing between 3 languages:
>D, Lua and Io. I chose Lua because:
>
>4. Documentation
>Lua comes with the best book for a programming language I read so far
>in my life. It is called "Programming in Lua" and is available from
>http://www.lua.org/pil/. A book about a language gives a newbie a base
>to stand. It gave me confidence. D (and Io) do not have this. Languages =
> =
>
>like
>Python and Ruby come with "Programming Python" and "Programming Ruby" bo=
>oks
>in the zip files you download from their sites. A newbie is lost in the =
> =
>
>scarce
>documentation of D. "Programming Python/Ruby/Lua" gives you the boost to=
>  =
>
>start.
>I cannot stress how important is a good book for the newbie.
>Just go to the link I give and read the book. And then compare to D  =
>
>documents.
>
>5. Often changes of the compiler.
>This is a controversial issue. But please consider, how many versions of=
>  =
>
>dmd
>came from February till now? Even the projects in dsource.org cannot cat=
>ch
>with them. Core32 collides with current phobos. DFL notes that it is tes=
>ted
>with version 140 and the author cannot help if you use other version.
>Lua on the other side stays unchanged from 2001. Most of its bugs are
>documented and their solutions are known. Also, the new version that wil=
>l  =
>
>be
>out this week is known from half an year. Its new features are known. Yo=
>u  =
>
>can
>prepare for them (I am currently modifying my code to be ready for it an=
>d
>send patches to authors for bugs I encounter). D just announces new  =
>
>features
>and deprecation of old ones and leaves you to adapt.
>I can't build my projects on a base that slips and changes every month.
>I know Walter thinks of setting version 1.0 but that is in the future
>and can't help me now.
>
>
>Consider the "Major goals of D" and compare to what I said earlier:
>  * Reduce software development costs by at least 10% - losing 5 hours j=
>ust
>  to link a simple 20 lines programme won't reduce the cost of its  =
>
>development.
>  The requirements for 3rd party tools (namely Microsoft linker, OpenWat=
>com
>  suite) and 4th party tools (the patched wlink for DMC) make the situat=
>ion
>  as bad as possible.
>  * Provide low level bare metal access as required - it is not even nea=
>r,
>  as I really need access to ntdll.dll (the lowest level to bare metal
>  in user mode available) and D actively hinders me.
>  * Be compatible with the local C application binary interface - Micros=
>oft
>  tools are de facto standard for Windows platform and D does not talk t=
>o  =
>
>them.
>
>
>To conclude, language D is a daydream coming true to every  =
>
>C/C++ programmer.
>But what D as language gives, D as infrastructure takes tenfolds.
>I admit all the problems I presented are not unresolvable,
>the big problem is that I must resolve or work around them before doing =
>any
>actual work. Also I know about projects like Poseidon or D Forms Library=
>
>which prove that D is useful. All I state is that D is not useful for me=
>
>in its current form. And I think that the problems I have are applicable=
>
>to other people too. Also it is possible that I mis-read the documentati=
>on
>and there is an easy way to do what I do and I simply didn't found it.
>But I read as much as I can, searched in the newsgroup archives and
>I think I made the best possible effort to do the things right.
>Last, I know some of the problems are hard to solve.
>Microsoft keeps interface of mspdb??.dll files for themselves so noone c=
>an
>easily produce pdb files in the new format. And it is not redistributabl=
>e.
>I know that writing a book is a demanding task that often requires more =
> =
>
>than year
>to complete. I thought of creating a module that in its contructor  =
>
>dynamically binds
>to functions in ntdll & write simple wrappers in D. Et cetera.
>I read the newsgroups since version 0.96 or .98 (can't remember exactly)=
>.
>I'm a competent Windows developer and if Poseidon turns a good IDE I can=
>
>try to write a decent wrapper around dbghelp.dll to help build a proper debugger. But now I feel that infrastructure of D have a room for  =
>
>improvements.
>
>Regards,
>Todor Totev

   Hello all,
to make my point clear, I present you a simple task:

Build a programme that discovers where boot.ini file resides and prints its contents on the screen.

For all that don't know, boot.ini file resides on the system partition of
Windows NT & up
and tells the system loader from where it can boot the OS.

For all that think that this is not a "typical" task, I will answer that
this summer I had not only to
do this but also to MODIFY boot.ini. And I have limited time to do this.
Yes, I'm a system programmer - for my living I write drivers,
WMI providers, and Windows services all of which runs on Windows
2000/XP/2003.

I attach the solution I forged in D. Please, disregard the quality of the
D portion of code -
this is my first programme in D so I'm sure it can be improved.

You can compile, link, run the program & enjoy the results.
I will post as replays to this message some hints of what must be done.
If you want to check how much time you need to run this programme, don't
read them.

You must know that you need kernel32.lib advapi32.lib & ntdll.lib which
corresponds to
Windows 2000 system dlls to successfully build the code.

Enjoy,
Todor

Problem 1: where is the damned ntdll.lib?

Solutions:

1. Digital mars one - use implib on ntdll.dll in your system folder and
make sure the resulted lib will work with windows 2000,XP,2003.

2. Official one - get Microsoft DDK and use the provided official import library ntdll.lib -
this is what I tried to do from the beginning but will cost you some $ if you do not have already one

3. The poor bastard that just whants to play with D one -
download Open Watcom form www.openwatcom.org and use the ntdll.lib from
\watcom\lib386\nt

4. The hacker one - modify the source until it compiles & links

Please tell me which route you take and how much time you need to finish it.

Enjoy the show,
Todor

  Hello all,
after I had read your oppinions I decided to make myself as clear as
possible.
First, I posted after I successfully compiled, linked & executed my test
programme. Second, from the beginning I was trying to prove that D is
excellent as a system programming language. Not application programming
but system programming.

According to Wikipedia (http://en.wikipedia.org/wiki/System_programming):
...the programmer will make assumptions about the hardware and other
properties of the system that the program runs on, and will often exploit
those properties (for example by using an algorithm that is known to be
efficient when used with specific hardware.

> If you're referring to your "Problem with COFF library" post, then I'd

As I stated, I published my thoughts after I found solution of all engineering
problems I encounter. The solution is within article
http://www.digitalmars.com/d/archives/digitalmars/D/9911.html.
I just didn't realized this at the time I posted that request.


> You don't need to link your Python or Ruby executable to kernel32.lib or gdi32.lib, because the interpreter that runs your Python/Ruby program is already linked to those.
Actually every single process in Windows have access to ntdll.dll
simply because this library is mapped in the process address space even
before the exe file is being read - actually a code inside ntdll is
responsible for starting the process :-) No excuse for D.

See http://www.digitalmars.com/d/overview.html:
"D is a general purpose systems  programming language."
I really think that such a language should give me easy access to the
platform.

>> 2. D is the only language which aims at system programming and in the same time cannot inter-operate with the operating system.
>>   2.1. No easy support for importing Windows types & functions not
>>        included by default within Phobos.
>
> D is not a platform-dependent language.  You are referring to the D infrastructure here, specific to the Windows platform.  It is not the purpose of Phobos to become a transparent gateway to the raw Windows API.  Yes, admittedly, phobos' Windows support is lacking.
>

Again:
"D is a general purpose systems programming language."
I trust in the intends of language's author and state that it is not
ready for it.

>> Want to easily convert a .h file to .d? Yes of course! Not with D.

I really regret for my particular choise of words.
What I really complain is that Phobos only partially defines very basic
Windows types AND in the same time Core32 which is supposed to complement it
actually clashes with it. So I had to resolve both issues.
Another problem is that I can patch these but a long-term resolution is to
fix them inside phobos & core32.
Of course, I'll send what I discovered to Walter and maintainers of core32.

>>        Plain old, boring Windows 2000/XP functions (5 years old, mind this)
>>        are nowhere to be seen. Functions like FindFirstVolumeMountPoint
>>        or GetVolumePathNamesForVolumeName.
>>   2.3. No out-of-box support for lib files coming with SDK/DDK/IFS/WDK.
>>   2.4. No implib functionality so I cannot create up-to date lib files
>>        from the dll files.

Again I want to stress that these issues make system programming with D
near to impossible.

> If you didn't know, the SDK, DDK, IFS, WDK, whatever from Microsoft are all proprietary development kits which must be purchased and licensed at hefty costs.  I'm no legal expert, but knowing Microsoft there is probably a high barrier to entry for compilers wanting to fully support the Windows platforms.

I'm the person responsible for MSDN subscription in our firm.
SDK costs 0$ - it is freely available for download.
DDK is free for MSDN subscribers.
IFS costs 900$ but nearly noone needs it.
MSDN subscription does cost some money but I cannot imagine a serious
development for Windows platform without this.

> I certainly wouldn't expect, let alone demand, from Walter that he shell out cash in the neighborhood of 5-6 figures to Microsoft to get such support for his compiler.
>

Neither I. Walter provides compiler & linker. He surelly does not need
DDK, unless he decides to prove that compiler can be written as a device
driver (humourous note).
It is I who need to bridge D & DDK. And I do have the DDK.
The problem is that I cannot use it with D because optlink does not
understands COFF libraries.
Also, OpenWatcom does understand COFF files in general and MS supplied
ones in particular out of the box. While Optlink can't?

>> I dig some more and found that there is coff2omf utility, which:
>>  * produces incompatible lib files, if I want to use the available Borland one
>

Answer:
http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/24468

>>  * is not available free if I want to use the digital mars one
>
> Digital Mars has to make their income somehow.  The utility CD is $15. Sacrifice a night out at the movies (which is most likely to be > $15) and grab your copy.  This is incomparable to what Microsoft would charge you for their compiler toolset.

The reason I don't wnat to purchase this cd is:
* I do not have credit card.
* Things tend to dissapear in Bulgarian customs - i.e. last month
there was a big scandal because two customs officers have stollen the
cell phone of the american ambassador while he was checked with metal detector.
I still wait for my Ubuntu cds. Although a colleague of mine received his
DVDs so apparently this is related to man's luck.

>>  * actually do not work because it requires special version of
>>  <b>Microsoft</b> link.exe that cannot be found anywhere.
>>  So to use Digital Mars product, I must pay to Microsoft and pray
>>  that I can found their very old linker somewhere in MSDN archives?
>
> Again, I'm not sure what you'd need this old LINK utility for?  If you use the Digital Mars toolset CD (available for $15 as noted above), then you wouldn't have to delve into these murky waters.  I could be wrong, since I'm not clear on your intentions here.

Answer:
http://www.digitalmars.com/ctg/coff2omf.html
clearly states: use microsoft linker.
The Microsoft linker I have access to complains that it does not know the
option /convert so it is useless.

>
>> I dig some more and found the special version of OpenWatcom wlink exe
>> that can do the trick. And indeed, it did the trick.
>
> I'm happy to hear you persevered and got your solution, but still I believe things might've worked better by just using the readily available Digital Mars toolset.

See the reply above.


>
> Besides, this COFF and OMF format thing is hardly Digital Mars' fault. Microsoft went their own way, invented their own standard, and closed the books on it so hardly anyone else could come and share.  This doesn't sound like a standard to me.

Answer:
http://www-128.ibm.com/developerworks/power/library/pa-spec12/?ca=dgr-lnxw07ELFHero
(look for "Microsoft's PE-COFF was another standard they documented.").
Also, OpenWatcom & Borland support Microsoft COFF files directly.
So I think this indeed is Optlink fault.

>
>> If I opted for MS C++ I will be ready in less than a minute.
>
> Well of course, since MS C++ is the same MS that gave you Windows.  It's not Digital Mars Windows XP, now is it? =)  Also, you'd be out $750.

From http://msdn.microsoft.com/vstudio/express/visualc/
you can download a free version of VS2005 that both
works out-of-box with SDk and does have a debugger (a very nice one).
According to Mattew Wilson (http://synesis.com.au/software/stlsoft/compilers.html):
Prior to version 7.1, the Visual C++ compiler had a number of issues with respect
to language conformance and robustness, but now is one of the leaders in compiler
conformance and quality. Their <b>outstanding</b> IDE has very few competitors in
the marketplace.

>> If I opted for C# I will be ready in less than 20 minutes
>
> That's funny that C# takes longer for you than C++?

Because I must translate c .h files to [DllImport] attributes
and make some structs. Basically exactly what I did to make D source.

>>   And actually that cannot be called "productive". I now must support three
>> separate entities: D compiler, DigitalMars C compiler and OpenWatcom  linker.
>> And of course, for every project I start from now, I must build a bat file
>> and linker response file tailored for that project. No build.exe for me.
>> No simple dmd *.d my.lib my2.lib. Nothing like this.
>
> Derek Parnell's 'build' utility (available also on dsource.org) will get you headed in the right direction here.

According to the site, build does not know how to handle wlink.
And my patchy solution relies on OpenWatcom's wlink.
Besides, it is very interesting that on my complain
"No build.exe for me." you responded with "Use build".

>
>> Ok, my programme is linked and I have an exe file. But as my ex-boss
>> likes to say: "No-one should commit code in the source control system
>> unless she had stepped through every one of the new code in the debugger."
>
> While your ex-boss may be a wise man stating this, it shouldn't be a strict requirement that all code must be stepped-through in a debugger in order to be bug-free.  True, it may catch many uncaught bugs, but this is what (and you realize this) the tools the language provides to you should help to eliminate.

Please make a multithreaded windows service that runs under LocalSystem account
and synchronizes itself with another survice that runs under user account
right from the first time without using the debugger.
After that write a book about how did you achieved this and I will buy it.
I realy do things like thouse to earn my money so I'm touchy on that subject.

>
>> 3. Where is the debugger?
>> No near me, for sure.
>> I hear "WinDbg" screamed, am I not?
>
> First off, again you're assuming Windows platform here.  GDC and GDB are perfectly acceptable alternatives.

Sure, but I need Windows 2000. If GDC can handle this, why not?
Remember, I am system programmer doing system programming.

>
>> First, it does not come with D/dmd.
>
> Nor should it, because it is not a Digital Mars product.

But comes with Utility CD? Pardon me?

>
>> Second, you must find it in the Microsoft site - not an easy task.
>
> This is Microsoft's fault alone.  Personally, I think it isn't all that hard to find.  Your milage may (and did) vary, of course.
>
>> Third, half an year earlier when WinDbg out of the blue got
>> the docking windows and user interface that made it actually useful
>> some of my colleague go out, bought some beer and celebrated it.
>
> Slapping a GUI onto a tool does not instantly make it "actually useful".   It *might* make it more user-friendly and manageable, but the old tool was just as useful.
>

All these points are valid but did not change the thing that debugger
is badly needed by the programmer and D does not have a easy to discover one.

>> Fourth, that WinDbg which is quite user-unfriendly does not work with D.
>
> If you mean that it doesn't work with D in that you can't peek at local variables' contents, then I should state that this is a problem with Microsoft's tools sporting their proprietary PDB file format.

In the example I provided in another post 100% of programme's state is inside
local variables. Debugger that hides 100% of program state is not useful one.
Of course this is Microsoft problem, as I admitted at end of my post.

>>   What other languages offer? Lua, Python & Ruby have built-in
>> debugging facilities. VisualStudio have a debugger which can be extend
>> to show your data the way you want it. The dotNet SDK comes with a
>> debugger (and an excellent one). D simply does not have working debugger.
>
> None of these languages are 'systems programming' languages.

I use VisualStudio C++ to develop device drivers. Are you sure that
this do not count as system language? Also the user interface of the
products I develop is written using C#. As its sole purpose is to tweak
the driver's behaviour it is indeed system software.
So C# is also system programming language.

I wnated to state that every language must have a built-in debugging facilities
to be useful. Actually the selling point of D is its debugging features.
Also both OpenWatcom and free Borland tools come with debugger.
And they are C++ compilers.

> They work through bytecode and interpretation (or JIT compilation) which make it significantly easier to debug and step-through.

Not for the way I use C++.

> I believe a D debugger project is in the works on dsource.org (dbug?) but I haven't tried it myself.

The current state of dbug is:
http://www.dsource.org/forums/viewtopic.php?t=1009
"you can set breakpoints by clicking on the leftmost margin in
the source windows - removing breakpoints isnt finished and its
getting an exception trying to resume from a breakpoint"
Not useful to me.

> D is assuming a solid understanding of C and [C++ or OOP in general] as a start for learning D.

Completely wrong. D requires from you to learn D and not C/C++.
What need of C you have to learn OOP or template metaprogramming?
Do the messy RTTI of C++ helps you to work with D's one?
Probably the fact that C does not know how large is int really
helps you to learn using the base types of D?
Et cetera, et cetera.


While a book would be great for the
> business-oriented newbie who is being paid to be trained in the language, I believe there is no substitue for raw experience gained while tinkering with the language.

Never been in paid to be trained in a language and can't talk for this.
The books help the programmer to get this experience so there is no
substitusion for them. I tried to learn how dotNet framework works
reading MSDN and I understood nothing. I read a book for newbies
and learned how to ask questions and where to look for answers
(I mean that I learned about System.Runtime.InteropServices,
System.Management etc namespaces and was able to figure out in MSDN
what to do to achieve my goals).

Once you have the basics down, go
> ahead and read the reference books/docs to find out what you may have missed in your tinkering sessions.

Completely opposite: Please go to the site of Lua and check the reference manual
(what D have) and Programming in Lua book. You can decide for yourself what
you want to use to begin learning a new language - the interpreter, the manual
or the book.

>>  The requirements for 3rd party tools (namely Microsoft linker, OpenWatcom suite) and 4th party tools (the patched wlink for DMC) make the situation as bad as possible.
>
> These are not requirements for regular development.
My regular development includes inter-operating with the OS at low levels.
I cannot write a notepad-type application without some serious help
or a framework but I can write a basic WMI provider for less than a hour.
YMMV.

>
>>  * Provide low level bare metal access as required - it is not even near,
>>  as I really need access to ntdll.dll (the lowest level to bare metal
>>  in user mode available) and D actively hinders me.
>
> Bare-metal access does not mean access to operating system libraries. It means that the code will run on the native processor without requiring an interpreter or JIT compiler.

Obvously you dont know that Win32 API is the ultimate virtual machine.
It is there to shield the programmer from the NT and presents her a
comfortable, compatible with 16 bit Windows, API.
If you escape its confines you can create files with names that
contains embedded zeroes, or that differs only by case of letters, etc.
Most of the functions inside kernel32/advapi32 either do the work
without going to the OS level or simply convert ASCIIZ to counted strings
and ANSI to UNICODE and gives them to the real OS to process them.
This looks like a tipical behaviour of a VM to me.

>
>>  * Be compatible with the local C application binary interface - Microsoft tools are de facto standard for Windows platform andD does not talk to them.
>
> Microsoft tools were made to force a de facto standard on the Windows platform because they use and integrate so well their own proprietary technologies to keep others out.

Dmd is a proprietary technology so you cannot blame MS doing the same thing.

Lets give you a hipotetical example. You develop a text editor that
implements "search in files" functionality.
Look at this code:

import std.recls;
import std.stdio;

void main()
{
  Search s = new Search(null, "*",
    RECLS_FLAG.RECLS_F_RECURSIVE|RECLS_FLAG.RECLS_F_DIRECTORIES);
  foreach (Entry e; s)
    writefln(e.GetPath());
}

Do you see the problem?
Alice as an advanced user had made hard links in her file system.
But the problem is that one of the hard link goes UP in the file system
thus if blindly followed forms a never-ending cycle.
One can recreate the Alice setup using a tool from
http://www.sysinternals.com/utilities/junction.html
You can do this yourself and enjoy the show.
After that come back and tell again that you do not need to
inter-operate with your OS.

> If you had made a case developing for Linux using either the Linux version of DMD or the GDC front-end for GCC, I'm sure your experience would have been much more enjoyable.

Windows 2000. It's what concerns me.

> To be fair, use the tools that are right for the job.  D might not be right for your current project, at the current time.  Don't overgeneralize to everyone else stating that D is a completely useless language in all areas of development.
>
Consider the native string type:
struct UNICODE_STRING {
    USHORT Length;
    USHORT MaximumLength;
    PWSTR Buffer;
}
Now look at D dynamic wchar array
struct {
  uint size;
  wchar* ptr;
}

Do you see the resemblance? Both are counted strings and as such
do not need trailing zero. Both are happy with embedded zeroes.
Both use UTF-16. D IS the best choice for the job.
The compiler is flawless! The Optlink is the guardian sitting
between me and my eternal happiness...
And if there is a statement in my post that can be interpreted
as "D is a completely useless language in all areas of development"
then I really regret for the choice of words.
All I state is that Dmd is very hard to be used as system programming
language.

Thanks for your profound replay, I hope I made myself more clear
on what my problems are.

Regards,
Todor