Backward compatibility !
Backward compatibility is something software developers have to consider when writing their next generation of software. The question is, is it important ?
My answer is yes!
Let’s take something like Windows. I read an interesting article which discussed the different views within Microsoft about whether backward compatibility in the Windows operating system was important. In the past it was actually critical, but things have changed. (read that article here: http://www.joelonsoftware.com/articles/APIWar.html )
Does backward compatibility make a difference ? Absolutely! Just the fact that many Windows 95 applications can still be run on Windows XP is amazing. Now when we write our own software, we have to consider the effects it will have if we make “big” changes in the software when customers upgrade. Now at times one must make changes, but how does one best handle it ?
If you must break backward compatibility, make sure it really is worth it and make sure you do it with as few changes as possible. The less the end user has to change to deal with this, the better. Provide some migration tools when something does change and such tools must work flawlessly. The migration tools Microsoft added for VB.NET so you could port VB apps (5.0,6.0) I hear were terrible, at least from the viewpoint of many VB programmers. From what I have read on the web, many were unhappy with the bigs changes to Visual Basic.
Now in my own case, backward compatibility is a real issue, since I write tools for programmers. EZGUI has a pretty large API of its own and any changes I make could break a lot of my customers code. Here are two examples of how I have dealt with this:
(1) In the Visual Designer, the Form files use a proprietary file format and it has changed a number of times between versions. What I did was make the Visual Designer capable of reading the old files and automatically converting them to the new format. From the earliest versions of EZGUI, I added a file version record in the files, so the Designer could know what version created it. The new designer would be able to check the version and then convert the file when it was loaded and then when you saved the file it was saved in the new version format. Once converted you can’t read the file in an old designer.
(2) When I needed to add parameters to an EZGUI command (sub/function) it was easy to do, by using two different techniques. Some commands pass properties as a string (ie. “IES”) and each character represented a property, so it is easy to simply add a new property character for something new. In the case where I needed to radically change a command call, I found that it was best to do the following. If I had a function say called EZ_MyFunction, I would first change its name to something slightly different like EZ_MyFunctionEx. I would change the parameter list to add new parameters, while leaving the old ones “as is”. Then I would create a new wrapper function with the original name and have it call the new function and pass default values for the new parameters.
It would look like this:
FUNCTION EZ_MyFunction ( BYVAL P1&, BYVAL P2&) AS LONG
END FUNCTION
would become:
FUNCTION EZ_MyFunctionEx ( BYVAL P1&, BYVAL P2&, BYVAL P3&) AS LONG
END FUNCTION
FUNCTION EZ_MyFunction ( BYVAL P1&, BYVAL P2&) AS LONG
EZ_MyFunction P1&, P2&, 0
END FUNCTION
You can add new functionality without breaking the old, but it requires some commitment to backward compatibility. If you must make signficant changes to the software, make sure you document those changes well so the end user knows how to handle those changes with the least amount of problems. If you write tools for programmers, I think that backward compatibility is even more important, than with software meant for end users alone. Now this does not mean that one may never need to break backward compatibility. It’s just that is has to be for a really important reason. I had to do this with the code generation for EZGUI’s Visual Designer. EZGUI 3.0 could only generate code for one form at a time and once generated you couldn’t go back to the designer to regenerate the code while saving the code you already generated. EZGUI 4.0 implimented the new Smart Parser, where you could move back and forth between the Designer and your favorite code editor, as well as work on an entire project. Majors changes in the code generation were necessary. In this case it was worth it and customers were willing to change how they created applications to the new style for the benefits of the new designer. The runtime GUI engine though still was backward compatible, so customers could still maintain older applications, even though they couldn’t port them to the new designer. They could continue to hand code their older applications while benefiting from the new features in the runtime. The new designer also could even generate code for new Forms for old applications and then generate only a single forms code for old applications. Then it could be pasted into the old application or put into an include file and included in the old application. Of course new projects would be built using the new designer, but old projects still could be maintained.
The key to changes which must break some degree of backward compatibility is to at least provide reasonable “work arounds” so older stuff can still be dealt with, while the customer can use the new features for new projects. As long as the customer has some kind of work around that will allow them to get the task done, they can live with the changes.
Now as far as writing software which will be able to run on a variety of operating systems (ie. Windows 95 to Windows 7), you have to make sure you take into consideration the changes made in the operating system. EZGUI is one of the few development tools that does this. It is quite common for programming tools to keep moving forward to add features in the latest operating system. At the same time the developers of such tools find themselves having to make the decision to not support older operating systems. First they drop Windows 95 support. Then they drop Windows 98/ME support. At some point they may even drop Windows XP support. Why ? Because the changes in the operating system require them to make changes in their tools, which make them no longer backward compatible. Not so with the EZGUI GUI engine! Fortunately the designers of Windows were smart enough to add the ability to dynamically load external DLL’s, rather than be forced to have them static. In PowerBasic if I declare an external API function and use it, then when the application runs, if that function does not exist in the version of Windows it is run on (ie. Windows 98), the operating system will generate an error message and the application will not run. Instead of this, the EZGUI runtimes will poll the operating system to find out what version it is and then if a newer API is required and the operating system has it, the call is made by loading the DLL (using LoadLibrary) and then getting the function address from the operating system and then make the call via a pointer. If the function does not exist, the runtime will know and will either ignore the call or will use an alternative if available. This allows the runtimes to work even on Windows 95, while allowing it to access new features in Windows 7.
Why is this important for EZGUI ?
Let’s say some of my customers write software for inhouse use only. Maybe they have been using EZGUI for years and they still have some older PC’s running Windows 98 (or even 95). The computers are still working and doing their tasks fine. The customer can maintain the old software they wrote years ago and not have to throw away the old PC’s (simply because they can’t program for them any more). The customer can also use EZGUI to write new software for their new computers (ie. Windows 7) and have the benefits of the new operating system and features EZGUI provides for it. This is all possible because I consider backward compatibility very important, even being backward compatible in the operating systems my tools will run on. When the time comes in the future and even some programming tools won’t be able to work on even Windows XP, EZGUI users will still be able to write apps for Windows XP, ME,98 and 95. This is a real benefit for those who write a lot of inhouse software. Some companies may have thousands of inhouse applications, so with EZGUI they will be able to maintain them when other companies are wasting money in throwing away older computers and buying new ones because their development tools won’t work on the older computers.