Mike Schaeffer's Blog

There's been some 'controversy' in the blog world about a petition that's circulating to ask Microsoft to continue supporting "Classic" Visual BASIC in addition to the replacement VB.Net. A month ago, I had a pretty long post dedicated to the topic, but due to technical problems I wasn't able to get it online. Therefore, I'll keep this sweet and to the point.

The core problem VB6 developers are facing is that they sank lots of development money into a closed, one-vendor language. Choosing VB6 basically amounted to a gamble that Microsoft would continue to support and develop the language for the duration of a project's active life. That gamble hasn't paid off for some developers, and companies with sizable investments in VB6 code now need to figure out how to make the most of that investment while still evolving their software.

With standardized languages like C, languages with multiple tool vendors, the risk is significantly lower. If one vendor drops their version of a language, switching to another implementation is going to be a lot easier than porting to an entirely different platform (particularly if you've avoiced or isolated vendor-specific features).

So... what's the moral of this story? Before you base your business on a particular language or tool, make sure you know what happens if that platform ever loses support. Pick something standardized, with multiple viable vendors. Or alternatively pick something open source, where you can take over platform development yourself (if you absolutely need to). Whatever you do, don't pick a one vendor tool and complain when the vendor decides to drop it. Commercial vendors, particularly, have no legal obligation to their customers.

Global variables tend get a bad rap, kind of like goto and pointers. Personally, I think they can be pretty useful if you are careful. Here are the guidelines I use to determine if a global variable is an appropriate solution:

• Will there ever be a need for more than one instance of the variable?
• How much complexity does passing the variable to all its accessors entail?
• Does the variable represent global state? (A heap free list, configuration information, a pool of threads, a global mutex, etc.)
• Can the data be more effectively modeled as a static variable in a function or private member variable in a singleton object? (Both of these are other forms of global storage, but they wrap the variable accesses in accessor functions.)
• Can you support the lifecycle you need for the variable any other way? Global variables exist for the duration of your program's run-time. Local variables exist for the duration of a function. If you don't have heap allocated variables, or if your heap allocator sucks, then a global variable might be the best way to get to storage that lasts longer than any one function invocation.
• Do you need to use environment features that are specific to globals? In MSVC++, this can mean things like specifying the segment in which a global is stored or declaring a variable as thread-local.

If all that leads you to the decision that a global variable is the best choice, you can then take steps to mitigate some of the risks involved. The first thing i'd do is prefix global variable names with a unique qualifier, maybe something like g_. This lowers the risk of namespace collisions as well as clearely denotes what variables are global, when you have to read or alter your code. If you have multiple global variables, I'd also be tempted to wrap them all up in a structure, for some of the same reasons.

The last line of my VB6 post post was this: "Commercial vendors, particularly, have no legal obligation to their customers." To clarify this, companies are legally obligated to their owners, not their customers. Since the owners own the company and have their investment at risk, the company has to act in their interest... even if it's in opposition to their customer's interest.

Since a company has to have customers to survive, most of the time the interests of the owners are in line with the interests of the customers. However, this isn't always the case: Microsoft's VB6/VB.Net decision might be an example. If you believe that the lower costs and better prospects of VB.Net outweigh the lost goodwill of all those VB6 developers, then you can also argue that dumping VB6 was a net profitable thing to do. This is despite the fact that so many customers are paying a price for the decision.

So... if you're a VB6 developer and you're upset about the way you were treated, the best protest you can make is to make Microsoft's decision a bad one. Make it unprofitable. When it comes time to pick a replacement platform, vote with your wallets and send your dollars somewhere else (and hopefully to a platform served by more than one vendor).

A few months ago, my wife and I recently switched from a Sanyo 4700 and a 4900 on Sprint PCS to a pair of Sony Ericsson T-637's on bCingular Wireless. Overall, the switch has been an improvement, but there are still a few nagging issues:

• Cingular's selection of Java games is much sparser and more expensive than Sprint's.
• There's no "Phone Ringing" Ringtone on the phone, just a bunch of generic and/or unrecognizable music files.
• There are buttons on the side of the phone that activate the web browser and camera. These are pretty easy to hit by accident.
• Sanyos and Nokias have this problem too, but the Sony doesn't really handle the case of multiple directory entries with the same phone number. When called by someone at a number that for which I have multiple entries, I'd really like to see a list of all of the entries containing that number. (This would help handle the case of two people each with cell phones and with one home number.)
• The incoming call logs are by number, not by call. This makes it difficult to tell when you've missed multiple calls from the same number.
• The incoming call logs rely on automatic horizontal scrolling to reveal information like time of call and number of calls missed. This means that you have to select a log entry and sit on it for a few seconds while the phone scrolls the information you want into view. I'd much rather have some kind of details/summary view toggle button on the side of the phone. Of the four side mounted buttons, surely one could be for this.
• There's a music editor built in that lets you compose custom ring tones. However, it only lets you work with a fixed set of clips, so it loses its appeal very quickly.

I guess that looks like a lot of complaining, but otherwise the phone is very nice. The last phone I've liked as much is my old Nokia 8260 (and the 6160 before that). The Sanyo 4900 doesn't even come close. I'm happy enough with this phone to consider buying another Sony Ericsson. (The new W800i looks pretty nice...)