One of the most exciting things I’ve seen since I started to work at Microsoft is how open the development teams are to listening and helping our customers when a problem arises. One case in point took place over the past couple of weeks.

 

Without stating specifics, a customer wrote me (via this blog) and asked if Windows Vista would continue to support ANSI code. He explained that his company produces a well-known imaging product that makes calls to the STI functions. (STI, or Still Image, is part of the Graphics and Multimedia APIs and provides a means of programmatically acquiring digital still images from cameras.)  Evidently, his application calls the StiCreateInstanceA function directly and while it works on Windows XP, they found that deploying and attempting to run the application on Windows Vista resulting in an (“Entry Point not Found”) error.

 

Now obviously, Windows Vista would have the shelf-life of a tsetse fly if it were not to support the countless ANSI applications in existence today. After some debugging with the customer, we determined that the XP version of the STI.DLL (5.1) was different than the Windows Vista version (6.0.5) and that his application works when he replaces the Windows Vista DLL with the XP version.

 

Therefore, this was definitely not a Windows Vista issue and I needed to communicate with the STI team. Armed with this information, I contacted the PM (Program Manager) for the STI team and, after a few back-and-forth emails, I learned that the ANSI versions of the STI functions were never originally supposed to ship with STI and were only discovered during code analysis. Once they were discovered, they were not removed, but they were never documented. In fact, the STI.H header file redefines StiCreateInstance as StiCreateInstanceW (Unicode) so that no one accidentally calls the undocumented StiCreateInstanceA (ANSI) version.

 

So how then did the customer call it? Evidently the customer’s programmer (for reasons unknown) explicitly called the StiCreateInstanceA function instead of converting the parameters to wide char so that the Unicode version could be used. I politely explained the situation to the customer and they were very cool with the globally acknowledged situation that if you use undocumented functions, you do so at your own risk.

 

However, Windows SDK PM Brent Rector made a great point. While we didn’t technically “document” the function in terms of formal documentation on MSDN, we as a company implicitly documented it by releasing it to the public in such a way that developers could make use of it and become dependent on it. At that point, I spoke to the STI PM and Lead Developer who listened to my advocacy on the part of the customer and were very open to at least considering putting the ANSI functions back. They asked that I create a bug in our internal database to track the issue and get feedback from other STI team members.

 

Will the ultimate resolution be to return the APIs. Honestly, I doubt it. First, this is the only customer that has even brought this issue up. Second, the customer has stated that this only impacts a very small piece of code and he’s migrating to full Unicode anyway. However, the key point here was that we could have easily blown the customer off with the standard reply of, “You used undocumented functions. Sorry, but we can’t help you.”, and the customer would have been cool with that. However, several people stepped up to not only ensure that we gave an acceptable answer, but that we did everything we could to do right by our customer.