Visual Basic 6 is very similar to Visual Basic 5. To convert a Visual Basic 6 program so you can load it in Visual Basic 5, open the .VBP file in an editor such as Notepad. Find these lines (they may not all be present) near the end of the file:

    Retained=0
    DebugStartupOption=0
    CodeViewDebugInfo=0

If you use classes, remove the initial lines from the .cls module up to and including the END line.

If you do not use any of the new features in Visual Basic 6, you should now be able to load the project into Visual Basic 5. (Thanks to Tony Zaradich for pointing out the DebugStartupOption problem, Ignacio R. Diaz for pointing out the CodeViewDebugInfo problem, and Sergio Perciballi for telling me how to fix classes).

Note that it really should not be this way. Visual Basic could easily be smart enough to realize that it is looking at an different version of Visual Basic instead of a corrupt file. It should open the project without complaint, ignoring the unrecognized command and warning you that the project may not be loaded perfectly. I can't imagine why Microsoft would make it so you cannot load a file for a single new line in the .VBP file.

Click here for a simple drawing program that demonstrates a lot of useful techniques including forward and backward compatibility.

It is quite simple, actually. That's called being backward compatible. Microsoft should have NEVER made anything backward compatible. That's what is holding back the software industry. It's (the industry) is geared towards creating stupid software for stupid people. If we could somehow raise the education level of the common user, we could have some kick-ass software. But, NOOOOOOOOO, they all want to be able to do some "stupid" things, like opening a VB6 app in VB5.

And in regards to your statement of "Visual Basic could easily be smart enough to realize that it is looking at an different version of Visual Basic instead of a corrupt file. "

Well, first of all, don't equate 'intelligence' with software. It's simply a set of instructions which executes within some predefined set of guidlines.

Secondly, I'm glad that the Microsoft Software Engineer's did it that way. If you use VB the way it's "SUPPOSED" to be used, then it is "smart enough". Just open a VB5 project in VB6 and it "knows" there is a difference, and will be "kind"-enough to upgrade it for you.

I'm afraid I have to disagree with Micheal Bailey on this.

1. The industry is not geared toward creating stupid software, it is geared toward creating flexible software. Mr. Bailey does not appear to have a business-related approach to software engineering. If you have a department equipped with VB5 and VB6's additional features are only useful to one small project then it would be an enormous waste of money upgrading the entire department. However code re-use and generic programming mean that there should be no problem in using code written in VB6 in a VB5 application for the most part , whether it be a single class or an entire project.
2. It is possible to write intelligent software. I have encountered numerous apps which will, if required, ignore unrecognized lines and prompt for further guidance. If the "predefined set of guidelines" is flexible enough then the software can be considered intelligent up to a point.
3. Finally, software engineering is about making people's work and lives easier. Users no longer have to be able to program in assembler in order to get anything done with a computer. It is the engineer's task to provide functionality in an easy to use form. This is the way that VB is ' "SUPPOSED" to be used'

My line of work involves making small little GUI utilities that I distribute via e-mail. I prefer using VB5 because with it you are pretty much assured that your programs are going to be able to run on all platforms, without complaining about a missing VB6 run-time (MSVBVM60.DLL), which isn't present on most Windows 9x machines.

With VB6, you have to have the added overhead of a bloated packager with the VB6 run-time in it, which you have to ship each and every time you send a tool to a new contact, in case they don't already have the VB6 run-time already, which many do not. This effectively increases the size of a 50K tool to over a meg -- not fun to transfer over and over again via dialup.

Since VB5's run-time is standard with all but the oldest Windows 95 installations (and even then, there's a 99% chance the VB5 run-time has been installed by another app) all you need to do is send your utility -- using API calls instead of OCXs to avoid that hassle as well -- and you're set. No worries about packaging and deployment. The VB5-compiled EXEs tend to be a bit smaller too.

So to me, I see nothing but disadvantages to compiling with VB6 over VB5. I'd dare say that the vast majority of programmers, except those working in a large team on big apps that really take advantage of the new features, are needlessly using VB6, simply because it is (was) the "latest and greatest" thing being pushed by Microsoft. I'd say the same thing about VB.Net, unless you're a big-time team developer, whats the point? Hundreds of dollars spent on upgrading, for what marginal benefit?

But back to the issue at hand, I found the info above about how to make VB6 projects compatible with VB5 by just removing a few lines in the .VBP file very useful indeed. I've "reverted" dozens of small example projects and have yet to have one complain about a feature in VB6 that is missing from VB5. Often authors will include a pre-compiled EXE along with the source. The EXE often complains about the VB6 run-time. A quick re-compile using VB5 and the problem is solved.

This only confirms my suspicion that many people are needlessly using VB6 when VB5's functionality can handle most projects just fine.