Never buy open headphones for office use. They may sound excellent, may be comfortable and may allow you to hear if someone calls you, but one day you will run into issues: if you listen them quietly enough to not to bother your coworkers, you will hear the neighbor knocking on the wall with a hammer. That’s not mere speculation, but an actual experience that I am having since 8:00AM this morning.

It has been quite a long time since I last posted to Vamsoft Insider and I have no good excuse, other than loads of work, but that is absolutely usual here and everywhere. I think the reason is like with emails that you never respond: the more you delay a response is the less you want to respond. I am not sure why is it so, I guess the delay changes the attitude towards the given activity: as fun turns into unwanted obligation, motivation falls sharply. So let this post be an attempt to overcome this.

A few weeks ago we released the first beta of ORF 3.0 and it works great, thank to the efforts of the ORF Feature Test Program members, who identified lots of the bugs in the intermediate releases. If you are not familiar with this program, here is a brief summary: a bunch of great guys volunteer to risk their emails by testing intermediate releases of the upcoming version. Most of them do this on their live system. Without these brave souls, beta users would have a much harder time testing ORF.

Beta testers also caught two more bugs and now we consider the code base stable enough to release ORF 3.0, so once we get the documentation back from Dave (the guy who fixes our funny English “accent”), we can do the release. If this happens before Wednesday, 3.0 will be announced next week. (If you are wondering why, the reason is simple: our internal policy is to not to release new versions after Wednesday, because this way we can provide faster technical support for early adopters and we can react if something goes wrong).

I cannot wait to get 3.0 shipped. It is a great (and rather anxious) moment when you have everything compiled, tested, signed, updated, uploaded and the only thing left on the checklist is “Send the announcement”. You get another café latte, hit the Send button, sit back and watch how emails are flowing out to our clients in 81 countries. It’s a great energy booster: you are finally done with months of work and you can focus on what comes next. And this time we have lot coming!

Every once in a while, somebody asks me if ORF will work under Exchange 12. My regular response is something (admittedly) obscure like “There are technical challenges that have to be solved first. Current versions of ORF surely will not run work with Exchange 12.”. It is obscure because I am not sure what is the best way to work around those “technical challenges”. Let me explain why.

Exchange 12 will run on 64-bit Windows only. 64-bit is good. 64 is twice as much as 32 and Microsoft knows this :) Alas, even though ORF agrees, it does not run on 64-bit Windows.

As you might know, ORF integrates with the IIS SMTP Server to perform filtering. This integration is done using a Microsoft-provided thing called Protocol Event Sinks, which allows third-party developers to hook specific events of the mail delivery and run their own code. (By the way, Exchange does the same).

Now the trick here is that IIS on 64-bit Windows is a native 64-bit application. This is great, because it can take advantage of the 64-bit power. On the other hand, it is pretty bad, because native 64-bit applications cannot load native 32-bit DLLs. Guess what—ORF is still 32-bit. And it will remain so for a long time.

Why can’t we just recompile ORF to 64-bit? That is an easy one. ORF was written in Borland Delphi, which, as of writing this, lacks of 64-bit compilation support. As much as I can predict the future, 64-bit support is not going to be added soon. Or ever. Borland is trying to sell their IDE business and I have this feeling that there are not very many companies knocking on the door. If you feel that translates to Delphi is dying, well, uhm, I keep my fingers crossed.

So what can we do? We need to interface with the IIS SMTP somehow. Now the only part of ORF which directly talks with the IIS SMTP is the SMTP Module and actually it is enough if we can get that part work. And we have multiple options!

• A) My initial thought was to turn the SMTP Module from an in-process COM server into an out-of-process server (~from DLL to an EXE). This would have a little performance penalty, but could work anyway. In theory. Alas, Microsoft’s documentation states that it will not work and this my experience confirmed this. Even though, I talked with a fellow professional who said he could get an out-of-process event sink work and I have no reason to doubt that.
• B) Rewrite the SMTP Module in C++, which supports 64-bit compilation. This would be a clean solution, but nobody here speaks C++ well. The result would be ridiculous at best. Not because any decent C++ developer would laugh his ass off while looking at our code, but because it would take enormous amount of time and would be hard to maintain.
  We could hire a contractor to do the job, but we believe that our core competencies like code and design must not be outsourced. We can also hire someone full-time who speaks C++, but it is hard to justify the cost.
• C) Rewrite the SMTP Module in C#, which supports 64-bit compilation. We speak C# and Microsoft recently made protocol event sinks available in the managed world. However, mixing languages just does not sound good and the fellow professional I mentioned above described his experience with managed event sinks using less than enthusiastic words (yes, that’s a gross understatement). I got the same impression when I tried getting a C# event sink work.

So we have a multitude of bad options, but Exchange 12 (now Exchange 2007) is coming soon, so we have to come up with something. Stay tuned :)

The focus is now on the Reporting Tool of ORF 3.0. We already got the tool backbone, most supporting code and now reports are being designed. See below how it looks so far.

The GUI misses lots of functionality, from report generation (the above report has real data from a real client, but it was generated outside of the Reporting Tool) to navigation or printing, but we are closer to the 3.0 release than ever :)

This is the one of the most fun parts of software development. Small cog-wheels like PowerLogs, log preprocessing and reporting code get integrated and the engine slowly starts working. It is noisy, emissions are high, fuel leaks, but it finally works! :)

The Art of Customer Service is a recently published piece of Guy Kawasaki’s excellent “Art of…” series. In his article, he emphasizes the importance of having a great customer service and points out that…

[…]customer service has as much to do with a company’s reputation as sales, marketing, engineering, and finance.[…]

I cannot agree more. Maybe I would even call it an understatement.

Customer service can make or break a company, if the company is not in some kind of monopoly position. My previous ISP, the manufacturer of my previous MP3 player and a couple of other companies lost me for their ignorant and bureaucratic customer
service. I would not hesitate a second to switch my cable TV or telephone provider if there were alternatives, thanks to their poor customer service. On the other hand, I cannot stop recommending products of companies which gave me great customer service experience (well, provided the product works). Surprisingly, a few companies still have not realized that it is always the service sold, even though the product itself is an MP3 player or a software tool.