"Alex" asked:

"Could you tell me if it is possible to use VB6 under operating system Windows 7?"

Yes I can, Alex!

In an uncharacteristic act of customer support ... ...see one of my many moans and groans on this subject ...

• Visual Basic 6 Programmers Are Revolting!
• It's Dead, Dave!

... Microsoft has actually officially announced support for VB6 on Windows 7.

See ... Support Statement for Visual Basic 6.0 on Windows Vista, Windows

The key statement is: "VB6 runtime will ship and will be supported in Windows 7 for the lifetime of the OS."

Oh! You were thinking of maybe using the development environment in Windows 7? There's a chart showing what will run and what won't. Microsoft's policy seems to be to avoid giving you any encouragement if you want to persist in running products you have already paid for.

If you're using Windows 7 64 bit (which I am), the chart has a simple "No" in it. If you have lots of money, you can still get "custom support" (ie ... whatever they can get you to pay) for the IDE. (I guess I'll have to keep my XP system limping along.) But we have had one report that the IDE will run in Windows 7 here.

Is it a bad thing?

This week's new technology article will focus on WPF again. This time, I'll explore using WPF to add "resources" to your project.

While writing the article, however, I started to think about an old Microsoft controversy: "Embrace and Extend".

The argument you get from Microsoft critics is that Microsoft locks you into their products and then bleeds you dry because you can't afford to switch. The critics say that they will first "embrace" a technology - like XML - and promise to follow the standards fully and completely. But then they "extend" those standards in proprietary ways that you can't really avoid using. After you have made a big investment in developing products using Microsoft technologies, you discover that no one else supports the same technologies and you have to pay whatever they want to charge and follow whatever rules they impose.

XAML ... a "flavor" of the very standardized XML and the biggest part of the new WPF technology ... seems to be a prime example. This week's article will discuss something that is even named "extension": markup extensions.

There is undoubtedly some truth in the criticism of Microsoft. But there's also a lot not said. For example:

• You get a lot of technology in return when you walk into the trap. Yes, switching would be difficult, but who wants to switch?
• Everybody else does the same thing. Show me a vendor who doesn't do essentially the same thing and I'll show you a vendor with no real technology at all. Some are a lot worse. (For example, a vendor named after a healthy red fruit or a vendor named after the word for "prophet".) Your choice isn't avoiding embrace and extend; your choice is selecting which vendor to get married to.
• Microsoft does make an effort to allow other companies to compete using the same technologies that they have invested millions to create. They have published something called, "the Microsoft Open Specification Promise" where they say they will never assert legal rights over a list of technologies. XAML is prominent in that list.

But it's something to consider, anyway. Is "embrace and extend" still a problem? Should we avoid WPF and XAML because it will lock us into Microsoft now and forever? What do you think?

First, thanks to About Visual Basic reader "Chris" for suggesting that I upgrade the WPF tutorial to include WPF animation. The tutorial really was incomplete because using the WPF animation classes is the right way to do something like varying the opacity of a Label component.

In addition to demonstrating how to do animation, the new addition to the tutorial, Part 7 of the tutorial, Storyboards are introduced (since complex animations will require a Storyboard) and the code developed is downloadable.

Reader "Mark" left a comment to my recent blog ...

... Hungarian Notation Revisted that included a link to a great article written by the authentic programming guru Joel Spolsky about Hungarian Notation. (Scroll all the way to the end to find Mark's comment.) I found both to be really interesting. And for anyone who doesn't make it all the way through Joel's essay to the end, there is a link to Charles Simonyi's original paper at Microsoft's site in it: http://msdn.microsoft.com/en-us/library/aa260976(VS.60).aspx

I especially love Joel's down-to-earth descriptions.

"you spend the next day writing up coding conventions for your team and the next six days arguing about the One True Brace Style and the next three weeks rewriting old code to conform to the One True Brace Style until a manager catches you and screams at you for wasting time on something that can never make money"

Oh yeah! Been there. Done that. It got even worse in the "methology wars" of the 1980's and 1990's. Drawing the "wrong" kind of arrow in a modeling diagram could get you hung at sunrise in some programming shops.

Although Joel has written a much more thorough and well grounded explanation of Hungarian Notation, his bottom line conclusion is pretty much the same one that I have advocated here: Quoting one of my replies above: "I do think that being able to, for example, group all of the variables in an 'employee' structure (say ... maybe with an 'emp' prefix) might be handy."

But I think he still misses a key point, and that is because Joel doesn't usually think like a VB programmer.

Joel does recognize that language makes a big difference.

"When you see the code

i = j * 5;

... in C you know, at least, that j is being multiplied by five and the results stored in i. But if you see that same snippet of code in C++, you don't know anything. Nothing."

(There's a reason why C++ just isn't used that much anymore. Multiple inheritance is a problem, not a solution. That's why it's not part of .NET.)

The key to understanding why VB6 coders used to feel Hungarian Notation - the Petzold version - was important has to do with the unique advantages and disadvantages of VB6. And the "Law of Immediate Threat". If you're in a war zone, two threats that you face are: (1) Getting shot. (2) Getting hit by a meteorite from outer space. Either one can kill you. So, do you put your armor over your head or in front of you? The answer is obvious, but let's apply that to VB6.

VB6 featured a unique language feature called the "variant" type. Basically, a variant could be anything: integer, long, string - whatever. That was a huge convenience for beginning programmers and people writing quick and dirty apps, but for more sophisticated code, it could get you into real trouble with code that failed only once every five years. (The code usually failed on Christmas eve just as the year end accounting reports were being finalized so you could work throughout the night looking for the bug and miss most of Christmas day.)

The emphasis on Hungarian Notation as a "data type" indicator in VB6 is based almost completely on this particular bug. It's the one that plagued beginning programmers and people writing quick and dirty apps. They didn't have to worry about "Cross Site Scripting Vulnerability". (I can remember when THE FIRST VIRUS hit the web. The reaction back then was, "Gee! That's interesting! I didn't know you could do that!") (And while I'm discussing "type" - that's another word that just doesn't have a clear definition. It means different things in different languages and even in just one language - say, VB.NET - it's fairly loosely defined.)

Thanks muchly for the great link. I enjoyed it and I recommend it highly to all of my readers.