The last line of my VB6 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).

reddit this! Digg Me!

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.

reddit this! Digg Me!

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.

reddit this! Digg Me!