Windows Service in the D Programming Language

Nine months ago I blogged about my curiosity about the D programming language. It is possible that this curiosity is turning into a hobby. Time will tell. Recently I decided to create a Windows Service written in the D programming language. I’ll share my journey to that end here.

When I started I assumed it would be easy to find examples in the open source world from which I could learn. That assumption turned out to be mostly false. I found some posts on the forum that were helpful. I then dug up an email address using that famously free detective, Google. Graham Fawcett was very helpful in sharing some code with me but for some reason I could not get it to work.

After a week or more of evenings attempting to find a solution, I gave up and offered a bounty on the forum. And Vladimir Panteleev, a regular D community contributor, came to my rescue and gladly took the $100 bounty to be applied toward other issues he would like to see resolved. My deep thanks to both of these community members.

As it turns out, the code that Graham shared with me would have worked except the Win32 bindings code had an x64 bug that would not have manifested itself had I been compiling for x86. Specifically, the winsvc.d code file contained the line:


I took Vladimir’s advice and changed it to:


And then later pulled in his final fix as;


I won’t try to explain the differences here. In any case, the handle in x64 world needed to be a ulong and it was getting declared as a uint (C# equivalents here). And once that was resolved, I was very happy to see the code work.

You can get or read the code for that first success on GitHub. I refactored that code using a reference app in C++ that followed a familiar pattern having written many Windows Service in C#, even to the point of writing a short cut to standing up a Windows Service in .NET.

In any case, if you are curious to see my first real foray into the world of D programming, you can check out the code on GitHub. It even includes a minor improvement suggested by a forum member already. And if you have questions or need help, please leave a comment and I will do my best to help.

DMD x64 with Visual D in Visual Studio 2013 on Windows 8.1

About ten days ago, I installed the latest Visual D from GitHub and ran into some problems when trying out the DMD/GDC console application to use the “DMD | x64” config to compile a simple console app as an x64 native Windows application.

While I have not yet tested it, I believe the installer would have worked out of the box on my Windows 7 machine. But on my Windows 8.1 laptop, I had some trouble. Rather than boring you with all the things I tried, I will just share what finally worked for me.

Here’s the console app code I was working with:

import std.stdio;

int main(string[] argv)
    writeln("Hello D-World!");
    return 0;

I had downloaded and installed Visual D with VisualD-v0.3.37.exe. I had also downloaded and installed the latest DMD compiler from In the process of figuring things out, I also reinstalled Visual D.

In Visual Studio, I created a new DMD/GDC console app from the D Language tab in the new project dialog. This console app template comes preconfigured with a configuration called "Debug DMD|x64" and I switched to that. But when I hit F6 to build, I would get the following error:

------ Build started: Project: ConsoleApp1, Configuration: Debug DMD x64 ------
Building Debug DMD x64\ConsoleApp1.exe...
LINK : fatal error LNK1181: cannot open input file 'user32.lib'
Building Debug DMD x64\ConsoleApp1.exe failed!

After doing some browsing and searching, I found the known issues page and the fix described on the page did not work but it did lead me to do some more digging and experimenting until I found that modifying the sc.ini file with some very specific changes solved the problem. Here are the relevant lines, as modified, in my sc.ini file that finally made it possible for my little program to compile. (update—only the Environment64 changes are required—while Rainer Scheutze suggests that the paths can be modifed in Visual Studio, I’ve not been able to make that work).

   ; original LIB="%@P%\..\lib64"
   LIB="%@P%\..\lib64";\dm\lib;"C:\Program Files (x86)\Windows Kits\8.0\Lib\win8\um\x64";%DMD_LIB%

This post will be my saved notes for the next time I have to configure a Windows 8.1 machine for D programming language in Visual Studio 2013 (and beyond). And I hope you find it useful too.

Diversions in the D Programming Language

I am not a systems programmer, meaning I do not write operating system device drivers or file systems or operating system modules, etc, all written in a language that will compile down to raw machine code. I write in C# primarily which is arguably an applications programming language, running in the much loved .NET Common Language Runtime.

The vast majority of systems programming is done in C and C++. And for some reason, C++ has always been a daunting mess of libraries, odd syntax and pointer and memory allocation madness to me. Even setting up an environment to get the right build libraries, the right compiler and linker, etc., have always led me to fits of impatience. And for that reason and many others, I have stuck to C# and applications development.

But every once in a while, I look in on systems programming to see if anyone has really solved the problems I love to hate with respect to C and C++. And for a few years I’ve read a little about the D programming language here and there. A week ago, over the weekend, I decided to give it a try and really see what I could learn.

I have to say, I have been impressed. The D programming language offers a few things that I would dearly love to see in C#.

1. Exception Safety – the scope keyword

void abc() 
  auto resource = getresource();  // acquire some resource 
  scope(exit) resource.close();   // close the resource 
  doSomeProcessing();             // do processing

As C# programmers, we’re used to the try..catch..finally blocks. And we clean up a resource in the finally block. The trouble with that is many lines of code can end up separating your resource acquisition code from your resource cleanup code. Yes, with vigilance and well written tests, this is okay. But wouldn’t it be cool to be able to tell the compiler, “Hey, when I’m done with this thing I just now created, clean it up for me, no matter what code comes after this in this method.” I would love to see the scope keyword added to C#.

2. Concurrency approach

int perThread;
shared int PerProcess;

In C#, when you declare a class level variable, it is automatically shared between threads. You can use the [ThreadStatic] attribute to get a per thread instance of a given value or object. But it then has to be static. With the D programming language, you get thread safety in class variables. To override that safety, you have to explicitly tell the compiler you want the value shared. While I’m not advocating a change to C# in this regard, I would love to have a way to assure that a variable cannot be modified across thread boundaries.

3. Message based threads

import std.concurrency, std.stdio;
void main() {
   auto low = 0, high = 100;
   auto tid = spawn(&writer);
   foreach (i; low .. high) {
      writeln("Main thread: ", i);
      tid.send(thisTid, i);
      enforce(receiveOnly!Tid() == tid);

void writer() {
   for (;;) {
      auto msg = receiveOnly!(Tid, int)();
      writeln("Secondary thread: ", msg[1]);

For me, this is perhaps the coolest part of the D programming language’s base class library which they call Phobos. Note that main spawns a thread calling writer. The loop in main then sends a message to writer and the loop in writer receives the messages and operates on them and then sends a message back to the original thread.

You can learn a lot about D on and read more about D concurrency on Informit. And if you want to play with D in Visual Studio, hop on over to see VisualD on