Partager via


Windows Vista, STI and a Story about Customer Service

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.

Comments

  • Anonymous
    March 22, 2006
    It would be nice if you chose an example of you being responsive to a mistake made by your own company.  To make an example of you being responsive by saying that the customer did something he should not have done just comes accross as being self congratulatory.  Whilst I don't understand the technology you describe, you do appear to be saying that what the customer did on XP (the current standard Windows) would not work on Vista, the new Windows, and whether the call made by the customers programmer was on something documented or undocumented, the concept of reverse compatability should have been maintained.

    Saying that the XP STI.DLL  (5.1) supported something which the Vista version (6.0.5) did not seems very much to be a Vista issue, how can you say that it is not?

    To say about the programmer '(for reasons unknown)' implies that he was incorrect in writing something for XP which could not subsequently be read by Vista but I take the view that if he wrote something that worked in XP he did so because he could, and because it worked, and he therefore should be able to do the same with the next generation of Windows.

    I work on development of a DOS database for my own use which still works very well for me so the subject of reverse compatability is one very dear to my own heart.
  • Anonymous
    March 23, 2006
    This customer might have been satisified had you just blown him off with a "You use undocumented features at your own risk", but who knows how many other users would eventually have been making that same call and losing sleep over why things weren't working?  If it shows up in a header file that programmers read, people will use it.  You made the right call in treating it as you did.
  • Anonymous
    March 23, 2006
    The comment has been removed
  • Anonymous
    March 23, 2006
    I agree with you wholeheartedly, Wil and so does the STI team which is why they asked me to open a bug so that if we get similar complaints - and we will if people's apps break - then we know it's a big enough issue that we should incur the expense of putting the functions back in.
  • Anonymous
    March 24, 2006
    [Tom] ... I was pleased with how open dev was to going outside the typical response...

    The typical response being, "this was definitely not a Windows Vista issue". Say, wasn't that your initial response, Tom?

    [Tom] ...  if you use undocumented functions, you do so at your own risk.
    ... He committed the cardinal sin of using undocumented code

    The StiCreateInstanceA function is "undocumented"?? Since when?!
  • Anonymous
    March 25, 2006
    LioNiNoiL:

    Not sure what you mean by initial response. When the customer said someting was amiss with Vista in that his STI app wasn't working, I brought the issue up with that team who pointed me to the STI team who explaind the issue - that it was their decision and had nothing to do with the Vista dev team.

    The StiCreateInstanceA function has never been documented by Microsoft. StiCreateInstance is defined to use StiCreateInstanceW. Therefore, the only way to even use StiCreateInstanceA is to have looked through the header file and call it explicitly, which most people don't do as they allow the header file to call the appropriate ANSI/Unicode version based on the build type and what the API supports. In this case, the API only (officially) supports Unicode.
  • Anonymous
    March 26, 2006
    The comment has been removed
  • Anonymous
    March 26, 2006
    avenger218: I believe there is a plan to get bits to the public, but can't say anything else. Stay tuned :)
  • Anonymous
    March 29, 2006
    excelent
  • Anonymous
    March 31, 2006
    Hello,

    I have a question really on WinFx.net, but I was just curious if you'd know about it.

    I really like WPF based UI & would love to recommend it for some business solutions that we are planning to build in the next 6-9 months. However, these solutions will probably run on XP.

    Would you happen to know if the WPF/WinFx.Net will be getting out of the Beta version & if it is a good idea to think about serious WPF based solutions in the next 6-9 months timeframe.

    Thanks..
  • Anonymous
    March 31, 2006
    The comment has been removed
  • Anonymous
    April 06, 2006
    The comment has been removed
  • Anonymous
    April 11, 2006
    i want to load windows vista
  • Anonymous
    April 14, 2006
    The comment has been removed
  • Anonymous
    April 14, 2006
    Ai_Vista:

    That completely depends on the driver. I know that with each build, Vista is able to recognize more and more drivers. For example, back in November, it wouldn't automatically work with my Dell's Network Adapter. I had to manually get a driver from the Dell site for it to work. Now it identifies and configures it up automatically.

    Regarding release dates, Windows Vista will be available via volume licensing for businesses in November '06 and to consumers in January '07.
  • Anonymous
    May 02, 2006
    The comment has been removed
  • Anonymous
    May 10, 2006
    Carlos: There is a world-wide "Windows Vista Beta Experience" program that you can register for:

    *Vista Beta Experience
    http://go.microsoft.com/fwlink/?LinkId=66411

    I would also recommend looking at the following page if you're interested in developing for Vista as it walks you through which tools you need and where to get them.

    http://msdn.microsoft.com/windowsvista/downloads/getthebeta
  • Anonymous
    July 07, 2006
    Your article is quite right, thanks.