Chapter 7 - Migrating Custom Applications and Scripts

  • Article
On This Page

Overview Overview
Compiled Code Application Migration Compiled Code Application Migration
UNIX Script Migration UNIX Script Migration
Summary Summary

Overview

Your organization may need to develop and maintain custom code and scripts for use with your CATIA system. If you have invested time in code development, you will want to leverage this investment with the new system. Therefore, techniques for the migration of custom solutions are of great importance.

Migrating CATIA V4 to CATIA V5 running on UNIX involves no changes in the operating system and requires few changes in the code in order for it to continue working. Most of the code issues surrounding upgrades arise because of the change to the Microsoft Windows architecture that can be made with V5 and which this guide is designed to address.

Custom applications are typically implemented either with compiled languages, such as C++, or with scripting languages, such as Perl or UNIX shell scripts. In this chapter, approaches to the migration of custom code will be discussed, first for compiled code, and then for scripts.

A more detailed approach can be found in UNIX Application Migration Guide Patterns & Practices at https://msdn.microsoft.com/library/en-us/dnucmg/html/ucmglp.asp

Compiled Code Application Migration

Organizations with a large code base of installed UNIX applications will be interested in the ability to continue using the entire suite of packages they have developed or acquired. If these applications were written to interact with CATIA, and they are being moved to Windows, the application will usually need to be migrated as well. Fortunately, there are ways to preserve your investment in this code while developing under, or moving to, Windows over a longer period.

Most applications are written in a compiled language. After you have written your code, it must be converted into a binary executable file, a process called compilation. No coding can be done if you have only this binary, which may be the case if you purchased the application off the shelf from a third party. If you have the source code, however, you can take the following approaches to move it over to Windows.

Options

Porting a UNIX application to Windows may be as simple as recompiling, or it may require significant redesign and recoding. It does require access to the applications source code.

There are four possible options for migration or co-existence between UNIX and Windows:

  • Quick port

  • Full port

  • Application rewrite

  • Co-existence

Detailed descriptions of these options appear in the sections that follow.

Quick Port

One of the simplest migration paths possible is to port the code directly to Microsoft Services for UNIX 3.0. Services for UNIX 3.0 includes Microsoft Interix, which provides a UNIX environment that runs on top of the Windows kernel, allowing native UNIX applications and scripts to work alongside Windows applications. This is achieved by obtaining the source code, installing it in the Interix development environment, modifying the configuration scripts and Makefiles, and recompiling the application.

The ported application may be successful immediately, or it may require modifications to the configuration scripts or Makefiles to account for the new hardware platform, the target operating systems, and local configuration information. It may not be possible to determine whether a quick port is possible without actually conducting the port. Extensive testing of the application is essential after the port to ensure that all features have been migrated successfully.

Advantages:

  • A quick port is the fastest way of migrating an application.

  • When the Interix environment is used, the native UNIX applications and scripts can be run alongside Windows applications on that platform.

Disadvantages:

A quick port may fail in the following scenarios:

  • The application proves too complex to be ported quickly.

  • Some parts of the application have to be rewritten for the port to be successful.

  • The code depends on some part of the UNIX environment.

  • The quick port uncovers some new issues in the code or shows that assumptions were incorrect.

Often, a quick port can be attempted as the first stage of the migration process. If it does not work, the results can be used as a basis for a full port or a rewrite.

Full Port

During a full port, the application is migrated with the minimum necessary changes to the source code using UNIX-compatible libraries and utilities available on the Windows platform, which can include Interix. Unlike the quick port, however, significant changes may be required to enable the code to run on the new platform. This can happen when the original code is not fully compliant with programming standards, or when code elements such as device drivers are specific to the original system.

Advantages

  • A large quantity of code can be migrated quickly.

  • The application can easily be run on both operating systems for a sustained period because there is a single code base where changes can be made.

  • The current look and feel of the UNIX application can be retained.

  • The business logic of the application is retained.

  • There is no need for new documentation or user training.

Disadvantages

  • If the original code is not fully compliant with standards, or when code elements such as device drivers are specific to the original system, a full port may require significant changes to enable the code to run on the new platform.

  • Extensive testing is essential.

Application Rewrite

Here, the application is recreated from scratch for the new Windows platform. Rewriting the application is the ideal approach to make full use of the Windows platform. Though this course requires the greatest amount of work, it also promises great rewards. This strategy has the highest potential risk, but it frequently produces the best results.

Advantages

  • A rewrite results in the maximum use of the advanced features of the native Windows environment, including the Win32 Application Programming Interface (API).

  • A rewrite offers the best performance in a native Windows environment.

  • You can standardize all of your organizations Windows coding in the Microsoft Visual Studio environment.

  • Rewriting offers the best possible integration with other Windows applications.

Disadvantages

  • A rewrite is potentially the most costly and time-consuming option.

  • A solution based on this strategy requires a thorough analysis of the UNIX application before a Win32-based redesign of the application architecture is undertaken.

A rewrite strategy is most appropriate when the costs of porting the application may outweigh the benefits, or when specific application qualities, such as performance or scalability, require that code be written specifically for the Windows platform.

Co-existence

