26 April 2001 Unicode and Visual Basic, IUC 18 (Hong Kong) Unicode and Visual Basic: A Case Study Michael S. Kaplan Software Design Engineer Trigeminal

26 April 2001 Unicode and Visual Basic, IUC 18 (Hong Kong)

Unicode and Visual Basic: Unicode and Visual Basic: A Case StudyA Case Study

Michael S. KaplanSoftware Design EngineerTrigeminal Software, Inc.http://www.trigeminal.com

http://www.i18nWithVB.com/


The purpose of Visual BasicThe purpose of Visual Basic

Making Windows development easierPromote the Windows platform through

ISVs who use itThe "apple in Bill's eye"


International support in the International support in the early versionsearly versions

Very limited!Multiple versions of the product codebaseBugs found in one language version often

not fixed elsewhereCertainly NO Unicode support


VB 4.0 - a time for choicesVB 4.0 - a time for choices


Keep VB in 16 bit, and take Keep VB in 16 bit, and take advantage of the support for advantage of the support for

Win16 applicationsWin16 applications

Easy for VB to doUseless for the Win32 platform itselfNo international support at all


Move VB to Win32 entirely, Move VB to Win32 entirely, leveraging the emerging NT leveraging the emerging NT

platform's full support of Unicode platform's full support of Unicode through its "W" APIs.through its "W" APIs.

Great international solutionPoor solution for Windows 95


Move VB to Win32 but still with a Move VB to Win32 but still with a code page model rather than a code page model rather than a

Unicode one, using the "A" APIs.Unicode one, using the "A" APIs.

Easiest to doLess multilingual support


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

Most complicated to doBest international supportGood leveraging of the best features of each

platform


What the VB team actually didWhat the VB team actually did

Using COMPorting the original VBWorking with the volume platform

(Windows 95)


Where COM fits inWhere COM fits in

Benfits to VB by using COMBenefits to COM by VB being a client


The birth of "UniMess"The birth of "UniMess"

An attempt to keep the conversion from VB3 to VB4 simple

From simplicity comes confusion


The cousin of UniMess:The cousin of UniMess:Using LCIDs for code pagesUsing LCIDs for code pages

COM's biggest drawbackOnce again, simplicity causes problems


Beyond UniMessBeyond UniMess

Intrinsic function woesSource file encoding compatibilityTrouble with the Ruby forms packageDifficulties with API callsProblems with file i/o


The verdict for VB4?The verdict for VB4?


Changes in VB5Changes in VB5

Minor functionality enhancementsNo major changes for Unicode supportSome work with the StrConv function


Changes in VB6Changes in VB6

More work with StrConvA lot of VB-specific code moved to COMA lot of other VB-specific functionality

now using existing COM methods


And then came VB.NETAnd then came VB.NET

System.TextSystem.GlobalizationSystem.ResourcesThe [unicode] Visual Studio IDE


Lessons learnedLessons learned

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


Summary of lessons learnedSummary 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


Questions?Questions?


Unicode and Visual Basic:A Case Study

Documents

26 April 2001 Unicode and Visual Basic, IUC 18 (Hong Kong) Unicode and Visual Basic: A Case Study Michael S. Kaplan Software Design Engineer Trigeminal