Reading a couple of posts on The Old New Thing (Raymond Chen's blog) made me realize that compatibility issues, except for being a general headache, have a lot of nontrivial repercussions. Take this example of a network interoperability issue: Samba, the standard Linux implementation of an SMB server, supports a feature called fast directory queries. Apparently the feature had been (until recently) broken, and because Windows XP never made use of the feature this was a non-issue until internal tests with Vista brought it to light.

A naïve developer would, at this point, assume that Microsoft would let the responsible party know that they have a bug and move on. Things are obviously not that simple, but for reasons you wouldn't expect: exactly because Samba is such a widespread product, any user encountering the bug (assuming he/she'd even notice something was wrong - the bug in question is not easy to spot) for the first time would automatically assume a bug in Windows Vista (a fairly reasonable assumption considering you could never hit that bug with older versions of Windows). Worse still, although the bug was fixed quickly there is no guarantee that the fix will actually be installed on the problematic devices. For starters, there is a chain of responsibility which starts with the administrator of the offensive device and ends in the product vendor; this means that in some cases the vendor will not install the bugfix by default and will void the support contract if a "vigilante" administrator installs it locally. Second, Samba is often used in embedded devices (such as network attached storage [NAS] devices) which may or may not be firmware-upgradable by the user.

Regardless of the solution Microsoft decides on (Raymond is actively seeking ideas - if you have any, make sure to drop a comment), some of the proposed solutions have even subtler repercussions that need to be considered. For example, one of the proposed solutions is to detect and maintain a list of "bad" servers for which fast queries will be disabled. Apparently this is a potential security hazard, because a malicious user can make use of this feature to launch denial of service-like attacks on the client (it's not obvious how this can be done, so Raymond elaborates on this point in a follow-up).

One of the disadvantages of working on relatively low-profile software is that you hardly ever get to tackle security issues such as these, so you only get food-for-thought by reading articles and blogs. But I guess that's what the blogosphere is for in the first place, no?

In the process of "going legit" with my laptop (i.e. getting rid of all commercial software I won't pay for, trading proprietary software for free/open-source alternatives etc.) I've reached several important conclusions:

• There are very few commercial applications I can't live without (specifically, Windows; Visual Studio; Total Commander)
• Some free/open-source alternatives are actually superiour to their commercial counterparts (Firefox, Thunderbird and OpenOffice.org [Hebrew version] are three such examples)
• The sheer amount of tools and applications I require just to get things done is astounding

Despite the impressive efforts by the free/open-source community, there are still a few areas where commercial companies (in this case, Microsoft) have the upper hand: PDAs. I was recently handed down a MIO 168 RS handheld which my dad replaced, and ended up trying to learn the quirks of Windows Mobile and how to best make use of it.

Apparently the whole deal of synchronizing with mobile devices is not as trivial as you'd think; there is only one standard, SyncML, which is apparently supported only in part and inconsistently by various mobile devices, and is basically not supported by Thundebird (nor, to my knowledge, Outlook). The Windows Mobile connectivity solution from Microsoft, known as ActiveSync, is perfectly adequate if you intend to use Outlook; however I do not own a license for Outlook (one is provided with the PDA, however it is for the obsolete Outlook 2002) and would prefer to keep using Thunderbird anyway.

The one glimmer of hope is an application called FinchSync - a combination of java sever on the PC and a .NET agent installed on the PocketPC device (strange, wouldn't you agree?). There are several problems with this solution:

• It is incredibly cumbersome. Having to install a seperate server and client application is in itself a chore, but having to install the server application on each and every host machine is really very annoying.
• Although it supports .ics files (which appear to be the standard calendar file format used by Mozilla applications), these files do not appear to be employed by the Lightning extension to Thunderbird by default and I couldn't figure out how to get it to work.
• Finally, the software works over TCP/IP; this was probably the easiest solution, however PocketPC devices that are not WLAN-capable are not configured for TCP/IP by default; it might be possible to configure a TCP/IP bridge over the device's USB connection, but up to this point I have spent so much time with so few results I've conceded that there is no way to do this easily.

As you can see, in this case Microsoft takes the cake: synchronizing to anything but Outlook is a real chore, if not next to impossible. I'd consider getting a license for Outlook, but at roughtly $70 for an academic license of a version of the software that's three years old and about to be replaced it's hard to justify the expense; additionally I would much prefer to keep using Thunderbird as my e-mail client of choice.

With the upcoming competition from Office 12 and the far-superiour integration of Outlook in the corporate environment along with its tight integration with PocketPC-based solutions (which I've come to understand are the majority in this market segment), the open-source alternatives are in pretty grave trouble.

I decided to split my previous post in the hope that someone googling for this topic might actually get a straightforward answer (I certainly didn't). Visual Studio 2003 does not let you use Bitstream Vera Sans Mono by default. Instead it takes a bit of trickery to get it to work.

1. Open Visual Studio 2003; go to Tools->Options->Environment->Fonts and Colors. You will notice that you can select either Bitstream Vera Sans or Bitstream Vera Sans Mono Bold. Select the latter like so:
   
   
   
2. Click on OK and close Visual Studio 2003.
3. Run regedit; click through to the following key: HKCU\Software\Microsoft\VisualStudio\7.1\FontAndColors\{A27B4E24-A735-4D1D-B8E7-9716E1E3D8E0} (the GUID may be different for you - there aren't many of them, just look until you find the right value name):
   
   
   
4. Change the value of FontName to "Bitstream Vera Sans Mono" (without the quotes):
   
   
   
5. Click on OK, close the registry editor, restart Visual Studio 2003. You're good to go!

 

I haven't been working with Visual Studio 2005 that much thus far; the project I've been working on for the last 8 or so months was launched before VS2005 came out (around beta 2), and given the relatively schedules between milestones (first version was to be demoed in about two months) it seemed far too risky to invest in a codebase around the yet-unproven features of .NET 2.0.

I still think that was the right decision. I've been doing some work with Visual Studio 2005 lately, primarily on PostXING and other minor projects, and have come to the conclusion that Visual Studio 2005 is practically unusable. The IDE is even heavier than Visual Studio 2003, ridiculously slow and extremely prone to stalls; it feels like working on a huge solution in VS2003 with a buggy alpha version of ReSharper. The debugger has an incredibly annoying tendency to just stall for tens of seconds at a time whenever I step in/out/over. The IDE feels more like NetBeans than Visual Studio, and is about as responsive, but while NetBeans can be forgiven as a relatively new - and partially open source at that - effort, Visual Studio 2005 is an evolutionary step on a reasonably mature IDE that itself is the 7th version of a 12 or so year-old effort.

Too bad I can't really stick with 2003, it's just not an option - but I would rather have my trusty old combination of VS2003 and R# (which in itself is not without issues) than the heap of bugs and unoptimized UI that is VS2005. At least until VS2005.1 comes along (maybe they'll launch VS2006 with .NET 2.1, like they did with 2003...)

 

I didn't really believe there were any genuinely crapy onboard sound card this day and age. Being a gamer and audio enthusiast I've always considered sound cards to be one of the most important aspects of my PC (along with the monitor, keyboard and mouse). My PC soundcard timeline goes something like:

1993	Sound Blaster Pro
1996	Sound Blaster AWE32
1998	Aureal Vortex 2-equipped Xitel Storm Platinum
2001	Sound Blaster Live! Value (after Aureal went bankrupt)
2000-2002	Gravis Ultrasound and Roland MT-32 for my retromachine (and a GUS ACE in storage for rainy days)

When I bought my latest desktop at the end of 2003 I had a newly found faith in onboard solutions; onboard network adapters were finally up to snuff and the latest SoundStorm (the onboard sound solution found in nForce2-class boards) was being heralded by the online hardware press as the next best thing. Seeing as I was serving my stint in the army at the time and was relatively low on cash I opted to save money on a dedicated sound card and went with the onboard solution. This turned out to be a mistake; the audio quality of SoundStorm was not on par with the five year-old Live! and has pretty major bugs in the hardware acceleration layer; mixing would sometimes clip - particularly when very low rumbles were mixed in the general sound, as in System Shock 2's elevator shaft - and the EAX implementation was so poor it was next to unplayable. There were also major compatibility issues, such as the sound cutoff problem prevalent in a lot of Ubisoft titles and the extreme sound stuttering with Half Life 2. This was probably the game developers' fault for not ensuring compatibility, but nVidia did not seem overly inclined to work with developers to resolve these issues; conversely I would seriously doubt Creative would stake its reputation on this sort of bug.

At work I have an Athlon 64-based machine with the ubiquitous onboard Realtek AC97 codec (Gigabyte GA-K8NF-9 mainboard). I constantly listen to my music collection, streaming audio etc.; I don't game, I don't edit audio, I don't do anything that requires more than a passable audio solution. The onboard audio should have been perfectly acceptable, and so it was. Until a few days ago when I started noticing crosstalk from the I/O subsystem to the audio lines; in other words, there was a weak sort of static hiss which would change pattern and frequency depending on how hard my hard drive was churning. I probably wouldn't have noticed that with lesser headphones, but that's no excuse! Why is it that in the year 2006, 18 years after the first commercial sound card for the PC was developed, I can't even get reasonable, 2D stereo audio from onboard solutions?

The only reasonably-priced sound card in the market at the moment is the Sound Blaster Audigy 2 Value (around $70 in Israel - the price of a new Audigy 4 in eBay!). Guess I better start hammering at those auctions.

ReSharper EAP build 222 totally barfed on one of my source files and I was too lazy to reinstall build 219. The result? I was working on this one file for a couple of hours without any help from R# (no advanced syntax highlighting, static analysis, improved intellisense etc.)

I would like to reassert my statement that R# is the best thing that happened to C# programmers since, well, C#. Working with Visual Studio 2003 and without R# feels a little like trying to use a pen with an amputated finger.

Chris has finally released a beta version of PostXING v2.0 (an opensource blog client for Windows)! The development version is pretty stable and usable, but the more people that use it and post bugs and feature requests the more motivated the developers get

Grab it from Project Distributor (requires .NET 2.0).

I've been working with build 219 for about a week now. With Visual Studio 2003 it's perfectly stable (only one exception so far), seems considerably faster and I haven't encountered any major (and very few minor) bugs so far. I haven't worked with Visual Studio 2005 at all over the last week (sorry Chris... project schedules ) so I've nothing to report on that front.

I'll keep the ReSharper: New And Improved post up-to-date, as always.

While working on one of our projects at Monfort, we encountered a very strange problem. The project was dependant on several COM objects, one of which queries a database according to a predefined interface and returns the results in an ADO Recordset. Our project is key-signed, so we had to import the COM objects using the .NET SDK tlbimp utility; everything worked perfectly until we added the querying logic that receives the Recordset result object. The class loader would throw an exception on calling the relevant method (it was invoked dynamically) claiming that the "referenced assembly adodb.dll could not be found." To quote Monty Python: this is, of course, pure bullshit. The imported ADODB wrapper was right there in the directory. I couldn't figure out the problem in a reasonably timespan, and finally decided to ignore it altogether by using the ADODB primary interop assembly distributed with .NET 1.1. I added a reference to the ADODB PIA and everything compiled and seem to run fine.

This turns out to have been a mistake. I was absent from work for a few days getting ready for a test, and came back to find that a colleague has encountered the same problem but elsewhere; examination of the compiled executable's references (via ILDASM) revealed that it was in fact generated with two separate references to ADODB with two different public key tokens. One of the references was the PIA, which was just peachy, but the other one (in the hidden namespace ADODB_19 of all things) referenced a non-existing assembly with the same public key token we sign our other assemblies with. I concluded that there must be some sort of problem with the build process - left over dependencies that weren't compiled properly or something of the sort. Cleaning up the build directory and rebuilding did not alleviate the issue. In desperation I tried to manually edit the project files but couldn't find anything.

I then decided that one of the COM object wrappers we created using tlbimp was, for some reason, referencing a non-existing version of the ADODB wrapper; I went through the wrapper assemblies one by one and managed to find the offending library. Turns out that tlbimp does not, by default, look for primary interop assemblies and opts to import ADODB every single time (singing the new wrapper assembly accordingly). When I deleted what I thought was a redundant ADODB wrapper assembly, I in fact deleted a version of the wrapper that was referenced by one the imported COM wrappers. So now all I had to do was add a /reference: directive to the tlbimp call in our build script and voilla - everything works!

Only it doesn't. Another COM object which references ADODB was still generated with the mangled assembly reference (i.e. it still referenced the wrapper with our own public key). I retried all sorts of tricks and couldn't figure out why it was generated that way; I eventually tried to re-import it manually with a /strictref directive, which resulted in the following error message:

A fit of confused rage and an hour later I sat at the computer again to try to figure things out; finally (as usual) it was just a matter of asking Google the right question:

The problem was that MyCOMLib.dll was compiled against ADO 2.5 and the PIA released by MS is registered only for ADO 2.7. I don't have access to the COM component to recompile it for ADO 2.7, so I had to get a PIA for ADO 2.5.

Further research into this turned out a little detail most .NET developers are probably unaware of:

Issue 7: You experience problems working with components that expect ADO 2.8 interfaces

The ADODB PIA that is included with Visual Studio 2005 is the same component that was included with Visual Studio .NET 2003 and was built by using the Microsoft .NET Framework 1.1. The ADODB PIA was built to interact with ADO 2.7 interfaces and has not been updated to work with ADO 2.8 interfaces.

Therefore, attempts to use the ADODB PIA together with components that expose ADO 2.8 interfaces will fail. This scenario is not supported with the ADODB PIA.

Oh, great job, Microsoft! You spent so much time on the interop issues with .NET (of which, by the way, there is an impressively small number), came up with the concepts for Primary Interop Assemblies, Publisher Policy Files and everything else that went into .NET in order to prevent DLL hell, you tout Primary Interop Assemblies as a way for component publishers to guarantee that their components are usable under .NET, and finally you go on to release a PIA for one of the most widely used COM objects in Windows which only supports one version!

So there you are, I hope this might save someone the frustration of having to figure all of this out on their own.

As a footnote, ILDASM is one of the worst tools I've ever used. I can't believe how Microsoft managed to wrap a useful debugging tool with one of the most frustrating and least usable UIs I've ever encountered. Don't know what I'm talking about? Try double-clicking on a node (method, manifest, whatever). You can't run a search through the text; worse still, you can't even Ctrl+A, Ctrl+C then paste into notepad! Only now, days after I needed it, did it occur to me to rightclick and "select all". I suppose it's OK if you don't follow the classic usability patterns and guidelines in a small and esoteric development tool, but please try and exercise a bit of common sense...

I couldn't access the comments on my own website for an indeterminate amount of time (at least a week) and had to dig in the sourcecode to find the culprit (now described in bug 1439112). To make a long story short, it appears I got my dasBlog cookies mangled, so if you have the same issue either contact me or get rid of all cookies from www.tomergabel.com.

(If you're using Firefox and don't know how to access your cookies, here's how. If you use IE just go to d:/Documents and Settings/username/Cookies).