Up until recently I’d used Subversion to store all my vim (and other) configuration files. This is a reasonably common practice. But I’ve had two issues with this approach. First, I had a few makefiles (or batch files for Windows) that I used to sync the contents of the repository to to appropriate locations on each type of machine. I did this largely to keep my home directories clean, but having to maintain them — even in a limited capacity — was obnoxious. Second, I had to remember to actually commit any changes I made back to the central repository. On a number of occasions I made some tweak at work, went home, and realized I’d failed to commit. A minor annoyance, but an annoyance nonetheless.

This is why I decided to try storing the configuration using Dropbox. Since Dropbox storage is accessible like a local directory, I could easily create symbolic links to the .vimrc file and .vim directories stored in my Dropbox drive on all my machines. This means I don’t have to manually commit any local changes back to the repository. It also obviates the need for the synchronization makefiles; while they provided a bit of a buffer for changes, which was occasionally nice, they existed largely to keep the temporary cruft created by a Subversion working copy out of my home directories. That’s not a problem with Dropbox.

So far I’ve had no trouble using this approach, and the additional streamlining is a huge boon. I was very pleased, in particular, that the symlinks worked out so well. My fallback was to create shim .vimrcs that set $VIMRUNTIME and sourced the Dropbox version of the file, but fortunately I didn’t need to.

Also, in an effort to try and get a better sense of our users and community, we’ve put together this quick SlimDX developer survey and would appreciate your time in filling it out if you use, have used, or are considering using SlimDX for anything.

Finally, we’ve received several queries through various channels about contributing to SlimDX, especially the upcoming version 2.0 redesign. If you are at all interested in participating in or simply observing the discussions about the redesign, you should join the slimdx-devel mailing list.

We arrived, all dressed up, shortly before our 8PM reservation. The valet took my car without giving me a ticket — one of the things the staff is known for is their ability to operate their valet service smoothly without such pedestrian aides as tickets — and we were promptly shown to our table. We were seated on the opposite side of the dining room from the main windows, and there was another party at a table between us and the view. However, the windows were large enough that we still were able to see out across Lake Union, and we were near the kitchen (which I always enjoy).

We were there for the three-course dinner offered as part of the Seattle Restaurant Week promotion, and since there were two of us and two options for each course we were able to experience everything on the menu. I carelessly left my phone in my car, so credit for all of these wonderful photos must go to the lovely Ms. Clark:

A wine pairing was offered to accompany each dish; we both ordered it, but since I have a terrible memory for wine I couldn’t really tell you much about it. All of it was awesome, though, especially the dessert wine — which isn’t something I normally enjoy. The service was excellent, and the staff was attentive and responsive, very knowledgeable about the food and preparation. We only had to suffer through one minor delay, just before placing our order, but given how busy the dining room was that evening I was not terribly bothered and our server’s affable mood more than made up for it.

In addition to the items on the menu, we were served a small cup of gazpacho as an amuse bouche and pair of wonderful petit fours along with the coffee we had after dessert. Once the meal was concluded, our server took us on a quick tour of the restaurant, showing us the various private dining rooms that were not currently in use, and offering a lot of interesting information about the history of the Canlis family and the restaurant itself. At the conclusion of the tour, somebody was waiting with Katie’s coat and my car was ready outside. Impressive.

Despite the upscale dress code, ironed tablecloths, and general air of “fancy,” the atmosphere of the restaurant wasn’t stuffy — they take your dining experience seriously, but not so seriously as to make you worry about stepping out of line. You can get an idea of the attitude of the place by taking a look at the light humor on their Q&A page.

I will definitely make the time to go again.

A C-style string is just an interpretation of an actual type (a char*) that adds some additional semantics. These semantics are not enforced by the language, except implicitly and very poorly via some C library functions. This approach, which presumably grew out of the “pay for what you use” mentality, is a huge part of what makes C-style strings cumbersome and error-prone.

That topic is how we’re not going to use IDisposable any longer.

More specifically, we’re not going to use it as much. Almost every SlimDX 1 object implements IDisposable, because IDisposable is all about cleaning up unmanaged resources and SlimDX objects are, for the most part, exactly that. But the sort of resources IDisposable is geared towards are those with very explicit lifetimes: you create it, do your thing, and then Dispose() of it. C# using-blocks allow you to implement this exact pattern for locally-held objects quite efficiently.

Long-time readers will recall that our IDisposable wrappers around COM objects have caused us a lot of trouble in the past, largely because the interface’s contract does not really jive with COM’s reference counting. To account for this, we implemented an object table based loosely on the same principles that the .NET RCW uses — specifically, we tried to maintain exactly one COM reference to any object known to SlimDX so that we could do the correct thing when Dispose() was called. This eventually led us to an overly-complicated system burdened with multiple creation code paths and inconsistent ownership semantics.

Our solution is to, essentially, side-step the issue entirely and just expose the reference counting directly. All SlimDX 2 objects that are backed by actual COM interfaces implement IComObject, which provides the familiar-looking methods AddReference() and Release(). For the trivial scenarios where you just want quick, scoped access to a COM object, we’ll be providing a simple IDisposable utility wrapper you can use in conjunction with a using-block to automatically drop the reference count when appropriate.

While it first might seem like this change is a step backwards, we think that it’s an improvement in the long run: it obviates the need for the exceedingly complex object ownership rules that existed with SlimDX 1 (which, we suspect, most of our users were getting wrong). Plus, it makes the SlimDX ownership semantics match those of the already-familiar native API.

