is a page on getting VbClassic
applications reimplemented to run on machines hosting MicrosoftWindows
As most of the VbClassic
applications are clientServer type applications, the information discuss here may not apply to situations where other uses of VbClassic
was deployed in other ways (e.g. in ActiveServerPagesInVbClassic
Another assumption of this page is not to use (often quite good) OpenSource
tools. Quite often, SystemsIntegration?
complexities of a hybrid solution are a major concern.
Assumptions for an EnterpriseApplication solution
The "migrated" application should have a reasonable chance of being compatible with WindowsLonghorn
, but it is not necessary to use any new WindowsApi?
If the application uses data (most do), an acceptable solution will probably have its data hosted in a SqlServer
MicrosoftWay approach to migration
is to use the most recent release of their product. At this writing, it meant the yet unreleased DotNetFramework WindowsForms
An Apr05 application migration strategy can be found at http://msdn.microsoft.com/vbasic/default.aspx?pull=/library/en-us/dv_vstechart/html/appmigrationstrat.asp
For simple cases, a MicrosoftExpress
solution may suffice. If this applies, the applicable paper (2003 paper migrating to AspDotNet
) is located at http://msdn.microsoft.com/asp.net/migration/default.aspx?pull=/library/en-us/dnaspp/html/aspnet-movingvbtoaspnet.asp
Other ways that are Microsoft friendly
implementation using MicrosoftDotNet
Other ways MS (and your manager) don't want to know
What is all this talk about future MS OS's busting VB6 applications? If a new OS cannot run VB6, likely it won't run a lot of other existing things also. With Linux eating into MS's market share, I don't think MS would really risk pissing off that many people. I think they are bluffing.
- Microsoft typically don't bluff about breaking compatibility. They did it more than once to their OS when it served their purposes. They may have put away an unreleased safety mechanism in case user resistance becomes too expensive to manage.
- In WindowsXp SP2 already there are new APIs introduced in the name of security. I am speculating one way to rid VbClassic apps is for InternetExplorer (7) to break the HTML component used by VbClassic 6, making it necessary for a rewrite once IE7 becomes widespread.