VB6

[lostcarpark]

The above title should have been enough to make most readers switch off. But for those who are still reading, this is a geeky post about Microsoft development tools. Everyone skipped to something more interesting? Good.

One of the Microsoft mailing lists I subscribe to included an article about upgrading from VB6 to VB.Net. It talks about how good it is, how easy it for VB6 developers to pick up, and how good the tools for migrating old applications are.

Unfortunately it misses the point.

I have been developing in VB.Net for nearly two years, and there are a lot of good things about it. But no matter how good it is, you can't escape the fact that there are some fairly significant changes to the language. There are tools which will run through old code and try to fix it up for VB.Net, and the do work quite well. But the code still needs to be reviewed by a developer, and oc course it needs to be fully retested.

Now if an application is undergoing a major upgrade, this work might be justified. However, many companies will have large applications which were written years ago, and which do what they're supposed to. I occasionally have to deal with several applications within our company which contain over a million lines of code. Updates tend to be minor, but they do take place from time to time. To convert such a system to VB.Net would be career suicide. You would be trying up sevelopment and testing staff for six months or more on a project to convert an existing system (the developers of which have probably left the company) that works into a new system, which will almost certainly introduce all kinds of bugs and problems, requiring more time to fix, but delivering no benefits. No manager in their right mind would approve such a project.

You could argue that there would be benefits in the long term, but the fact is that IT departments are always overstretched and don't have time to go looking for unnecessary projects.

Microsoft are panicking because primary support for VB6 is due to end next year, and they would love to cut it loose. But they know that there are too many people using it to do that. It will be like NT4, with extension after extension to the support. In the future, VB6 developers will become like Cobol developers, a dying breed, highly sought after to maintain ancient IT infrastructure, and commanding huge saleries to keep old systems alive.

Maybe there's hope for me yet!

Comments

[lostcarpark.livejournal.com]

I really don't think that's a big issue for most users. There are some applications where it's a major benefit. However, most applications that need native compiler are written in C/C++.

The area where VB really shines is in business applications where the high level of database integration and easy front end development tools were a big hit. In the early 1990's there weren't a lot of tools which offered this, and very few that could compile standalone executables.

Compile native code was a popular feature, but it produced much larger executables than compiling to p-code (often 2-3 times as large). Database applications generally spend most of their time calling library functions, so the speed of the program's own code isn't that relevant, and I generally found that a large business application would run faster as p-code as there was less to load into memory and more memory left for the running application.

[spodlife]

Maybe I should speed test the vb6 app I maintain. Most of the heavy work is done in a C DLL, which I recently tried to speed up and slim down by removing lots of unused code.

Even more of the functionality is moving to a database too :-)

[lostcarpark.livejournal.com]

Well worth a try. It's under the project settings. If it's a large project it should dramatically cut down the .exe size. Whether it makes any difference to the speed probably depends on the hardware.

[lproven.livejournal.com]

Oh, OK. You really surprise me, but OK.

[lostcarpark.livejournal.com]

I was pretty surprised too. It was someone else told me the project ran faster when they turned off native code compiling. I refused to believe them until I tested it on my computer and found the same thing.

This won't be the case for computationally intensive applications, but these would be relatively rare in VB programs. Most VB code consists of chains of calls to library functions. The library function takes the same time regardless of whether it was called from compiled or intrepreted code, so if the amount of code between calls is small, compilation will make little difference to the overall speed.

[lproven.livejournal.com]

[Nod] I can see why, I'm just surprised by the result. My tiny bit of VB fiddling was with fractals and there the compiled code was MUCH faster.

[lostcarpark.livejournal.com]

Aha! Anything that involves lots of computation would see a big improvement from native code compilation. Most business applications won't however. For many such applications, upgrading the database server will make more difference than anything you do on the client side.

Incidently, VB.Net does claim to compile to native code. However, it uses "just in time" compilation, which turns the P-code into native code before it is executed. Generally when you run a .NET application there will be a pause during loading while compilation takes place, after which it will run like a racehorse.

[lostcarpark.livejournal.com]

Actually, it would be really interesting to see how your fractal application compares when moving from native code VB6 to JIT compiled VB.Net.

[lproven.livejournal.com]

I might try someday, but TBH, a simple math benchmark would test the same thing and be easier. Classic Sieve of Eratosthenes, say.