In any event, the purpose of Ada Lovelace Day is to write a post celebrating the achievements of women (or a particular woman) in the technology industry and thus, I would like to call out Tess Ferrandez, ASP.NET escalation engineer extraordinaire.

But this post isn’t about Ferrandez’s achievements in the domain of ASP.NET, specifically. Instead, this is about commending her for her work in educating the development community about debugging in the .NET environment. Ferrandez has been at Microsoft for more than a decade, working with .NET technology since it was in alpha, and offering her knowledge to the community at large through blog posts, podcasts, interviews and by speaking at conferences. She often discusses techniques for diagnosing obscure bugs or memory issues, providing great insight into the tools used or the systems affected — and she’s always informative, easy to follow, and extremely helpful.

I, personally, can attribute the entirety of my understanding of WinDbg and SOS directly to her, as well as a good portion of my understanding of the .NET internals. I am certainly not the only developer to have benefited from her work. So I want to congratulate you, Tess Ferrandez, on what I feel is the greatest achievement of all: teaching others through your own wisdom and experience.

I particularly enjoyed this post. Back in 2007, when SlimDX was a young API, we had the luxury of having very few serious users. When we realized we’d screwed something up, we just changed it, and it didn’t matter how much that change would impact a client code. There were no clients.

But now, three years later, that’s no longer the case. We have quite a few users; SlimDX has been used in commercially released games and applications, and helps power internal content production tools used by professional studios like Zipper Interactive. We no longer have the luxury of implementing sweeping changes on a whim, no matter how correct they may be. We have practical realities to consider: providing sufficient advance warning and documentation. Developing upgrade paths. Transitioning deprecated versions of the API to “support mode” for an appropriate period of time.

I believe that breaking changes are for the best when they actually improve the overall health of the API. But they’re also pretty scary.

The primary motivation for organizing the library in this fashion was to eliminate the problems with building “Any CPU” applications using SlimDX.

Managed applications built in “Any CPU” mode are essentially asking the CLR to load them as processes most-appropriate to the host machine: if you’re running on the x64 architecture, you get a 64-bit process. On x86, you’d get a 32-bit process.

For native code, however, the target architecture needs to be decided at compile-time, which is why there are distinct 32-bit and 64-bit versions of the SlimDX assembly. Unfortunately, you cannot load a 32-bit DLL into a 64-bit process.

If you’re using the copies of SlimDX that our installer places in the GAC, you can avoid running afoul of this problem by editing your .csproj. If you’re a user who prefers to reference the SlimDX DLLs themselves, you are out of luck. You have to pick a specific version to reference, and you have to set the machine type of your project to match.

By using a two-part distribution, we can ship a public assembly configured for “Any CPU” use. This assembly can detect whether 32- or 64-bit code would be more appropriate and load the correct private implementation DLL into your process.

This approach also allows us to write more of SlimDX in C#, which is far more pleasant language to work with than C++/CLI, and has a much better toolchain.

It also lets us improve the health of the code we do need to write in C++/CLI. Because of a peculiarity in how templates (not generics) interact with managed types, the presence of a template type anywhere in a class hierarchy results in a complete lack of IntelliSense support for that class hierarchy… but there’s a lot of redundant boilerplate code in SlimDX, exactly the kind of code one would like to use templates to write just once. We had to compromise and use macros to provide that code for SlimDX 1.

However, with the split-assembly approach — along with with our adoption of interfaces — the classes “polluted” by templates exist entirely in the private assembly and are never exposed by their concrete types; the lack of IntelliSense becomes a non-issue.

There is one small downside, unfortunately. Since the implementation DLL is loaded manually, clients who reference and ship private copies of SlimDX (that is, anyone not using the GAC version) will need to add or link the SlimDX implementation DLLs (and PDBs) in their .csproj files in order to allow the build system to copy those files into the directory of the built application.

The first is the question of how one initially obtains an interface. SlimDX 1 uses the constructors of its concrete objects to enable users to obtain new instances. Thus, in SlimDX 1 you would obtain a texture instance by doing new Texture2D( device, … ). This constructor will invoke the native ID3D10Device::CreateTexture(). In SlimDX 2, we’ll present a model that mirrors the native interface more closely, with an IDevice interface that demands a CreateTexture method.

To handle bootstrapping — obtaining that first interface — we’ll expose so-called “API objects” that will represent each of the primary subsystems SlimDX exposes to native code (for example, there will be a Direct3D10Api object that will let you obtain the initial D3D10 device interface. These API objects will also be a convenient location to present many of the native free functions. SlimDX doesn’t expose all of these now, and the ones it does provide are often tucked away, seldom-seen static members of one class or another.

The other half of the problem is translating those interfaces back into concrete, usable objects when they are passed back to SlimDX for one reason or another.

We could simply downcast the interface to the concrete type, but that relies on the assumption that such a cast would always succeed — and that isn’t true in general. SlimDX has always supported interoperation with other DirectX-wrapping managed libraries, and to make the assumption that our interfaces were only ever implemented by our own library would work against that.

Fortunately, as a result of that interoperability feature, we’ve had to have all of our objects expose their IUnknown or similar native pointer (wrapped up in a System.IntPtr). Thus, we can rely on an accessor for that pointer being available from the interfaces, and we can use that to obtain the actual interface we’re interested in working with in the SlimDX code.