Maintenance Contract for legacy VB6 application

Years ago I created an application using VB6. Over the years I've updated and maintained it so that it works just fine with w9x, w2000, XP, Vista and Win7.

My customer now has a new IT/IS manager who would like to formulate some kind of maintenance contract so that he knows I will continue to keep the application working on future versions of windows.

He obviously accepts that it's an old application and that I'm not going to completely re-write it - for example I'm not going to make a .net or native 64 bit version as part of a maintenance agreement (that level of development would need to be negotiated separately)

So, the 'wording' of the contract would exclude that - in other words I'll maintain a 32bit application which works on 32bit windows and would depend on WOW64 if it was installed on a 64bit OS.

So, I'm happy to guarantee to keep it working on 32 bit windows but I can't guarantee that it'll work on WOW64 (or can I/should I ?)

How soon do you expect MS to stop actively selling 32bit Windows ?

Has anyone ever done any kind of maintenance agreement ? What did you include/exclude - any specific wording ? Suggestions ?

I've worked with this customer for almost 20 years so we're not going to screw each other I just want to make sure there's no misunderstandings.

Thanks
Ian

Moved To General Developer

It is awkward because you need to predict the future to some degree... while the VB6 runtimes have been supported by the OS so far, there are no guarantees that future versions of Windows will have that, even if they are 32 bit.

I expect future versions of Windows to be 64 bit only due to hardware reasons, but I also expect them to have WoW for 32 bit programs for many years (just like 95/98/ME/2000/XP had it for 16 bit programs). Whether that is enough or not we will have to wait and see.


You are right to explicitly exclude a re-write as part of this, but you need to be careful about how much effort might be required to get it running on the next version of Windows if it explicitly does not support the runtimes. While that is unlikely it is possible, and could mean an awful lot of work dealing with "bugs" that are effectively introduced to the runtimes due to the differences in how Windows is built.

I would recommend having something that says about the level of work involved, perhaps "less than 20% of the time for a re-write".

Hello Si_

Thank's for that input.

Your mentioning of them dropping support for VB6 runtime is interesting. Almost a topic for an entirely different thread.

I kind of feel that MS's continued compatibility with legacy applications is a ball and chain for the future development of windows. Once they can unhitch themselves from that ball and chain then we'll see a lot of changes/improvements.

I've never used the 'XP' mode in Win7. Although I do use Virtaul PC quite a lot. The fact that they've taken the time to include Virtual PC in Win7 as a way to run legacy applications makes me think that they're about to do something pretty drastic. Running legacy apps in a VM/guest os instead of in the host os is the way they intend to go.

At the moment running VM's in windows is not quite as 'invisible' as it can be on MacOS.

I use an Apple Macintosh as my main workhorse. Legacy VB6 development is done in a virtual machine (Parallels) and, believe it or not, XP runs faster on MacOS in the VM than it ever did on my real 'pc'.

The virtualization is also very smooth. On the MacOS desktop clicking a shortcut to a native windows app simply opens that app's window on the MacOS desktop. I don't actually see Windows, just the "app's" window. Obviously there's a Windows VM running in the background but I don't see it.

I suspect Microsoft will go down that route with Window 8. Running windows 8 (or 9) you'll start a legacy application and the app will appear to run in Windows 8 but, behind the scenes, there'll be something like an XP VM doing the work. Except that Virtual PC will be completely transparent so you don't actually see it.

So, if that was the case then we shouldn't worry about compatibility with legacy applications because they'll simply run in a VM.

or what do you reckon ?

The continuation of something like XP Mode seems like the most likely route, but it may still be limited to the high-end editions of Windows (such as Professional, which I presume your clients will have).

Assuming that happens, you will have virtually no work to do. :)

I work for a commercial software house and we have a 32 Bit system that we still sell partially written in VB6, and we guarantee support on 64 Bit Vista & Windows 7.

We do that because we have done extensive testing on those platforms and we know the product works. I would suggest that your wording should mention specific versions of Windows not just 64 Bit.

So say your product is supported on Windows 7 64 Bit for instance rather than saying it is supported on 64 Bit systems, this should cover you, and as and when new version of windows come out you can test against them and offer support as appropriate.