May 2009 - Posts

• Changing Software in these Times of Crisis Article at El Financiero

  The business-oriented newspaper, El Financiero, just published an article talking about the advantages of performing a migration instead of a manual rewrite. The article talks about how Banamex (part of Citigroup) saved an estimated 80% of the cost when compared to rewriting their 125 applications, totaling over 5 million lines of code. It also talks about the advantages of being in .NET, including how it allows customers to rapidly respond to changes in market conditions. You can read the original article in Spanish at the following link: Cambiar el software en estos tiempos de crisis or read the Google Translation in English. You can also check out the Banamex/Citigroup case study at the following link: Banamex - Citigroup turns to ArtinSoft to ensure compliance and business continuity through massive migration to C#.NET Posted May 17 2009, 04:46 PM by Jaguilar with no comments Filed under: Visual Basic to .NET, Why Migrate?

• Best-in-Class Companies more likely to use Code Conversion or Automated Porting Tools

  Yesterday TechNewsWorld published an article called Planning a Migration Route From Visual Basic 6 to .Net, which discusses some aspects of a report by the Aberdeen Group. The article contains lots of valuable information for those of you considering moving your VB6.0 applications to .NET, by giving a very good idea on the best practices performed by the “Best-in-Class” organizations. I wanted to touch briefly on some of the points from the article, and how it matches our experience helping Fortune/Global 1000 companies upgrade their applications to the latest technology. Something that is consistent with what we’ve seen is that 33% of the respondents from Best-in-Class and 15% of the “All Others” organizations engage a third party to assist with the migration. We at ArtinSoft, with our Consulting Services group, and along with our world-wide partners, have seen this as a growing trend, and have accumulated a vast a mount of experience that can be leveraged by these organizations to move away from legacy environments. Also, as part of our migration methodology, we promote a controlled process that first brings your VB6.0 application up to Functional Equivalence in .NET, and then you can use this as a base to enhance an improve your investment. For many clients we also use the extensibility capabilities of the Visual Basic Upgrade Companion to prepare the source code for these enhancements by automating specific architectural modifications required by our customers. These modifications represent an enhancement in itself, and also leave the code ready for further changes by making sure it meets all the practices and coding standards of the organization. The Vertex Omiga and Supervisor Case Studies are a good example in this regard – and we’ve done other migrations with even more important customizations that, unfortunately, I can’t mention directly. Finally, I want to quote the following text from near the end of the article: “The research shows that Best-in-Class companies are six times more likely than all other companies to use code conversion or automated porting tools in order to help accelerate part of the migration process.” You can read our case studies that show this is in fact the case, and we have helped many organizations save time and resources when performing migrations aided by using the Visual Basic Upgrade Companion. Posted May 08 2009, 10:51 AM by Jaguilar with no comments Filed under: Visual Basic to .NET, Why Migrate?

• On VB6 and Windows 7 XPM, Part Deux

  Yesterday I blogged about Windows 7’s XP Compatibility Mode, and have some additional pieces of information that I consider interesting if you are considering using it in the future: First of all, not all CPUs would be able to use XP compatibility mode. Take a look at this page over at Tom’s Hardware, and the post over at Ed Bott’s blog. I think the image halfway down the page on the second link speaks for itself – you probably won’t be able to know if the deployment target for your application supports XP Mode or not, which can complicate the installation experience. The second bit of information I want to comment about is the fact that even though applications running under XP mode appear seamlessly alongside Windows 7 applications, they are still running on a virtual machine. From what I’ve seen the boundary is not noticeable to the end user - the application’s shortcuts appear in Windows 7’s start menu, the tray icons appear in Windows 7’s tray, etc. But apps in XP Mode run completely separate from their Win7 counterparts, and the VM itself needs to be patched with its own version of Windows Update, requires specific policies applied to it, etc. It goes without saying that all this adds overhead to managing these type of deployments, and may cause incompatibilities if an app requires interaction with other programs installed on the Windows 7 side (VB6 apps using Office’s COM API is a common example – will you require separate versions of Office, one in the XPVM, and another one on W7 for daily use?). Finally, XP Mode uses Terminal Services and something similar to the RemoteApp mechanism to display applications on the Windows 7 desktop (not sure how other VMMs such as Parallels’ Coherence manage it) . Even though the integration is almost seamless, there are a few quirks here and there that make for an inconsistent experience (drag and drop files, etc), and may affect the performance and L&F of the application. This post argues that the best solution would be to use Microsoft’s App-V technology to virtualize “XP and older” applications. I agree that would be an ideal solution. But maybe there is a reason why it works like it does – so that you won’t get too comfortable. XPM, IMHO, should be considered as an intermediate step towards moving your legacy apps to the latest technologies. (As a side note, remember I did a lot of work on Virtualization, and think it is a good way to get the most out of your IT infrastructure resources. XPM, to me, is an excellent idea to start dropping all the legacy parts of Windows without compromising application compatibility, and a smart move at that. ) Posted May 07 2009, 07:46 PM by Jaguilar with no comments Filed under: Virtualization, Tools, Windows 7

