It’s Never too Late to Fix Bugs

Time once again to mention my dirty little secret… yes, I’m a Visual Basic programmer. Of course, I also do alot of Perl, and I’ve done my share of Java, but much of the software I’ve written in the past 10 years has been VB, starting with VB3.0 (I did play with VB 1.0, but not for work). My current major project at work is mostly implemented in VB6.0 (service pack 5) because of the requirement to interact with the Excel and Word application binaries.

Why do I bring this up now? Because Microsoft has released Service Pack 6 for Visual Studio, which includes updates for VB6, VC++ 6, and SourceSafe. I took a look at the list of VB bugs addressed by this update, and found a couple that make this upgrade worthwhile for me.

Knowledge Base article 297112, “BUG: Visual Basic Compiler Pads Embedded Resources to Align on 32-Bit Dword Boundaries”, is an old friend of mine. I have an application that makes use of a number of XSLT stylesheets and W3C Schema Defs (XSD). In order to ease deployment issues I decided to load these documents into the app’s DLL as resources. When I tested this, some documents would work, but others would not. At the time (a couple of years ago), this article was not in the KB (or at least, I was unable to find it. Fortunately, I was able to work out the solution on my own. Every now and then, I forget to check the file sizes when build a maintenance release, and run into the problem again. Nice to see it’s finally being addressed.

The other fixed bug that caught my attention is KB Article 312218, “BUG: Deadlock in Multithreaded Process If You Use Declare Statements for APIs in Visual Basic ActiveX .dll Files or .ocx Files.” The short version is this: VB6-authored DLLs which use the Declare statement to access API functions can deadlock things like IIS and MTX. If you’re using such a DLL under IIS, it’s running under one of these two executables. I don’t know how long this problem has been documented, but it may be the answer to many untraceable, non-reproducable issues I’ve had. The problems occur on a production IIS webserver that uses a custom COM component written in VB6 for mainframe access. I think I’ll be putting a new build into production soon. This one really ticks me off, since it I’ve been having these problems for a long time, and since it affects such core techonologies… the ones Microsoft spent so many years convincing me to use (before .NET came along and changed the rules. Again.)

If you, like me, have any ongoing interaction with VB6 or VC++6, give this service pack a look. If not, well, congratulations.

Both comments and pings are currently closed.

Comments are closed.