VisualWorks 3.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 3.x to VW 5i. This document will address those issues in the following fashion:
Follow this link for specific class/method differences
VisualWorks 5i.4 White Paper, VisualWorks 5i.3 White Paper
Why Upgrade VisualWorks
- Highlight the important changes from VW 3x to VW 5i
- Overview the likely impact on developers in moving forward
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 3.x and VW 5i - most of those are in obsoleted look polcies:
Removed: Win3CheckButtonView
Removed: Removed: Win3ComboBoxButtonView
Removed: Removed: Win3FeelPolicy
Removed: Win3LookPolicy
Removed: Win3MenuBar
Removed: Win3MenuBarButtonView
Removed: Win3MenuButtonView
Removed: Win3MenuItemView
Removed: Win3MenuView
Removed: Win3RadioButtonView
Removed: Win3ScrollBar
Removed: Win3SliderView
Removed: Win3WidgetPolicy
Removed: Win4ActionButtonView
Removed: Win4Border
Removed: Win4BorderDecorationPolicy
Removed: Win4CheckButtonView
Removed: Win4ComboBoxButtonView
Removed: Win4FeelPolicy
Removed: Win4LookPolicy
Removed: Win4MenuBar
Removed: Win4MenuBarButtonView
Removed: Win4MenuButtonView
Removed: Win4MenuItemView
Removed: Win4MenuView
Removed: Win4RadioButtonView
Removed: Win4ScrollBar
Removed: Win4WidgetPolicy
- 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.4, the following look policies will be 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 2001) release.
- In a future release, the Windows 3 and old Mac Look policies will be shipped as obsolete parcels
- Event enablement is now the default for the GUI. Polling has been removed and is in a compa parcel.
- 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
- VisualWorks 5i will read VisualWorks 3.0 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.
VisualWorks 5i.4 White Paper, VisualWorks 5i.3 White Paper
Why Upgrade VisualWorks
Instructions to Port Arbor 2.5 help to 5i help