• On Visual Basic 6.0 and Windows 7 XP Compatibility Mode

  As you are probably well aware, along with the release of Windows 7 RC came some big news that affect Visual Basic 6.0 applications: Professional and Ultimate Editions of Windows 7 will feature a Windows XP Mode for backwards compatibility with legacy applications. This means that even if you are using components that have issues with Windows 7, you will be able to run your VB6.0 application on the new operating system, albeit within a Windows XP virtual machine. It is important to mention that the VB team over at Microsoft was already making sure the IDE and VB6 runtime would work on Windows 7, as I commented before (second comment on that post) based on the Support Statement for Visual Basic 6.0 on Windows Vista, Windows Server 2008 and Windows 7: The Visual Basic team is committed to “It Just Works” compatibility for Visual Basic 6.0 applications on Windows Vista, Windows Server 2008 and Windows 7. The Visual Basic team’s goal is that Visual Basic 6.0 applications that run on Windows XP will also run on Windows Vista, Windows Server 2008 and Windows 7. The Visual Basic team is also committed to the Visual Basic 6.0 development environment running on Windows Vista, Windows Server 2008 and Windows 7. The objective of XP Mode is clearly to move forward the Windows architecture to the latest technologies, free of all the legacy bits required to maintain compatibility of old applications (read the History posts at the The Old New Thing blog for examples), while at the same time it allows developers to smoothly upgrade their applications without the threat of the application not working in the new OS. It is basically a compromise of old vs. new. And it is very easy to draw parallels between XP Mode and the approach taken by Apple, first with Classic and then with Rosetta, to smooth the transition to new platforms. But as was the case in those scenarios, Classic was eventually phased out, and Rosetta will eventually be as well. I personally think that this technology may end up being around for a while, and may even end up included in the next versions of Windows if there is enough customer demand for it. This has to be the same technology used in their Microsoft Enterprise Desktop Virtualization (MED-V) solution, targeted towards enterprise customers: “Microsoft Enterprise Desktop Virtualization (MED-V) provides deployment and management of virtual Windows desktops to enable key enterprise scenarios. MED-V 1.0 helps enterprises upgrade to the latest version of Windows even when some applications are not yet compatible.” Even in the scenario that XP Mode is supported for a long time, you still have to consider it as something that can be used for a smooth transition while you upgrade your applications to the .NET Framework, and not as an excuse for not upgrading. It can help you plan a gradual migration, were you first start migrating certain modules while leaving others in VB6, with tools like the Interop Forms Toolkit. And keep in mind that even though the application will run, the IDE is simply not supported anymore and neither are most controls that cause compatibility issues. And at the same time you will be missing the benefits of using the latest technologies and the increased productivity of the .NET Framework. Posted May 06 2009, 07:19 PM by Jaguilar with 11 comment(s) Filed under: Visual Basic 6.0, Visual Basic to .NET, Windows 7

• Visual Basic Upgrade Companion 3.0 Official Release

  Today we formally released version 3.0 of the Visual Basic Upgrade Companion, including both the Enterprise and Developer Edition of the migration tool. This is a significant new release, which has improved the efficiency of the conversion tool by reducing the amount of work required to the the applications to functional equivalence by over 30% (and more in some cases). All migration improvements are based on the feedback from the experiences of both our clients and our own consulting team, and we are very happy the changes have such an effect. I already talked about specific new features on a previous post. Also, today we went live with a new companion website to the VBUC at www.vbtonet.com. This repository of information should help you in all aspects of the migration, and includes both best practices for, for example, finding customization opportunities in the code, and both overall strategies and detailed examples on how to solve migration issues. This site is tightly integrated with the VBUC, and migration issues identified in the code by the tool will contain a link to latest information to help you solve the issue, like the following example: 'UPGRADE_TODO: (1067) Member MyMember is not defined in type Variant. More Information: http://www.vbtonet.com/ewis/ewi1067.aspx This library of information will continue growing over time, so make sure you come back often during your migration project to check out the latest content. You can read the official press release here. Posted May 06 2009, 12:34 PM by Jaguilar with no comments Filed under: News, VBUC Releases