This week Microsoft updated its support statement for Visual Basic 6.0 to include the upcoming Windows 7. Even though the original idea was to not support VB6 in Windows 7, given the outstanding demand, the runtime WILL BE included in the OS.
To summarize, the support status of the different Visual Basic 6.0 components is:
- Visual Basic 6.0 IDE: Unsupported as of April 8, 2008.
- Visual Basic 6.0 Runtime: Supported for the lifetime of Windows Vista, Server 2008 and 7. *This is the big change in the Support Statement*.
- Visual Basic 6.0 Runtime Extended Files: The supported versions are here.
Even though the runtime components will be supported in Windows 7, it is important to consider the implications of the IDE not being supported (as I described in this post). There are also additional advantages of moving to .NET such as 64-bit support (VB6 apps are 32-bit only) and all the productivity, maintainability and deployment gains provided by the platform.
A while ago, I blogged on the benefits of migrating from VB to .NET,
based on an analysis that one of our customers did before engaging in the
upgrade process. They had about 124
applications, for a total of more than 5
million lines of VB6 and ASP code that needed to be migrated to C# and ASP.NET to comply with corporate policies, while
they expected more than US$40M of accumulated benefits in 5 years as a result
of this investment.
Well, the migration was completed some time ago, and they’ve
been including several other applications during the process, and we’ve just
released the case study for the original
engagement. The customer is Banamex, a
leading Mexican bank, part of Citigroup, and the project implied an
unparalleled methodology for collaboration between customer and provider teams,
taking into account that Citigroup’s information security policies required to
establish an appropriate mechanism for protection of sensitive data. Not to mention
extremely tight deadlines!
The business logic and functionality had to remain intact, and dependencies
with non-authorized providers, like proprietary runtimes, were just out of the
question, and using ArtinSoft’s
Visual Basic Upgrade Companion allowed reaching 100%
functional equivalence on time and on budget. You can read the complete Banamex/Citigroup case study
here.
This week we published a new case study on the migration we performed for Banamex, part of Citigroup and one of the largest Mexican banks. In this project we migrated 124 Visual Basic 6.0 and ASP applications from different divisions of the bank to C# and ASP.NET. All in all, we migrated over 5 MILLION LINES OF VB6 AND ASP CODE. This is the largest VB6 to .NET migration we’ve done so far, it was a huge success story – so much that we are now working on the migration of some other applications that weren’t originally included in the scope of the project.
You can read the details here.
We’ve just released a new case study
that shows how one of our customers saved lots of time and money by using our Visual Basic Upgrade Companion tool
to migrate its flagship application from VB to .NET. Based in South Africa, MDA Property Systems provides software solutions to the real state
sector. Its MDA Property Manager application is a comprehensive package for
rent collection, lease management, facilities management, integrated property
accounting and asset management, employed by more than 1800 users across 250
companies. With more than 600,000 lines
of VB6 code it encapsulated decades of business knowledge, so MDA licensed
our tool to perform the conversion to VB.NET with minimal risk and using their
own internal resources, after discarding a manual rewrite and the Upgrade
Wizard
Also, it was very important for MDA to use the newest
technology instead of just being able to run Visual Basic 6 style code inside
the .NET Environment, and using ArtinSoft’s Visual Basic Upgrade Companion
guaranteed that they will be getting native
.NET code, without any ties to third-party runtimes. RDO was transformed to
ADO.NET, third party controls were converted to native .Net controls, Component
One’s True DB grid was upgraded to the latest version of that component, and
coding standards that were common place when developing in Visual Basic 6.0
were also migrated to equivalents in VB.NET. It allowed MDA to save on valuable
resources: total savings for this
project were more than 3 years of development time and US$300,000, and they
are now ready to start taking advantage of compelling new features that will
extend the technological life of its product.
Read the complete MDA case study here
Danish magazine Version2 published an interesting article last week on VB6 migrations: http://www.version2.dk/artikel/9908-saadan-flyttes-milliarder-af-kodelinjer-fra-vb6#forum_post_anchor .
Microsoft is finally waving goodbye to Visual Basic Version 6. Its successor, VB.Net, is not backward compatible, but the company Artinsoft from Costa Rica can help with a translation machine.
By Tania Andersen, Wednesday 11 February 2009
This article really shows momentum in northern Europe.
Enjoy!
My good friend Jafet, was recently dealing with an interesting bug in Visual Studio.
He created a simple Visual Studio Project that had just an interface that he exposed thru COM. He’s intention was to compile the Class Library and use the TLB file in other projects, but after building the solution he found out that there was no TLB file generated.
After some tests he finally found out that Visual Studio does not generates a TLB if there are not classes in the Project. So your options are, add a dummy class to your project or invoke the TLB tool from the command line.
:)
A quick post to let you all know that we now have a trial available for download of the Visual Basic Upgrade Companion Developer Edition. To obtain the trial you need to fill in your information here, and we will email you the download link and the necessary licensing information to activate the trial.
The trial will allow you to migrate up to 2,000 lines of code simultaneously, and has a limit of 10,000 lines of code total – which means that every time you migrate some code, the amount of lines you migrated are discounted from the 10,000 total.
So don’t wait and download the VBUC DE trial now!
Remember that you can also request a trial for the Enterprise Edition of the Visual Basic Upgrade Companion at this page. You will need to run the Assessment Tool first, and based on the results we will send you a custom trial for a portion of your application.
Several times I’ve mentioned the Type Inference feature of the Visual Basic Upgrade Companion. The main objective of the component that we call the “Typer” was to eliminate Upgrade Issue 1037 (Couldn't resolve default property of object ‘x’) that appeared then the VBUC wasn’t able to correctly determine the data type of a variable and consequently couldn’t resolve its default property.
Even though dealing with EWI 1037 was the design goal, having a typing mechanism in the VBUC allowed us to improve a great deal of transformations. One particular feature that benefitted from it was the migration of VB6 Enums. To illustrate this, let’s look at an example.
First, let’s see some VB6 code (doesn’t really do much except use Enums):
1: Public Enum Myenum
2: EnumValue0 = 0
3: EnumValue1 = 1
4: EnumValue2 = 2
5: EnumValue3 = 3
6: EnumValue4 = 4
7: EnumValue5 = 5
8: EnumValue6 = 6
9: EnumValue7 = 7
10: End Enum
11:
12: Dim enumUsage As Integer
13:
14: Public Sub MyMethod()
15: enumUsage = EnumValue1
16: enumUsage = 4
17: If enumUsage = EnumValue4 Then
18: enumUsage = EnumValue7
19: End If
20: If enumUsage = 7 Then
21: enumUsage = 5
22: End If
23: End Sub
After running the code through the VB Upgrade Companion we get this:
1: Public Enum Myenum
2: EnumValue0 = 0
3: EnumValue1 = 1
4: EnumValue2 = 2
5: EnumValue3 = 3
6: EnumValue4 = 4
7: EnumValue5 = 5
8: EnumValue6 = 6
9: EnumValue7 = 7
10: End Enum
11:
12: Dim EnumUsage As Myenum
13:
14: Public Sub MyMethod()
15: EnumUsage = Myenum.EnumValue1
16: EnumUsage = Myenum.EnumValue4
17: If EnumUsage = Myenum.EnumValue4 Then
18: EnumUsage = Myenum.EnumValue7
19: End If
20: If EnumUsage = Myenum.EnumValue7 Then
21: EnumUsage = Myenum.EnumValue5
22: End If
23: End Sub
The VBUC performs some very subtle transformations to improve the quality of the generated code. Let’s look at them in detail:
First of all, the usage pattern for the variable EnumUsage is analyzed by the Typer, and it determines that it is always used to store a value of the Myenum Enum. Thus, it infers that the correct data type should be Myenum instead of Integer, as seen in line 12:
12: Dim EnumUsage As Myenum
Since the Typer keeps track of the different ways in which a variable is used, and of the values that are assigned to it, it provides information to the VBUC so it can replace the assigned values with the corresponding enumeration. This applies even for comparisons – the code is translated from:
16: enumUsage = 4
...
20: If enumUsage = 7 Then
21: enumUsage = 5
to (notice the if in line 20):
16: EnumUsage = Myenum.EnumValue4
...
20: If EnumUsage = Myenum.EnumValue7 Then
21: EnumUsage = Myenum.EnumValue5
This is just one of the features that we have worked on over time to improve the quality of the code generated by the VB Upgrade Companion. It was built on top of the functionality provided by the Typer, and works with both VB6 built-in and user-declared enumerations. As shown in the example, this makes the code easier to maintain, and even looks as if it was written originally in .NET. :)
I know this is completely off-topic to what I normally blog about, but I’ve been having problems this past couple of days when trying to checkout a document from SharePoint using Internet Explorer 7. It crashes every single time – which has been a very frustrating experience, to say the least. I have no idea what caused it to (mis)behave this way. Anyway, turns out the fix was incredibly easy:
- Close all IE7 Windows
- Run Microsoft Office Diagnostics from Start->Programs->Microsoft Office->Microsoft Office Tools
- Click on Run Diagnostics, wait a few minutes, and you should get a dialog saying that 1 repair was performed:
- Continue using SharePoint normally
FYI, I am using MS Office 2003 and Windows SharePoint Services 3.0.
As a Visual Basic 6.0 developer you may want to become yourself familiar with the .NET platform before putting it into production (and making the corresponding investments). In this blog post I wanted to give some pointers to commonly used resources that can help you in that regard.
To run one of the latest Microsoft operating systems you can take advantage of the VHD Test Drive program that I blogged about some time ago. Through this program you have access to a large number of OS configurations that you can try out for a limited time. The ones I would recommend to get started are the Windows Vista 30-Day Eval VHD, the Windows Server 2008 Evaluation, and the Microsoft Windows Server 2003 R2 Enterprise Edition VHD. Remember you need either Virtual PC, Virtual Server or Hyper-V in order to run the virtual machines.
You’ll also need to install Visual Studio 2008, and for this you can either install the Express Editions (which have some limitations, but are free), or a 90-day trial version of Visual Studio 2008 Professional Edition or Visual Studio Team System 2008 Team Suite. Another alternative is to download a full virtual machine with Visual Studio Team System 2008 Team Foundation Server installed.
Also, to get familiar with specific .NET features, you can take advantage of the free e-book offer and the additional content currently up at Microsoft Visual Studio 2008 Learning Portal.
Because of some queries we’ve had in the past few days, I think it is time to revisit the differences between the Upgrade Wizard that ships with Visual Studio .NET (2003,2005 & 2008) and the Visual Basic Upgrade Companion (VBUC). The VBUC is a different product, with very different capabilities than the Upgrade Wizard. We have a detailed comparison over at the Visual Basic Upgrade Companion vs. Upgrade Wizard page, but here is a brief overview of the main differences:
- C# Generation: The Visual Basic Upgrade Companion is able to generate C# directly from the Visual Basic 6.0 source code, as an alternative to Visual Basic .NET.
- Structured Error Handling: The Visual Basic Upgrade Companion includes features to remove unstructured “spaghetti” code and replace it with structured flow control statements in .NET. All unused labels are removed from the resulting code. Plus the most commonly used “On Error ” patterns are currently recognized and replaced by the tool. This is important for C# migrations, as it ONLY supports structured error handling.
- .NET Native Libraries: Instead of upgrading VB6 code using the Visual Basic Compatibility Libraries like the Upgrade Wizard does, the Visual Basic Upgrade Companion promotes the use of .NET native libraries whenever possible.
- Type Inference: The VBUC contains a typing system that accurately assigns correct .NET data types to existing VB6 variables, functions, fields, parameters, etc
- Stub generation: To ease the compilation process, the Visual Basic Upgrade Companion generates an empty declaration (stub) in a stub-dedicated source code file and into the converted project for each library element which occurs in the original application and does not have an equivalent in .NET. All the references to these not-converted elements are translated into references to their corresponding stub declarations. This strategy does not fully resolve the lack of .NET equivalent elements, since the stubs will require manual implementation, but, it saves an important amount of time during the manual changes stage.
- Code quality enhancements: The VBUC generates higher quality code with more mature and exact transformations. These transformations include data type enhancements and grammar pattern transformations and detailed code improvements. A detailed explanation of these transformations can be found on the VBUC vs. UW page.
- Multi-Project Conversion: The Upgrade Wizard is able to convert one single VB6 project file (*.vbp) at a time. Hence, if the user wants to upgrade a complex VB6 application with this tool, several considerations must be taken in order to accomplish full functional equivalence. The Visual Basic Upgrade Companion allows the conversion of multiple Visual Basic 6.0 projects. It performs a separation between the pre-processing and migration stages in order to fix problems like the use of by-ref parameters, interfaces, renaming and typing among the different projects. The pre-processor environment solves the references among projects and simplifies the overall migration process.
- .NET Enumerations: Another important Visual Basic Upgrade Companion feature, absent in the Upgrade Wizard, is the replacement of numeric literals assigned to several control properties with .NET enumeration equivalents when possible, so that the generated Visual Basic .NET code is more legible and maintainable.
- 3rd Party Library Extensibility*: The VBUC can be customized to convert any third party library to its native .NET equivalent. It ships with support for several libraries out of the box, which are detailed in the VBUC vs. VBUW document.
- Legacy Data Access to NET*: The VBUC upgrades the legacy data access models (ADO, RDO, DAO, ADOR) to .NET equivalents, employing special transformation rules and helper classes (for some specific source/target combinations). On the other hand, the UW generates a target application that still uses those legacy data access models to communicate with the database via COM Interop wrapper calls.
- Custom Maps*: The Visual Basic Upgrade Companion Custom Maps extensibility, allows the user to upgrade their non-supported libraries and controls using a simple set of user-defined transformations.
- User declarations advanced refactoring*: The Visual Basic Upgrade Companion manages all the user declarations to perform tasks such
as using standard Naming Conventions for the .NET languages and recognizing conflictive user-declaration names to assign new denominations (including all of its references).These tasks improve the resulting source code readability and hasten the manual change stage.
- COM class exposure*: When this optional feature is enabled, the Visual Basic Upgrade Companion will generate attributes for the COM-exposed classes and their members, in order to keep the resulting assemblies exposed through a COM interface. This enables the resulting components to be called from other non-managed components via COM.
Make sure you download the PDF on the Visual Basic Upgrade Companion vs. Upgrade Wizard page for additional details. Items marked with * are ONLY available in the Visual Basic Upgrade Companion (VBUC), and are not available in the VBUC Developer Edition.
One of the key features of the Visual Basic Upgrade Companion (one that is not present in the Developer Edition, BTW) is that it’s functionality can be customized and extended. By doing this, developers working on a migration can have the VBUC do as much of the work as possible for them, minimizing the manual work and producing a higher quality product that satisfy both the developer’s and end user’s expectations. Performing repetitive changes to, for example, replace the data access components from VB6 (ADO/RDO/DAO) with native .NET data access (ADO.NET), is better done by the VBUC at migration time. This also applies to particular programming patterns used by organizations that need to be replaced by .NET-native patterns, and to coding conventions that vary between VB6 and .NET languages.
The Visual Basic Upgrade Companion includes three mechanisms to customize the generated code: Migration Profiles, Custom Maps and Additional Customizations.
Migration Profiles
A new feature that was introduced in version 2.0 of the Visual Basic Upgrade Companion, it gives end users control over which features and transformations to use for a particular migration, by using the concept of Migration Profiles. These profiles provide two types of rules that can be switched on/off. The first type, Code Conversion Rules, that deal with patterns applied to the code, such as generating structure error handling (try…catch) from On Error…Goto statements or applying commonly used naming conventions to the code. The second type is called Component Maps, and deal with translations from from one ActiveX component, such as a status bar or a grid, to a native version of the component.
Profiles are managed through the Profile Maintenance screen:
Custom Maps
The Visual Basic Upgrade Companion includes a “mapping” mechanism that allow end-users of the tool to define the transformation of one element of a library used in the VB6 code to a member of an assembly in .NET. This allows a migration team to identify and implement time-saving transformations, and, when combined with the implementation of an adapter for the .NET component, can speed up the migration process dramatically.
The Mappings are defined through a GUI editor launched from within the VBUC itself:
Once the mappings are defined, they can be switched on and off in the migration through the Migration Profile Maintenance Window:
Additional Customizations
ArtinSoft’s VBUC development team can also include additional complex rules in the VBUC, including customizations for items such as error handling patterns, architectural modifications, and others. These customizations also include mapping COM controls to in-house libraries, or force in-house naming conventions. This was a decision point for one of clients in the United Kingdom, Vertex Financial Services, as documented in the Vertex Omiga case study:
“Vertex decided to migrate the Omiga application to C# using a customized version of the Visual Basic Upgrade Companion, a tool developed by ArtinSoft based on artificial intelligence technology. ArtinSoft was highly recommended by Microsoft UK, and the customization of this migration tool enabled Vertex to automatically convert coding patterns and meet its preferred standards.”
These type of customizations require some modifications to the VBUC that can only be performed by ArtinSoft’s in-house team. It is a very valuable option that allows companies to get a an end product which furthers increases the return on investment from the migration.
Earlier this week we launched an joint initiative with Microsoft and Avanade in the UK for helping Visual Basic 6.0 developers move their applications to .NET. The initiative consists of several parts:
The initiative is UK-only at the time, but if you want to take advantage of these time-limited deals feel free to contact us. The press release for the campaign can be found here and at our website. Eric Nelson from Microsoft has been heavily involved - you can read his blog post on the initiative here.
The campaign has been well received so far. In the two days since launch, we already have several leads interested in both offerings!!
Jointly with the Visual Basic 6.0 migration campaign we are launching in the UK, today we released the Visual Basic Upgrade Companion Developer Edition. This is a scaled down version of the Visual Basic Upgrade Companion, targeted at individual developers that want to migrate their Visual Basic 6.0 applications as fast and painlessly as possible. It has a license that is valid for three months and allows you to migrate an application of up to 50,000 lines of code.
The VBUC Developer Edition does have some fewer features than the fully-fledged Visual Basic Upgrade Companion. All the features that we decided to include in the Developer Edition, however, are targeted towards automating as much of the migration process as possible. So, we left out features that have been introduced by the request of our enterprise customers over the 7+ years the tool has been on the market (yep, we were already doing VB6 migrations before the official release of .NET - and it wasn't all fun with the Betas). We made it so that getting an application up and running in C# or VB.NET is as simple as possible.
Here you can see the VBUC Developer Edition in action (video recorded by yours truly :) ):
And, as an introductory offer, The VBUC Developer Edition will only cost £199 for a limited time. So why wait?
Starting tomorrow January 27th we will be
engaging with Microsoft on a campaign aimed
towards helping companies and developers in the UK move their Visual Basic 6.0
applications to the .NET platform. This is not the first time we provide
migration solutions in that territory,
since we have lots of customers
there already (you can read some of our case studies and references here), but this is the first occasion
we join forces on a massive scale effort locally with 2 of our major partners:
Microsoft and Avanade. ArtinSoft will be providing tools, resources and
guidance, along with limited-time offers during this campaign. For example, we’ll
have a 10% discount on licenses of our Visual
Basic Upgrade Companion for the enterprise level, while launching the Visual
Basic Upgrade Companion Developer Edition at a special introductory price
of only £199. For those who require a turn-key solution, we have also partnered
with Avanade to deliver the most
comprehensive, cost-effective Visual Basic 6.0 to .NET migration solution. So
if you are based in the UK and still have Visual Basic 6.0 investments that
need to be leveraged, click here to learn
more about this campaign, and contact us as soon as possible to take advantage
of this unique opportunity.
Recently I had to deal with targeting an XBAP application that had some Windows Forms controls.
The problem is that those controls can only be used in a trusted environment. If you try to debug an XBAP with some Windows Forms Controls you will get an exception like:
Message: Cannot create instance of 'Page1' defined in assembly 'XBAPWithWinForms, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'. Exception has been thrown by the target of an invocation. Error in markup file 'Page1.xaml' Line 1 Position 7.
It took me a while to found a solution, and it was thru Scott Landford Blog that I found a way around.
In short what he recommends to do is:
Change your settings to:
Start Action->Start external program = %windir%system32\PresentationHost.exe
In my case (and the case of most people that is: c:\windows\system32\PresentationHost.exe)
Start Options->Command line arguments = -debug "c:\projects\myproject\bin\debug\MyProject.xbap" -debugSecurityZoneUrl "http://localhost:2022"
Copy the value from the Start URL after the –debug argument
Very import for using WinForms components you must run in FULL TRUST
Here is some XBAP code using a WinForms WebBrowser. They designer does not like it a lot but it works:
XBAPWithWinforms.zip
ArtinSoft recently published a number of case studies of Visual Basic migrations for ISVs. The projects were successful both from the technical as well as the economical perspective. If you are an ISV and you are considering an evolution of your application and a port to the .net platform I encourage you to take a look:http://www.artinsoft.com/vertex-omiga-vb-to-net-migration-case-study.aspx
http://www.artinsoft.com/vertex-supervisor-vb-to-net-migration-case-study.aspx
http://www.artinsoft.com/hsi-latnav-vb-to-net-migration-case-study.aspx
In this blog I am trying to be as unbiased as possible in reporting my opinion with regards to VB migrations. This time I am mentioning the case studies as evidence that a lot of the conceptual discussions that I have are actually happening in reality. It is interesting to see how many of the comments to this blog tend to be from skeptics and from people that just love VB6 and do not want to abandon it. My purpose is to show that there is life after VB6 and that an automatic migration is not only possible but, in many cases, a great alternative for your evolution plans.Please let me know what you think of the case studies.
We were watching with great interest and seriously thinking about the nice videos from Anders Hejlsberg recently presented at PDC2008, regarding programming languages and particularly covering the future of C# 4.0; (JAOO). Both talks offer really interesting perspectives that can be useful when thinking ahead about new challenges and opportunities on Software maintenance and particularly automated tools for supporting Software evolution, as it is the case of Software migration, usually.
We realize migration as a fundamental piece in fulfilling maintenance requirements derived from platform/framework evolution (as it will be the case of C# 4.0) beyond legacy migration in a traditional sense (I mean very old languages). That is if we consider shorter cycles of evolution not necessarily critical cases (i.e. those ones pushing to the edge of obsolescence a user application). We mean those new platform features offering better performance, scalability and maintainability chances, for instance. Thus, moving VB6 to VB.Net is a first stage. Moving to "a better" VB.Net a second one. We will return to this statement later on.
We first notice that in his presentation Hejlsberg talked about C# but it is assumable VB.Net will be providing in other flavor similar features and orientation as has been for these languages so far. Another very interesting player on this game is F# which deserves by itself another post; so we leave it aside just for the moment.
The language orientation Hejlsberg describes is one where C# becomes more multi-paradigmatic which essentially means for him covering three general aspects: more dynamic, concurrency and declarative expression power. These three aspects are clearly interrelated to each other in his vision.
The dynamic (DLR) facet should provide alternatives to compete with the proliferation of scripting languages a wave where strongly static typing is avoided (considered harmful for productivity by someone) even tough such kind of (rebel) languages will be sooner or later turn reasonable and will be offering capability for static types. Otherwise testing and maintenance will be more problematic as they are per se. In addition, the "dynamic" static type (no word playing here) will allow a cleaner interoperability with other .Net languages (scripting specially) and with COM itself, as he explains.
Turning something that looks like a compiler directive into a type might be disputable, we personally think; but independently of the name used the approach sounds very flexible because it is something open and controlled via an interface the programmer can use for his/her own needs. This also complements very well with the "var" declaration giving the impression of being programming in a dynamic language. However, we can imagine potential misuse and abuse of such a feature; hence the VS might play an important role during development.
Avoiding Javascript, using C# instead, is a subtle suggestion we might (over)infer from the message and if accepted we see an interesting space in the Web domain.
The declarative aspect, which takes the form of adopting functional programming (FP) idioms, look for avoiding, explicitly, side effects and mutability providing the compiler with better chances of optimization for parallelism as well as more readability and understanding. In other cases, more intuitive forms of static typing are now possible concerning co- and contra variance, by the way which is an added-value.
Concurrency should help to take advantage of multi-core computing without affecting program intentionality where FP is naturally an option for achieving that (see post1 and post2 )
An exciting challenge/opportunity derived from this vision (which is also valid for C# or VB.Net not necessarily product of a migration) is the ability to offer tools for platform related evolution without changing the language: refactoring for platform adoption, in other words (RPA).
A quite interesting and rich part of the C# 4.0 package is likewise "meta-programming" and the "compiler as a service" orientation. In particular, there will be a much more complete code model for C# available with an API for compiling in C# itself (presumably in F#, too!), as we see from the presentation. In such a case the space for developing tools for RPA should be easier which is an interesting point to analyze, we believe. In terms of how exploit the compiler as a service to produce a "migration as a service" in analogy.
My first language ever was GW-Basic. I was a teenager doing in summer work at a company that made polls about hair products and things like that. At that time I didn’t had a computer. They were tooooo expensive.
And I found a manual for GW-Basic. I stole it, to make a copy, my boss found out and he fired me :(. But then I had the power!! jeje. With my cousin Esteban we started out first programs. And we got our first sale :) :) :). It was the typical POS software for a small video rental company.
Ahhh, and that was just the beginning.
So, I really appreciate basic, with all its strengths and weaknesses. I do most of my development now in C#, I think due to my C++, java years, and know I am more used to its syntax, and I really prefer C#. But I consider Basic a real treasure.
Well recently while digging in the Microsoft Dev Labs I discovered SmallBasic. I was just browsing for some new stuff and I am glad to have found this jewel.
Artinsoft (the company I work for) is a company that has devoted a lot of time in the research of automatic software migration to other platforms.Not for nothing one of our flapship products is Visual Basic Upgrade Companion, so basic in any form is always a delight for me. (I will soon post a brief article about bringing VBScript back to life in VB.NET just wait and see)
Ok. Back to SmallBasic.
First of all. The interface is great!!!
It has a cool intellisense guide and you can even extend it :)
And they even resurrected LOGO!
I just hope to write a cool Turtle Graphics routine soon!
:)
I spoke to Paul Yuknewicz who is a Program Manager on the Microsoft Visual Basic team and who is quite involved with everything related to VB6 and its migration process. Paul said and I quote: "VB6 runtime will be shipping and supported as a part of Windows 7, however there are no plans to ship it in future versions of Windows." Microsoft will surely release an official document stating this in the near future. What is my take on this latest Microsoft move in the VB6 saga? Well, I guess Microsoft had to react to the fact that VB6 is still widely popular and that a lot of businesses have delayed (procrastinated??) the decision to move to .NET. From that perspective I believe this is the right move for Microsoft. They want to minimize the impact of the end of life for Visual Basic 6.On the other hand, I have to wonder, why do people seem to not want to upgrade? Over the years I have formulated a number of hypotheses as explained below.
-
Migration is perceived as expensive: In the short term is certainly cheaper to do nothing than to migrate, however, if you have a valuable asset you want to make sure you can extend its life (and therefore ROI) as much as possible. Automatic migration is the best alternative to achieve it.
-
Migration is perceived as lacking value: I have often heard how by automatically migrating an application at the end I get the same application and therefore I did not gain anything. This is also false. Once you upgraded the source code you have injected new life into it. Your application has suddenly extended its life expectancy and (again) its ROI. Maintenance and evolution of a .NET application is safer than of a VB6 app.
-
VB6 Applications are not evolving: Can this be true? It is possible that companies have VB6 applications that support a business function that is not evolving. If this is the case, leaving applications in VB6 is just fine and the fact that now Microsoft supports VB6 in Windows 7 gives a new breath to those applications. However, in my more than 15 years of experience in the IT industry I have yet to see an application that never changes! It is important to remember that the Visual Basic 6 Development environment is off main stream support by Microsoft.
-
Applications will be retired before VB6 stops working: This is a plausible for a number of applications. Companies sometimes choose a substitution strategy and just retire applications, or business processes stop being important and therefore the applications that support them are no longer necessary. These cases certainly happen, and a number of applications might be in this category but it cannot be the great majority of them! Additionally, companies sometimes believe that substituting an application for an equivalent one is cheaper than migrating them. Well, I dare them to review this assumption make sure they run a complete comparison.
-
It’s just procrastination: The famous “if it ain’t broken don’t fix it!” … do I have to comment on this?? May this be the reason why VB6 is still around?
-
There’s just too much VB6: This is the argument Gartner used to make for COBOL: it would be too expensive to migrate all the COBOL. In fact, I have even heard this from an IBM executive who told me that at some point they were scared that all the mainframe code would migrate to Java (and therefore business rules would no longer be trapped in a mainframe) but then they run the math and just relaxed! Of course, there is no real automatic solution for COBOL!!!! For VB6 is a different story (ArtinSoft infomercial: http://www.artinsoft.com/pr_vbcompanion.aspx ).
What is your position? Am I missing a category of reasons why VB6 is still around?