VisualWorks 2.5.x to VisualWorks 5i Migration
With the release of VW 3.0 in March of 1998, followed by the release of VW 5i in March of 1999, there has been a large demand for information on the transition effort involved in moving from VW 2.5.x to VW 5i. This document will address those issues in the following fashion:
Follow this link for specific class/method differences
Why Upgrade VisualWorks
- Highlight the important changes from VW 2.5x to VW 5i
- Overview the likely impact on developers in moving forward
- Include full details of changes from VW 2.5.2 through VW 5i
Try it today! Visit the Cincom Smalltalk Website and download the non-commercial version. Then visit the Cincom Smalltalk Developer's Site in order to take advantage of our online developer community site.
There were only a handful of classes that were obsoleted between VW 2.5.2 and VW 5i; of those, Only a few are likely to impact any developers:
- ParcelList
- Replaced by the new ParcelBrowser
- UIMenuEditor
- Replaced by the new MenuEditor
- Project
- Replaced by the new Lite Projects toolset
- SystemDictionary
- Class organization has changed with the implementation of global NameSpaces
Of these, only the UIMenuEditor is likely to affect developers, and the new tool (actually introduced in VW 2.5) will read menu definitions created by the old tool. Thus class eliminations should not affect developers greatly. The following changes in the existing system will be of interest:
- New Feel Policies
- This addition eliminates the need to make direct modifications in class ParagraphEditor. Many developers modify this in order to create custom key bindings within the editors. In this case, developers can move forward merely by moving the bindings into a new subclass of UIFeelPolicy, thus eliminating changes to system code
- Look Policy Deprecation
- In VisualWorks 5i.x, the following look policies are shipped as obsolete parcels
- CUA Look Policy
- Windows 4 Look Policy
- The ICC Windows Look Policy has been fully integrated as the standard Windows Look Policy
- The Mac 8 Look Policy will be fully integrated as the standard Macintosh Look Policy in the 5i.4 (July 2002) release.
- In a future release, the Windows 3 and old Mac Look policies will be shipped as obsolete parcels
- Movement of exception handling to the ANSI standard
- The signal based framework has been changed to the class based exceptionm model used by VSE, VA, and Dolphin (which is the one adopted by the X3J20 committee). We have added extensive backwards compatibility, so no current exception handling code will break. Newly developed code should use the new model; this is detailed in the product documentation.
- Event enablement is now the default for the GUI
- In VW 2.x, polling was the default mechanism, with events an optional add-on. This is now reveresed; polling may be turned on for individual interfaces. This may be an issue for custom widgetry that has not been transitioned.
- Temporarily change the default to polling
- Transition custom widgets to events
- Restore system defaults back to events
- Parcels are no longer based on BOSS
- In VisualWorks 5i.3, the polling mechanism has been deprecated. We expect to remove the polling code from the system entirely in the 5i.4 (July 2002) release. Polling support will be shipped as an obsolete parcel at that point.
- Users of VW 2.5.x parcels must regenerate parcels from scratch in VW 5i.x. This is easy to do using the new parcel tools; additionally, the new parcel tools allow for more functional parcels
- VisualWorks 5i will read VisualWorks 3.x parcels, but generates a different format. The VisualWorks byte code set has been changed for VisualWorks 5i.
- VisualWave interface opening protocol has been made part of the VW standard base
- This allows users of VW and VisualWave to more easily build applications between the two environments
- Addition of Global NameSpace support
- This will have no actual impact on imported code; it should be noted that all code imported will fall into the NameSpace of its superclass
- Pool Dictionaries and Class Variables have been unified into a single new construct, the Shared Variable. This allows for more coherent organization of code moving forward; it also allows for the definition of true constants. It has no affect on imported code, as all defined Class Variables and Pool Dictionaries are mapped into statics, whether they are filed in or parceled in (or imported in via Envy)
- VW 5i includes a new versioning system, StORE. StORE uses a relational back end (Oracle, SQLServer, PostgreSQL) as the repository. Cincom is providing migration tools for those wishing to move code from ENVY to StORE. There is also community based support for DB/2; see: DB/2 StORE Support
As seen above, the changes have either been structural (with little developer impact), or have been done with careful attention paid to backwards compatibility. In most cases, code imported from VW 2.5.x to VW 5i should work with little or no modification. Tool developers (third party vendors of widgets, modeling tools, etc.) may have additional difficulty, but even here porting should be straightforward.
Why Upgrade VisualWorks
Instructions to Port Arbor 2.5 help to 5i help