To reduce the impact of code migration on users, you can plan a phase in which both the old version of an application and the new one exist simultaneously. With co-existence, the original application is retained alongside the new version while the application is being ported or rewritten. This approach significantly reduces risk because it allows the use of the original system should unexpected issues appear with the new application. However, a cross-platform source code control system is needed to organize and synchronize concurrent development on UNIX and Windows.

In this approach, choose a quick port, full port, or rewrite of the application, but retain the original after deploying the new version. There are a number of reasons to choose co-existence:

  • The two applications, original and migrated, can be run in parallel to minimize risk.

  • A new set of users or customers will use the ported application, leaving the original users unaffected.

  • A staged migration is planned between the original and the migrated application, enabling you to minimize disruptions to the working environment.

When planning to maintain co-existent applications, you should maintain parallel development and build environments in order to support both platforms on which the application will run. A major challenge is the synchronization of changes in code between the two versions. This may require a cross-platform source control system such as the non-Microsoft products Revision Control System (RCS), Source Code Control System (SCCS), Concurrent Version System (CVS), or Program Version Control System (PVCS). The native Windows source control system is Microsoft Visual SourceSafe, which supports the cross-platform Source Code Control Interface (SCCI) API. Interix supports the RCS.

A Mix of All Strategies

It might also be appropriate to mix strategies. This often happens with large applications where certain portions can be rewritten and others ported. Porting and then rewriting the application can be done to reduce the overall time requirements on the project, or to accommodate short-term time or budget constraints. For example, the migration could begin as a port and continue as an incremental rewrite based on the integration or evolution of portions of the application.

As in a port strategy, a common source code base across UNIX and Windows can be retained. This strategy is similar to the way in which UNIX software is ported between UNIX platforms because it allows developers to take advantage of platform-specific functionality.

To ensure the selection of the most appropriate strategy, perform a cost-benefit analysis that weighs the benefits of the strategy against its costs.

UNIX Script Migration

UNIX application and development environments commonly use scripts. These are text files with code that must be interpreted as it is executed. This includes shell scripts, such as those written for the bash shell, and Perl scripts, as well as other languages. These scripts may be used to automate parts of CATIA. If the scripting language used in UNIX is supported in Windows, it becomes a straightforward exercise to migrate the scripts. Otherwise, the scripts can be rewritten in a language that Windows supports, such as VBScript or JavaScript.

The following sections describe the available scripting options.

Interix

This environment, part of Services for UNIX 3.0, is able to migrate compiled applications. It also allows UNIX scripts to be moved to Windows with little or no revision.

Advantages

  • No migration effort. All the UNIX scripts will work on the Interix subsystem without change, including those written with sed, awk, Perl, and other languages.

  • This is an excellent option for programs using complex system calls such as fork, exec, or signal handling, which require a lot of effort to convert to Win32.

  • No retraining is required for using the current scripts and developing new ones. Users can continue to script in their familiar scripting language.

  • The UNIX to Windows migration effort can focus on the core migration of the desktops, servers, and CATIA itself, rather than the peripheral supporting scripts.

Disadvantages

  • The migration is not really complete because it still uses a UNIX style of scripting.

  • There may be a tendency for users to expect other familiar UNIX resources and functionality, such as file systems, path syntax, and user interfaces, after the migration.

  • There may be no clear perception of the benefits of migration from a user perspective.

  • The script may include no graphical user interface. Scripts developed natively for Windows can create an interface more easily.

  • Performance may be slower than a native Windows script. This arises from the extra load of running the Interix environment, as well as the script itself.

ActivePerl

ActiveState has developed the ActivePerl implementation of the popular Perl scripting language. ActivePerl can be used for migrating Perl-based scripts as a long-term or short-term option because it can run on both UNIX and Windows. Perl scripts migrated this way should require little or no rewriting to run on Windows

Windows Scripting Host (WSH)

WSH is an interpreter, built into Windows 2000 and later, for scripting languages including VBScript and JavaScript. It includes a set of objects for manipulating system configuration settings and files system resources, and it can be used with other object models provided with Windows and third party applications. WSH is frequently used to automate administrative tasks and create logon scripts.

Objects and services supplied allow the script to perform tasks such as displaying messages on screen, accessing network resources, and modifying environment variables and registry keys. Other languages, including Perl, Rexx, and Python can also be run under the WSH environment.

Scripts for batch jobs in UNIX are best migrated to WSH. However, as a short-term option, Interix can be used. UNIX style emulation tools such as Cygwin and MKS32 can also be helpful as a short-term solution for migration.

Summary

Customization of your UNIX implementation of CATIA can adapt the system to any specific requirements you may have. If you have already customized your system, however, the application may present challenges for the migration of CATIA to Windows.

Your custom application may consist of compiled code, such as that written in C++. In this case, a port of the code in which it is simply recompiled for Windows may work well. However, any code that references specific UNIX features or hardware will need to be rewritten. The Interix environment from Microsoft Services for UNIX 3.0 can help with this, but rewriting the application from scratch makes best use of the Windows architecture and can increase performance.

You may also have script code to migrate. The language this is written in will determine how difficult the migration of such code is. Various tools are available to help, including Interix, ActivePerl, and the Windows Scripting Host.

Disclaimer and Copyright Information

CATIA is a registered trademark of Dassault Systemes SA. The names of other actual companies and products mentioned herein may be the trademarks of their respective owners.