Find your next scenic drive!

January 6, 2006

RAPI EnumFiles error...

Recently, I was working with the Open .NET Compact Framework’s Desktop.Communication Library, writing a simple program to go through the device and show me all the files and directories below a certain starting point using the API’s RAPI.EnumFiles method.

Prior to adding the recursion, this program was working great. But once I added the recursion, the program began throwing a FatalExecutionEngineError exception usually at the EnumFiles method (but not always) and what was also interesting is the fact that it would sometimes recurse 10 directories and other times hundreds. The exact wording of the exception is as follows:

FatalExecutionEngineError was detected: The runtime has encountered a fatal error. The address of the error was at 0x7a0c6df2, on thread 0x1678. The error code is 0xc0000005. This error may be a bug in the CLR or in the unsafe or non-verifiable portions of user code. Common sources of this bug include user marshaling errors for COM-interop or PInvoke, which may corrupt the stack.

Googling over this error did not bring up very many useful results. However, I finally fell onto the post, FileInformation buffer size is too small. I downloaded the code, downloaded the RAPI.cs version 1.2 (Username: guest, Password: guest), built the library, and viola! It appears to have solved my problem.

January 1, 2006

Strings in C++...

A few weeks ago, Danny Kalev had an interesting article about Visual C++ 8.0 hijacking the C++ standard.  The gist of the article is that Visual Studio proclaims a few string manipulation methods as deprecated, when the official standard does not.  There are two things that I could not help wonder while I was reading through these articles though.

I find it interesting to have this entire controversy on the various string manipulation functions. If you look at strings from the perspective of an array of characters, the problem they are trying to solve is already solved in newer programming languages, such as Java and C#. The question of whether an array is shorter or longer than the other in these languages effectively boils down to calling array.length. This in actuality removes not only the requirement of passing in this argument, but it also prevents from you from lying about how long your strings actually are. Everyone that has been programming for any period of time knows that the length of that array will change at one point or another, and unfortunately, there will be at least one area in the program that makes some assumption of how large or small that array is no matter how careful you actually are.

This, however, is unlikely to be added to C++, as the technique is quite powerful and useful in many cases, not to fail to mention that it may be quite painful to add at this time. But to quote the Spiderman movie, “with great power comes great responsibility,” in this case, the responsibility to know and honor the bounds of an array.

Regardless of that, the other aspect that prevents this entire class of error without changing the language is simply by using the std::string class, as this class manages the memory and particularly, the length of the string for you. It is not to say that this class is not without faults, or at least perceived faults.  For one, there is no way to directly append an integer to the string, which would generally lead to code like this:

  • std::string myString = ...;
  • int value = ....;
  • char str[25];
  • snprintf( str, sizeof( str ), "%d", value );
  • myString += str;

This is unfortunate.  Java and C# have both addressed this issue, both from having automatic conversion from objects to Strings (making the above myString += value;) and also having formatters directly in the string object.

In addition to the perceived missing functionality (most developers will be able to quickly tell you at least one more function that they think should have been included in std::string), one major concern with the string class is its dynamic memory allocations.  Interestingly enough, however, the introduction to Effective C++ suggests some excellent advice: “As a programmer, you should use the standard string type whenever you need a string object. ... As for raw char*-based strings, you shouldn't use those antique throw-backs unless you have a very good reason.  Well-implemented string types can now be superior to char*s in virtually every way--including efficiency.” And this excellent quote is from the Second Edition (1998).  Of course, there are reasons where you may not want the std::string class, but in those cases, you should use a class that abstracts out the optimizations you require.

In addition to this, Item 13 of Effective STL suggests to prefer std::string and std::vector to dynamically allocated arrays, suggesting that they hide many of the intricacies of dealing with pointers, and further, mentions how some implementations of std::string employ a reference counted and Copy-On-Write semantics that could limit the number of allocations for certain usage, which is further described in Item 15.

A couple years ago, Andre Alexandrescu wrote an article in CUJ's Expert Forum describing his experience with std::string. He was asked to improve the performance of an application, and it was believed that the issue was with memory allocations. A little profiling lead him to believe that strings were part of the issue, so rather than rip them out, he instead decided to provide some policies to the classes, thus depicting how they were being used. This significantly improved the applications performance within a couple weeks of work.

All of this to say that the std::string class leads to code that is more readable, performs nicely, and should you encounter some issues on your platform, you could potentially upgrade your STL implementation or roll your own string-classes.

While declaring functions deprecated that are not deprecated in the standard is a bit extreme, I think that this brings awareness to the seriousness of this issue and should developers pay attention to the warnings, it could yield more secure and stable software.

December 21, 2005

Of Hacks and Keyboards...

I am not sure if I missed something or not, but I am completely surprised at this conversation about being notified when a tab changes in a TabControl. I am surprised that no one has mentioned TabIndexChanged event or, if you are working on a platform that does not support that event (such as Windows CE), the SelectedIndexChanged event.

But what is even more surprising to me is that, not only did someone suggest setting up a mouse event handler to be notified when the user selects the tab, the original author had actually tried it! Fortunately, it seems that this does not work.

