A Case Study on Unicode Integration: Microsoft Visual Basic, v 3'0 to v' 7'0

1
A Case Study on Unicode Integration Microsoft
Visual Basic, v 3.0 to v. 7.0

• Michael S. Kaplan
• Software Design Engineer
• Microsoft

http//www.i18nWithVB.com/
2
DISCLAIMER
3
The purpose(s) of Visual Basic

• Making Windows development easier
• Promote the Windows platform through ISVs who use
  it
• The "apple in Bill's eye"

4
International support in the early versions (1.0
3.0)

• Very limited!
• Multiple versions of the product codebase
• Bugs found in one language version often not
  fixed elsewhere
• NO Unicode support

5
VB 4.0 - a time for choices
6
Keep VB in 16 bit, and take advantage of the
support for Win16 applications

• Easy for VB to do
• Useless for the Win32 platform itself
• No international support at all

7
Move VB to Win32 entirely, leveraging the
emerging NT platform's full support of Unicode
through its "W" APIs.

• Great international solution
• Poor solution for Windows 95

8
Move VB to Win32 but still with a code page model
rather than a Unicode one, using the "A" APIs.

• Easiest to do
• Less multilingual support

9
A hybrid technique ("A" APIs on Win9x, "W" APIs
on NT)

• Most complicated to do
• Best international support
• Good leveraging of the best features of each
  platform

10
What the VB team actually did

• Using COM
• Porting the original VB
• Working with the volume platform (Windows 95)

11
Where COM fits in

• Benefits to VB by using COM
• Benefits to COM by VB being a client

12
The birth of "UniMess"

• An attempt to keep the conversion from VB3 to VB4
  simple
• From simplicity comes confusion

13
The cousin of UniMessUsing LCIDs for code pages

• COM's biggest drawback
• Once again, simplicity causes problems

14
Beyond UniMess

• Intrinsic function woes
• Source file encoding compatibility
• Trouble with the Ruby forms package
• Difficulties with API calls
• Problems with file i/o

15
The verdict for VB4?
16
Changes in VB5

• Minor functionality enhancements
• No major changes for Unicode support
• Some work with the StrConv function

17
Changes in VB6

• More work with StrConv
• A lot of VB-specific code moved to COM
• A lot of other VB-specific functionality now
  using existing COM methods

18
And then came VB.NET

• System.Text
• System.Globalization
• System.Resources
• The Unicode Visual Studio IDE
• Mostly Unicode controls in WinForms

19
Lessons learned

• Was VB4 a good Unicode integration?
• Were VB5 and VB6 good integrations?
• What about VB.NET?

20
Summary of lessons learned

• Backwards compatibility is crucial
• Conversion between Unicode and other encodings is
  crucial
• New data types need new constructs
• Understand why you are supporting Unicode (the
  primary reasons for that support)
• Know what supplementary benefits you will gain
  from Unicode

21
Questions?
22

• A Case Study on Unicode Integration Microsoft
  Visual Basic, v 3.0 to v. 7.0