From a usability perspective, what about the keyboard? While most people use a mouse for selecting tabs, some people use the keyboard, and depending on what happens when the event occurs, the user experience of the keyboard user would be different than that of the mouse user. Debugging this over e-mail could be rather amusing, to say the least.

When creating hacks, you have to consider the cases for which the hack would not work, and in a user-interface, the inability to use the keyboard is definitely something that should be avoided, especially when a little further research would provide the desired and correct behaviour with minimal effort as the case above. Unfortunately, sometimes this is not the case, and for these cases, the caveats must be minimized and well understood and documented. Based on the discussion, I do not believe that this was the case for this particular issue.

December 15, 2005

Commonalities between Home Depot and .NET

In the last few weeks, I have been developing a couple tools in C#, half in Microsoft Visual Studio 2003 and the other half in Microsoft Visual Studio 2005. I maintain some of my initial reactions to C#, but I have begun to see why Kevlin Henney believes that C# is a more expressive language than Java. Take, for example, the following Java code:

  1. for ( String str : list ) {
  2.   System.out.println( str );
  3. }

You would really have to know that this is a for-each statement or at least spending a couple seconds figuring that out the first time you see it. On the other hand, consider this C# example:

  1. foreach ( string str in list ) {
  2.   System.Console.WriteLine( str );
  3. }

That is very obvious, and can be easily read aloud.

That said, however, this morning I read Billy Hollis’s How is the .NET Framework like Home Depot? and I couldn’t agree more. The .NET framework is not obvious when you do not know exactly what you are doing, and it can be daunting to find the answer.

I have witness this myself a couple times in the last week. For many things, you can simply Google and find enough hints to get you through the situation, but one problem I still have not solved. According to this MSDN Chat, you can implement an ActiveSync Service Provider using C# by implementing two COM interfaces, although he is unaware of anyone actually doing this, but I have not made major headway in this area after trying for a couple evenings (this is not particularly useful, BTW).

This is probably an extreme case (though you would think that C# would be a first-class citizen), but I regularly find myself knowing that I want a particular class or behaviour, but I am not sure what it is called. For example, the other day I was looking for the a map class, similar to Java's java.util.Map or C++’s std::map, and it was rather surprising to find out that this class named System.Collections.SortedList, a class that I would have assumed would have meant that the items in the list were sorted, not a list of key-value pairs, sorted by key.

One of the biggest issues with .NET is definitely the documentation. The documentation is generally brief or misleading. Some entries are simply filled with examples, such as when upgrading to 2005, the debugger will throw an InvalidOperationException if you attempt to perform an operation on a control that was created in another thread. When this occurs, it will refer you to How to: Make Cross-Thread Calls to Windows Forms Controls; the entry, however, does not describe the technique that you are employing, and the example is much longer and convoluted than it needs to be.

There are definitely some improvements in the newly released Visual Studio 2005, and while some of the things I have mentioned above will hopefully be addressed in future releases, some of them are not easily resolvable (like the Map-class), but at least they are going in the right direction.

December 8, 2005

Wells Fargo One-Look Discontinued...

When I recently moved back to the US, one of the things that surprised me was how much more prominent the Internet was, but I think this is actually more of an illusion. In reality, I think that when you move (and particularly more so when you move across borders), you get to setup all kinds of services, and compared to when I did this in 1998, everything is more on-line than then.

One of the sites that really amazed me was that of my bank, Wells Fargo. Their interface is particularly smooth, throwing you directly on an SSL connection, supporting web standards, the ability to display scanned images of your cheques (which they do for free, and I see that my Canadian bank now does this service, but charges $1.50 per cheque), but what really impressed me was their One-Look Service.

Now forget for a moment all those security and privacy concerns, this web application is a perfect example of what web services and web applications are intended to deliver: to aggregate information from multiple providers to make one seamless view to the customer. Their interface effectively allows you to see all of your bank accounts, regardless of the bank, and you can see your current balances in a nicely designed summary page. From the summary page, you can dig down and see the account activity, login directly to that organization's accounts (you must login) or refresh the current snapshot that it has.

The truly amazing part in all of this is how it was so interoperable. All of my 401K, mortgages, credit cards, brokerage accounts, and everything is right there in one place! In fact, the only account that I was unable to add directly was my autoloan, and well, based on their website, it aint surprising why you can't. But even for such accounts, it provides you an interface to manually enter information so that it is still available, albeit not realtime (I have never tried this; my impression was that it was not as powerful as it could be).

Unfortunately, however, Wells Fargo has announced that this service will be discontinued in February 2006. According to this, the service was started in March 2001, and Citigroup had a similar service that was discontinued earlier this year.

And while there are some security concerns around one site having all this information (especially given the number of banks that have "lost" customer information in the last couple years), the interoperability of this service and the customer's ability to get a great, quick summary of all their finances with an easy-to-use interface would seem to be the future of usability. It is unfortunate that this could not be secured sufficiently well to gain customer confidence.